Picture the usual setup in 2026: a Symfony or Laravel app, a queue worker that embeds every uploaded document, and a Qdrant node sitting next to the database doing semantic search over it all. The app itself is cheap to run. The vector store is not, because vectors want RAM, and RAM is the most expensive thing you can rent. Qdrant 1.19 ships two answers to that, and I want to make a case that the unglamorous one, the unified memory tier API, is the feature most of us should upgrade for, while the headline-grabbing turbo4 datatype deserves both admiration and a warning sticker. It permanently throws away your full-precision vectors, and that decision does not belong in an infra config file alone.

{
  "vectors": {
    "size": 1536,
    "distance": "Cosine",
    "datatype": "turbo4"
  }
}

Start with the boring win. Before 1.19, controlling where Qdrant kept data meant juggling on_disk on the vector params, always_ram on the quantization config, and on_disk_payload at the collection level, three flags with three names in three places. The HNSW graph itself you could not place at all; it always lived in heap memory. Version 1.19 collapses this into a single memory parameter with three values: pinned (locked in RAM), cached (on disk, page cache pre-warmed, evictable), and cold (on disk, loaded lazily). It works on vectors, HNSW links, quantized copies, payloads and payload indexes alike, and you can change it on a live collection with update_collection, no rebuild required. For those of us operating Qdrant as a sidecar to a PHP app, talking to it over HTTP, that turns memory planning from folklore into an actual knob.

The knob matters because the arithmetic is ugly. Cloud RAM runs somewhere around $3 to $8 per GB per month; NVMe disk costs roughly $0.10 to $0.30. The release notes' own example: a billion 768-dimension float32 vectors need about 2.9 TB of storage, and an all-pinned deployment wants roughly 3.7 TB of RAM. Move the originals to cold storage and pin only an int8 quantized copy for graph traversal, and you're at about 768 GB. At $5 per GB per month that's $18,500 versus $3,840. You and I are probably not at a billion vectors, but the ratio survives the trip down to ten million just fine, and ten million chunks is a very reachable number for any product that embeds customer documents.

Now the sharp knife. TurboQuant arrived in 1.18 as a quantization method built on a Google Research idea: rotate the vector randomly before compressing, so the information spreads evenly across dimensions and 4-bit encoding loses a little everywhere instead of a lot somewhere. In 1.18 that 4-bit copy sat on top of your float32 originals, which meant 36 bits per dimension in total. In 1.19, turbo4 becomes a datatype. Set it at collection creation and Qdrant stores only the 4-bit form. No float32 on disk, none in RAM, none anywhere. Ten million 1536-dimension text-embedding-3-small vectors shrink from roughly 64 GB under the old pattern to about 7 GB. For multi-vector ColBERT-style collections, where every document carries dozens of token embeddings, the savings multiply per vector.

The price is rescoring, or rather the permanent absence of it. With no full-precision copy, both graph traversal and final ranking run on 4-bit distances, and typical recall lands around 0.90 to 0.95, compared to 0.97 to 0.99 when you rescore against float32. Here is my actual point: that gap is a product decision wearing an ops costume. Whoever writes datatype turbo4 into a collection config is deciding that roughly one relevant result in twenty may quietly not come back. For first-stage retrieval feeding a cross-encoder reranker, or a recommendations widget, that trade is often correct. For anything where a missed match has consequences, a legal archive, a compliance lookup, the person deploying the config should not be the only person who signed off on it.

The fair counter-argument is that this door isn't truly locked. If you kept the source text, and you should have, you can re-embed everything and rebuild a float32 collection whenever you like. True, and it takes the drama out of the decision. But re-embedding ten million chunks costs real API money and real days, and the failure mode is nasty precisely because it's quiet: recall regressions surface as a support ticket saying search feels worse, and nobody's first suspect is a storage datatype chosen eight months ago. So before flipping it, measure recall on your own queries against your own data, not synthetic vectors. Also mind the fine print: turbo4 is dense-only, and Manhattan distance forces full vector reconstruction, so stick to Cosine, Dot or Euclidean. And there's a middle path I genuinely like: stack 1-bit TurboQuant on top of turbo4 and rescore against the 4-bit values, better recall than none, still the 4-bit disk footprint.

It's worth saying that nobody else offers this exact trade right now. Weaviate has a rotation-based quantization scheme of its own but always retains the uncompressed vectors, Milvus doesn't go below 8-bit, and Pinecone's serverless tier exposes no compression or placement controls at all. From PHP-land, where the vector store is usually a service we call from a worker rather than a system we patch, I'll take an explicit dial over an opaque managed decision every time, because the invoice arrives at our address either way.

So here's where I land: upgrade for the memory tiers, treat turbo4 like a schema migration you can't roll back cheaply, and put the recall number in the pull request description where a human has to read it. Now tell me where your line is. Would you run turbo4 for user-facing search in production, and if so, what recall figure, measured on your own query log, would make you comfortable deleting the originals? I suspect the answers under this column will range from 0.99 to a shrug, and I want to see both.