Qdrant 1.18 is on Layerbase, and the Headline is Quantization

Qdrant 1.18 is now the default version for new Qdrant databases on Layerbase Cloud. 1.16 stays supported for databases already running it, and as always we do not move a version underneath a database that is working.

The interesting part of this release is quantization, which is the lever that decides whether your vector index fits in RAM or does not. To explain why that is the lever, it helps to be precise about what a vector database is doing in the first place.

What vector search actually computes

An embedding model turns a piece of content into a list of numbers. A sentence becomes 384 or 768 or 1536 floats, depending on the model. The useful property is that the model was trained so that content with similar meaning lands close together in that space, under a distance measure like cosine similarity or dot product.

Search then becomes geometry. Embed the query with the same model, and the documents whose vectors are nearest to the query vector are the ones that mean something similar. That is why a search for "receipt" can return a document that only ever says "invoice": the words never match, the vectors do.

Doing that exactly means computing the distance from the query to every stored vector, which is fine at ten thousand vectors and hopeless at ten million. So vector databases build an approximate nearest neighbour index. Qdrant uses HNSW, a layered proximity graph: the top layer is sparse and lets you jump across the space in a few hops, and each layer down is denser, so you descend and refine until you are in the right neighbourhood. You give up a small amount of recall (you might miss a true nearest neighbour occasionally) in exchange for logarithmic-ish search instead of linear.

That is the entire trick, and every other decision in a vector database is a consequence of it.

What Qdrant adds on top of the index

A bare ANN index would not need to be a database. Qdrant is one because a real retrieval system has requirements the index alone cannot meet.

Payloads and filtering. A Qdrant point is an id, one or more vectors, and a payload: arbitrary JSON attached to the point. Tenant id, document category, language, ACL, publish date, whatever your application needs. You can then search with a filter, and this is where the implementation matters. Filtering after the ANN search is broken: if you ask for the top 10 and then throw away everything from the wrong tenant, you may be left with two results. Qdrant's filtering is integrated into the graph traversal, with payload indexes it can consult while walking, so what you get back is the top 10 among points that satisfy the filter, not whatever survived a post-filter. It is still an approximate top 10, because HNSW is approximate; set "exact": true inside the request's params object when you need a guaranteed answer and are willing to pay for a full scan. It has to go in params, not at the top level of the request: a stray top-level exact is silently ignored, so you get the approximate answer back with no error to tell you. If you take one thing away about why to use a vector database rather than an index library, filtered search is it.

Multiple vectors per point. A single point can carry named vectors: a dense embedding for meaning, a sparse vector for lexical matching, maybe an image embedding for the same product. You search whichever one the query calls for.

Hybrid search. Dense embeddings are good at meaning and bad at exact tokens. Nobody's embedding model reliably nails a part number. Sparse vectors are the reverse. Hybrid search runs both and fuses the ranked lists, usually with Reciprocal Rank Fusion, which scores each result by its rank in each list rather than by raw scores that are not comparable across retrieval methods. 1.17 added weighted RRF, so you can tell the fusion that your dense results are worth more than your sparse ones (or the other way round) instead of accepting a straight blend.

RAG. Retrieval-augmented generation is just this pipeline with a language model bolted on the end: embed the user's question, retrieve the top handful of chunks (filtered to what this user is allowed to see), put them in the prompt. The retrieval quality and the filter correctness are the whole ballgame. The model is downstream of both.

Quantization, and why it is the interesting number

Vectors are stored as 32-bit floats by default. Do the arithmetic on a realistic corpus:

A 1536-dimension embedding at fp32 is 1536 × 4 = 6,144 bytes, so roughly 6 KB per vector. One million of them is about 6.1 GB, before the HNSW graph, before payloads, before payload indexes. Ten million is 61 GB. That number is why "just add more vectors" turns into an infrastructure conversation faster than people expect.

Quantization compresses the stored vectors so more of the index fits in memory, at some cost in precision. The classic options:

• Scalar quantization maps each float to an int8, which is 4x smaller. Recall loss is usually small.
• Binary quantization takes it to one bit per dimension, 32x smaller. That is a dramatic saving and, on many embedding models, a dramatic recall loss.
• Product quantization splits the vector into subspaces and codes each against a learned codebook. Good ratios, more tuning.

The usual play is to search over the compressed vectors to get a candidate set, then rescore the candidates against the full-precision originals on disk. You pay the disk read for a few hundred vectors instead of a few million.

Qdrant 1.18's headline feature is a new rung on that ladder. TurboQuant is a rotation-based scheme out of Google Research: it applies a fast Hadamard rotation to the vector before compressing it, which spreads the information evenly across the coordinates instead of leaving it concentrated in a few. Because the rotation normalises the distribution, it behaves consistently across embedding models rather than needing per-model tuning.

What Qdrant reports is 8x compression at scalar-quantization-level recall, and at the more aggressive 16x and 32x settings a recall advantage over binary quantization of roughly 9 to 21 percentage points across the datasets and embedding models they benchmarked. The 4-bit variant lands competitive with scalar quantization at half the storage. Their TurboQuant write-up has the per-dataset numbers, and they are worth reading before you take any compression ratio on faith for your own embeddings.

Back to the arithmetic: that million-vector, 1536-dimension collection goes from about 6.1 GB of raw vectors to roughly 770 MB at 8x. That is the difference between an instance you have to think about and one you do not.

The rest of what landed between 1.16 and 1.18

Two releases of changes, and the pattern across both is memory and operational honesty rather than new query surface.

From 1.17:

• Relevance Feedback, so a search can be refined using signals about which earlier results were good.
• Weighted RRF for hybrid search, covered above.
• An optimization progress API, which reports what the optimizer is doing and which stage it is in. Previously "why is my collection slow right now" was answered by staring at metrics and guessing.
• update_mode on upsert, letting you pick upsert (the default), insert_only, or update_only explicitly instead of always getting upsert semantics.
• Audit access logging, and a secondary API key so you can rotate keys in a cluster without downtime.
• A dedicated HTTP port for /metrics, so internal monitoring does not have to go through the same port as your data plane.
• Snapshot recovery without intermediate files, unpacking directly into the target filesystem. This is a large win on recovery time and on the disk headroom a recovery needs.

From 1.18:

• TurboQuant.
• Named vector creation and deletion on an existing collection. Adding a second embedding to a live collection used to mean a migration.
• Deep memory reporting, a breakdown of memory usage per storage component. Paired with the new memory and disk inspector in the web UI, "what is using my RAM" is now a question with an answer.
• Low memory mode, which forces everything open on disk to avoid an out-of-memory crash during startup, and a strict mode parameter (max_resident_memory_percent) that rejects updates once memory usage crosses a threshold. Both exist because the failure mode people actually hit is an OOM during load or ingest, not a slow query.
• RocksDB removed entirely, simplifying storage handling. Qdrant has been migrating off it for several releases and 1.18 is where the last of it goes.
• A dynamic CPU pool for search workers, which helps most when searches are IO-bound and threads would otherwise sit idle waiting.
• Immutable geo index memory down 7x, and API key or JWT authentication now enforced on internal gRPC endpoints.

Through 1.18.3, three patch releases of fixes, including two worth naming: 1.18.2 fixed a REST auth whitelist bypass on specially crafted paths (the route is now resolved before authorization) and an out-of-bounds heap read triggerable by a malicious snapshot. There were also correctness fixes for indexed integer range filters compared against float values, for MatchAny with an empty list on an integer index, and for a panic on empty vectors. 1.18.3 fixed query errors when using shard keys during resharding.

That is the argument for being on the current patch rather than the current minor.

What it looks like on Layerbase

Create a Qdrant database from the dashboard and you get a REST endpoint plus an API key. Qdrant's API is HTTP and JSON, so the fastest way to confirm what you are running is to ask it:

curl -s https://your-host.cloud.layerbase.dev \
  -H "api-key: your-api-key"

{ "title": "qdrant - vector search engine", "version": "1.18.3", "commit": "..." }

The dashboard also has a REST console, so creating a collection and running a query does not require a local client. PUT /collections/support_docs with a body declaring the vector size, the distance measure, and how you want vectors quantized. The size is 4 here only so the two calls below can be pasted in and run as written; in production it is whatever your embedding model emits, 1536 for the model the arithmetic above assumed:

{
  "vectors": { "size": 4, "distance": "Cosine" },
  "quantization_config": { "scalar": { "type": "int8", "always_ram": true } }
}

Then POST /collections/support_docs/points/query to search with a filter, which is the shape of every real query you will write. The query vector has to have exactly the number of dimensions the collection declared:

{
  "query": [0.021, -0.114, 0.043, 0.077],
  "filter": {
    "must": [{ "key": "tenant_id", "match": { "value": "acme" } }]
  },
  "limit": 10,
  "with_payload": true
}

Create a payload index on tenant_id before you rely on that filter at any scale. An unindexed filter field means Qdrant is checking payloads it could have skipped.

Qdrant is one of our always-on engines, so it does not sleep when idle and there is no cold start in front of the first query. That puts it on the Pro plan: $15/month flat for the whole engine catalog, no usage meters, with a 1.5 GB reserved RAM pool you allocate across your databases however you like. Vector indexes grow with your data, so the pool is the number to watch rather than a per-query bill.

Where to go next

If vector search is new to you, What is a vector database? is the ground-up version of the first half of this post. Getting started with Qdrant builds a filtered semantic search in TypeScript with local embeddings, end to end, no embedding API key required. Qdrant vs Weaviate runs the same queries through both if you are still choosing, and full-text search vs vector search is the post to read before you assume you need embeddings at all.

Engine details and connection specifics are on the Qdrant engine page, and the Qdrant docs cover everything above in depth.