Qdrant in 8 Slides

This cover frames Qdrant by the choice it refuses to make. The usual vector-database split is stark: either you take an open-source library you host and babysit yourself, or you rent a managed cloud whose internals you can never inspect. Qdrant's pitch is that you don't have to pick — the identical Rust engine runs as a one-line Docker container on your laptop and as a managed service in Qdrant Cloud.

That single-engine story is why this post starts with vocabulary rather than features. Before 'payload filtering' or 'HNSW' mean anything, you need the nouns: vector, collection, point, payload. Get those straight and the rest of the day's posts slot into place.

Calling Qdrant a 'vector database' is precise, not marketing. A relational database is built to answer exact and range queries over scalar columns; a vector database is built to answer 'which stored items are nearest this one in high-dimensional space'. Qdrant stores the embeddings a model produces and returns nearest neighbours in milliseconds, even across millions of points.

The Rust detail matters more than it sounds. Rust gives Qdrant tight, predictable memory behaviour and no garbage-collector pauses, which keeps tail latency stable under load. And because it ships as a single binary or container exposing REST and gRPC, the operational surface is small: there's no JVM to tune, no external coordinator to run for the basic case.

A vector is the unit Qdrant actually stores and compares. It's a fixed-length list of floating-point numbers — common sizes are 384, 768, or 1536 — produced by an embedding model. The key property is geometric: content with similar meaning lands at vectors pointing in similar directions, so 'similar meaning' becomes 'small distance' or 'large cosine similarity'.

The division of labour is important to internalise early. Qdrant does not embed anything. You run the model — sentence-transformers, OpenAI, Cohere, whatever — and hand Qdrant the resulting numbers. Qdrant's job begins after the embedding exists: store it, index it, and find its neighbours fast.

These three nouns are the entire mental model. A collection is the container that fixes two things you cannot change casually later: the vector size and the distance metric. Every point in a collection must share that size. A point is one stored item — an integer or UUID id, the vector itself, and an optional payload. The payload is arbitrary JSON: tags, timestamps, owner ids, anything you might want to filter on.

The reason to learn these now is that almost every Qdrant operation is phrased in them. You create a collection, upsert points, query for nearest points, and filter on payload. Master the four verbs over these three nouns and you can read any Qdrant codebase.

This stack diagram shows the containment hierarchy that trips up beginners who picture a flat 'database of vectors'. The collection sits at the top, defining size and metric. Inside it live points, each of which bundles an id, a vector, and a payload. The vector is the searchable geometry; the payload is the filterable metadata.

Seeing the nesting explicitly clarifies why some settings are collection-level (size, metric, quantization) while others are per-point (the actual values and JSON). You configure the box once, then pour many points into it.

This is what a single point looks like on the wire. The id can be an unsigned integer or a UUID — not an arbitrary string, a constraint that surprises people coming from key-value stores. The vector is the list of floats your model produced. The payload is free-form JSON.

Notice how the payload mixes types: a string source, an integer page, and an array of tags. All of these become filterable, which is the feature that makes the next post worth writing. The vector answers 'what's similar'; the payload answers 'and which of those am I allowed to return'.

This slide names the behaviour that separates a vector database from a normal one. Qdrant does not look for exact matches; it ranks points by closeness to the query vector. What 'closeness' means is decided per collection — cosine similarity, dot product, or euclidean distance — and that choice must line up with how your embedding model was trained.

The payoff is semantic recall. A user asking 'how do I reset my password' can match a document titled 'recovering account access' despite zero shared words, because the two phrases embed to nearby vectors. That is the capability keyword search structurally cannot offer.

This comparison places Qdrant against the two alternatives people most often weigh it against. Versus Pinecone, the headline difference is openness: Pinecone is managed-only and closed-source, while Qdrant you can self-host, read, and run air-gapped. Versus pgvector, the difference is dedication: pgvector adds vector search to Postgres, which is convenient if you already run Postgres but inherits a general-purpose engine's constraints, whereas Qdrant is purpose-built with mature payload filtering.

None of these is strictly 'best'. The right pick depends on whether you value managed simplicity, an existing Postgres footprint, or open-source control with strong filtering. This post argues Qdrant wins when that last column matters most.

This slide defends the two words Qdrant leads with. Rust matters because vector search is latency-sensitive and a garbage-collected runtime can pause mid-query when the collector runs, spiking p99. Rust has no GC, so latency stays predictable, and its zero-cost abstractions let Qdrant use SIMD for distance math without unsafe hacks everywhere.

Open-source matters for a different reason: trust and portability. You can read the engine, audit how filtering works, run it where compliance requires, and avoid being locked to one vendor's pricing. Crucially, the laptop binary and the cloud service are the same code, so behaviour you validate locally holds in production.

This recap compresses the whole post into five lines you can recall under pressure. Qdrant is an open-source vector database written in Rust. A collection fixes the vector size and distance metric. A point is an id plus a vector plus a payload. You search by vector similarity and narrow by payload filter. And the same engine runs from your laptop to the cloud.

If you remember nothing else, remember the noun hierarchy and the single-engine promise — everything in the next four posts is an elaboration of those.

The CTA points forward to the 'why it matters' post. Having the vocabulary is necessary but not motivating; the next post supplies the stakes — what payload filtering, self-hosting, and Rust speed actually buy you in a production system, and where Qdrant is the wrong tool. Save this one as the glossary you'll reread when the later posts use these terms freely.