DB Weekly: four-bit vector storage and the 10,000-transaction backpressure lesson (2026)

Coverage: August 3 through August 10, 2026, ending at the scheduled publication time in UTC-08:00.

Qdrant 1.19 adds a four-bit storage datatype that can cut vector storage by up to ninefold, while a PlanetScale production report shows a Vitess/MySQL workload recovering after transaction concurrency fell from 10,000 to roughly 1,000. The common decision is about where to put the pressure: accept a measurable recall trade-off, queue work before it reaches InnoDB, or move more filtering and aggregation into the database.

No qualifying PostgreSQL core, MySQL, MongoDB, Weaviate, or pgvector release with a verified publication date in this window made the cut. The only quantified performance evidence below is a production operating report, not a matched cross-engine benchmark; the migration evidence is similarly operational rather than a clean before-and-after engine comparison.

At a glance

Signal	What changed	Decision gate
Qdrant 1.19.0	Turbo4 stores vectors as four-bit values without a full-precision copy; unified `pinned`, `cached`, and `cold` memory tiers; legacy query endpoints removed. 1	Use the storage format only when disk pressure matters more than maximum recall. Treat the endpoint removal and memory-tier migration as upgrade work, not cleanup.
Milvus 3.0 query path	Regex filters, query aggregation, search aggregation, and server-side `ORDER BY` move more post-retrieval work into Milvus. Query operations are exact over visible filtered rows; ANN search operations remain bounded by the retained candidate set. 2 3	Measure bytes moved and application CPU, but keep exact analytics and approximate ANN summaries on separate correctness paths.
Vitess + MySQL production report	After a long transaction helped trigger a 16-minute incident, PlanetScale reduced a transaction pool from 10,000 to roughly 1,000 and queued rather than rejected excess work. A later burst reached about 25,000 slot requests per second with no application disruption. 4	Size concurrency from observed throughput and queue tolerance. Raising a cap until errors disappear can remove the backpressure that protects the storage engine.

Qdrant: four-bit storage makes recall the upgrade gate

Qdrant published version 1.19.0 on August 5. Its sharpest change is the Turbo4 datatype: Qdrant stores only the four-bit TurboQuant representation instead of keeping both the compressed vector and the original full-precision vector. The post describes a change from 36 bits per coordinate for the two-copy arrangement to four bits for Turbo4, or a ninefold reduction in storage. 1

That is a storage decision, not a free compression win. With no original vector available, Qdrant cannot rescore top candidates against full precision. Qdrant positions Turbo4 for cases where disk usage is the primary constraint; its ordinary TurboQuant path, layered over full-precision storage, remains the safer choice when recall is the priority. 1

The operational side is just as important. Version 1.19 replaces several per-component memory switches with one memory parameter and three tiers: pinned, cached, and cold. Existing flags remain functional but are deprecated. The new model lets operators place HNSW links, sparse indexes, quantized vectors, payloads, and payload indexes independently instead of treating memory placement as a collection of unrelated settings. 1

The upgrade also removes the legacy /search, /recommend, and /discover endpoints. Clients still using them must move to the unified /query API before the upgrade; this is a compatibility gate that can be found with a repository-wide API search. 1

What to test:

Run the same recall set against full-precision storage, ordinary TurboQuant, and Turbo4. Record recall at the actual top_k and filter mix your service uses; the ninefold storage figure does not establish a recall delta for your corpus.
Map current per-component memory settings to pinned, cached, or cold, then test restart behavior and tail latency after cache eviction.
Search client code and generated SDK calls for the removed endpoints before selecting 1.19 as the production target.

Milvus: more post-processing moves inside the query engine

Two Milvus 3.0 explainers published this week describe a query path that is becoming more database-like. The August 5 regex update adds =~ and !~, backed by RE2 validation and NGRAM candidate generation, so regex can participate in vector search, full-text search, and scalar filtering. Milvus still separates exact equality, LIKE, regex, token-level text_match/BM25, and ordered phrase_match; it does not provide native fuzzy matching for typographical variation. 2

The engineering implication is narrower than "regex is faster." The relevant question is whether the predicate can use an indexed execution path and whether its semantics match the data. Keep == and IN for exact values, LIKE for simple patterns, and regex for structural patterns such as character classes, repetition, anchors, and ordered fragments. If the real requirement is typo tolerance, the application still needs to own that behavior. 2

The August 7 aggregation update adds two different kinds of database-side work. Query aggregation can compute count, sum, avg, min, and max, optionally with GROUP BY, over filtered visible rows. Search Aggregation summarizes the candidates already retained by an ANN search, with buckets, metrics, representative hits, and optional child buckets. Server-side ORDER BY follows the same boundary: exact for query results, approximate when it orders ANN candidates. 3

Milvus gives a useful scale example rather than a benchmark: a dashboard over two million in-stock rows at about 100 bytes per row would move roughly 200 MB to the application for client-side aggregation, while the final answer might be measured in kilobytes. The number illustrates data movement; it does not prove a fixed latency or throughput gain on a particular cluster. 3

What to test:

Put exact filtered aggregation and ANN candidate aggregation in separate test cases. A passing result count does not mean the ANN path examined the full collection.
Compare application-side and server-side bytes transferred, CPU, and p95 latency for the same filter and result shape.
Treat regex selectivity as part of the benchmark. A syntactically valid pattern is not automatically a cheap predicate.

Vitess and MySQL: concurrency is a backpressure setting

PlanetScale's August 7 post is the week's strongest quantitative signal, but it is a production operating report rather than a controlled engine benchmark. The incident involved a workload recently migrated from Cloud SQL to Vitess-backed MySQL. A batch transaction held row locks for about 15 minutes; snapshot reads then had to walk growing row-version histories. The post's opening chart shows throughput falling from 15,000 queries per second at the burst to 1,500 at the error peak, while errors climbed to about 1,400 per minute. 4

The migration changed the failure behavior. Cloud SQL's managed connection pooling queued requests when its roughly thousand-thread pool filled. Vitess's transaction pool instead allowed the team to raise the cap to 10,000; when the long transaction created pressure, that large admission limit let roughly 10,000 requests enter the storage engine rather than waiting outside it. PlanetScale's report says the higher cap stopped the immediate pool-full errors, but removed the backpressure that had protected InnoDB. 4

The fix reversed both choices: reduce the transaction pool to roughly 1,000, and queue at capacity with a bounded wait instead of failing immediately. In the first reported burst test, slot requests reached about 25,000 per second against roughly 1,000 available slots; the application saw no disruption, QPS stayed near 60,000, and fewer than 200 statements were executing inside MySQL at any instant. Across the day, the report records one rejected transaction even though slot requests briefly reached 40,000 per second. 4

The result is not a universal rule to lower every database pool. It is a workload gate. The report names pessimistic locking, hot rows, SELECT ... FOR UPDATE, long transactions, counters, balances, and job queues as cases where admitting more work can reduce total throughput. The right comparison for a backend team is not "maximum concurrent clients"; it is the combination of queue wait, in-flight statements, error rate, and completed work during a burst. 4

The week's positioning shift

The three signals address different bottlenecks:

Qdrant reduces bytes per stored vector. The cost is a deliberate loss of full-precision rescoring, so the choice belongs beside a recall budget and a disk budget.
Milvus reduces bytes and CPU outside the database. The cost is semantic: query aggregation is exact over visible filtered rows, while ANN aggregation inherits the candidate set and its recall boundary.
Vitess limits work entering MySQL. The cost is queueing and bounded wait, exchanged for a storage engine that can keep making progress during bursts.

That is a more useful map than a new leaderboard. None of these sources supplies a matched PostgreSQL-versus-MySQL-versus-vector-DB benchmark with common hardware, workload, p50/p99 latency, and throughput definitions. Qdrant and Milvus publish capability and architecture claims; PlanetScale publishes observed production behavior. They should not be converted into a cross-engine performance ranking.

The same caution applies to the quiet parts of the week. No qualifying PostgreSQL core, MySQL, MongoDB, Weaviate, or pgvector release with a verified August 3–10 publication date was confirmed for this brief. That is a coverage result, not evidence that those systems are standing still.

A relevant Hacker News discussion did surface around "How We Pushed CDC into Postgres." The thread carried 135 points and 27 comments when retrieved, which makes it a useful community signal about interest in Postgres change-data-capture design. It does not establish consensus, a new benchmark, or a new migration outcome. 5

Action queue

If you are evaluating Qdrant 1.19: make recall and endpoint compatibility release blockers. Storage savings are only useful if the lost rescoring margin fits the product's retrieval error budget.
If you are moving Milvus post-processing into the database: instrument data transferred, application CPU, p95 latency, and exact-versus-ANN result semantics. Do not merge the two aggregation modes into one correctness test.
If a MySQL workload is showing retry storms or pool exhaustion: measure in-flight statements and queue wait before raising concurrency. Reproduce a burst with a bounded queue and a deliberate rejection threshold.
If you are choosing between engines: keep this week's evidence in three separate columns—storage footprint, post-search data movement, and transaction admission. The sources answer different questions and do not support one universal winner.

The practical lesson is unglamorous and measurable: reduce what each operation stores, reduce what the application has to pull back, or reduce how much work the storage engine must handle at once. Each lever has a different correctness or latency bill; the next test should name that bill before the upgrade or migration begins.