DB Weekly: MongoDB 9.0's new hard limits, and pgvector's IVFFlat bug
The September 28-October 5 brief turns MongoDB 9.0's new transaction and memory caps, a code-execution fix in pgvector, Pgpool-II's seven CVEs, and four measurement reports into concrete upgrade gates for backend teams.
The week from September 28, 2026 at 10:00 a.m. through October 5, 2026 at 10:00 a.m. (UTC-08:00) produced one major database release whose new server-side limits can surface as production errors, a code-execution fix in the most widely deployed vector extension, a seven-CVE patch for a popular PostgreSQL pooler, and four separate measurement reports with numbers attached. Neither the PostgreSQL project nor Oracle's MySQL team shipped a server release inside the window, so upgrade work for those two families stays where the previous brief left it.
Decision table
| Date (UTC-08:00) | Component | Verified change | Trade-off or gate | Immediate check |
|---|---|---|---|---|
| Sep 29 | MongoDB 9.0 | The 9.0 line is generally available, with patch entries for 9.0.1 and 9.0.2 dated September 28; 9.0.1 fixes CVE-2026-89099 12 | New refusal paths — TooManyOpenTransactions above 10,000 concurrent multi-document transactions, and ExceededMemoryLimit above 1 GB or 20% of server memory per operation — can appear as application errors after an upgrade | Stage long multi-document transactions and large aggregation sorts, then read the new serverStatus counters |
| Sep 29 | Milvus v2.6.25 | A new patch tag on the 2.6 branch; the release page says only that the release note is coming soon 3 | No feature or fix list is published yet, so no behaviour can be attributed to this tag | Watch the release-notes page before scheduling |
| Sep 30 – Oct 5 | Weaviate v1.40.0-rc.2, v1.39.9, v1.39.8 and v1.38.18 | The release candidate adds Namespaces (GA), schema-level vector-index drop (GA), HFresh MUVERA and 4-bit rotational quantization; the stable-branch patches repair write-ahead-log replay, Raft start-up, MMR normalisation, backup authorisation and PATCH re-vectorisation 4567 | The release candidate is pre-release software; the patch wave targets recovery and authorisation paths rather than a new feature boundary | Test MMR queries, PATCH re-vectorisation, backups and restart recovery on the branch you actually run |
| Oct 1 | pgvector 0.8.7 | Fixes a buffer overflow in IVFFlat index builds, CVE-2026-103484, that can lead to arbitrary code execution 89 | Every release through 0.8.6 carries the flaw; the exposure is a database role that can create an IVFFlat index | Upgrade, rebuild the index, and audit who holds index-creation rights |
| Oct 1 | Qdrant v1.19.2 | Speeds up sparse-posting upserts, persists proxy-segment state to stop WAL pinning, fixes HNSW builds that did not saturate their threads, fixes a filtered-search entry-point bug and Gridstore write tearing, and restricts the internal gRPC API to read-write keys 10 | Correctness and recovery fixes rather than a new feature boundary; the filtered-search fix can change how many results a query returns | Re-run filtered-search result parity and snapshot recovery on the pinned version |
| Oct 1 | Pgpool-II 4.7.3, 4.6.8, 4.5.13, 4.4.18 and 4.3.21 | Seven CVEs across the watchdog and certificate paths, including an authentication bypass that accepts a client certificate whose common name contains NUL bytes, and a watchdog promotion bypass 1112 | Every maintained branch is affected, and the pooler sits in front of the database on the client path | Upgrade each branch in use and restrict pooler network exposure |
MongoDB 9.0 caps concurrent transactions and per-operation memory
MongoDB announced the 9.0 line on September 29, and the release notes carry 9.0.0 alongside 9.0.1 and 9.0.2 patch entries dated September 28. 12 The patch entry for 9.0.1 fixes CVE-2026-89099 and describes the release as carrying security and reliability improvements. 2
The release notes matter more than the announcement for anyone planning an upgrade, because 9.0 adds two server-side limits that did not exist in the 8.x line.
The server now caps how many multi-document transactions external clients can hold open at the same time. The
maxConcurrentMultiDocumentTransactions parameter defaults to 10,000, and the server rejects a transaction that would exceed the cap with a TooManyOpenTransactions error. 2A single query operation now has a memory ceiling of 1 GB, or 20% of the memory available to the server process, whichever is greater. An operation that exceeds the ceiling fails with
ExceededMemoryLimit or QueryExceededMemoryLimitNoDiskUseAllowed. The 100 MB per-stage limit and the spill-to-disk behaviour of individual stages are unchanged, so the new cap sits above the old one rather than replacing it. 2Server-side JavaScript returns as a supported feature. MongoDB deprecated
$where, $function and $accumulator in 8.0; 9.0 re-enables them on a WebAssembly engine that the release notes describe as stronger sandboxing than the previous implementation. The functions remain unavailable on the ppc64le architecture. 2The release also expands observability. New
serverStatus counters cover change-stream pre-image purging, cursor batches and errors, and the release notes warn that two pre-image counters may report estimates when the server has no size information for the config.system.preimages collection. 2MongoDB's announcement leads with performance and operational claims: up to 35% faster baseline query performance, prefix, suffix and substring matching in Queryable Encryption, native OpenTelemetry integration, and Intelligent Workload Management, which queues operations and protects Atlas clusters during traffic spikes. 1 The announcement gives no hardware, workload or percentile behind the 35% figure, so treat it as a vendor claim to verify against your own query mix.
The transaction and memory caps are the two items most likely to change application behaviour on upgrade. A service that holds many long-document transactions open at once, or one that runs a large aggregation without
allowDiskUse, can start returning errors after the version change where the 8.x server would have kept going. Staging should reproduce both patterns on purpose and watch the new counters before rollout. 2pgvector 0.8.7 closes a code-execution path in IVFFlat builds
pgvector 0.8.7 appeared on October 1 and fixes a buffer overflow during IVFFlat index builds, tracked as CVE-2026-103484, that can lead to arbitrary code execution. The project's advisory states that every version through 0.8.6 is affected and encourages users to upgrade. 89
The exposure is narrower than "any connected user". The overflow happens during the index build, so a role that can create an IVFFlat index can reach it. Teams that let application roles own their own indexes, or that run multi-tenant databases where tenants can create indexes, gain the most from upgrading quickly. Teams whose indexes are built by a migration role with no untrusted writers have more room to schedule. 8
The 0.8.7 changelog also fixes an error in the
avg aggregate when no rows match. 9 Because the fix changes the code path that the previous version got wrong, rebuilding an IVFFlat index after the upgrade is the sequence that leaves the least on the table. 8Vector-engine repairs: Qdrant, Weaviate, and a Milvus tag with no notes
Qdrant v1.19.2, released October 5, is a maintenance release with an unusual amount of substance. Sparse-vector upserts no longer rewrite a full posting list on every write, which the release notes call significantly faster. Proxy segments now persist their state, which stops them pinning the write-ahead log and dragging out restart recovery. HNSW builds that did not saturate their assigned threads are fixed, filter identifiers resolve once per search request instead of repeatedly, and the collections lock is no longer held during a Raft snapshot, which previously blocked access to every collection. On the security side, the internal gRPC API accepts only read-write keys, and a startup warning fires when no API key is configured. 10
The correctness fixes in the same release matter as much as the performance work. A search could return zero results when the HNSW entry point did not satisfy the filter; named multivectors added to an indexed collection could break search; and writes to Gridstore storage could tear and corrupt data. 10 The filtered-search fix is the one to test for behaviour change, because a filter that previously matched nothing may now return the rows it should.
Weaviate shipped three stable-branch repairs and a release candidate across the same days. v1.39.8 and the parallel v1.38.18 repair MMR query-vector normalisation, fix the multi-tenant re-vectorisation check on PATCH, stop backup endpoints from exposing collections the caller cannot access, and break a commit-log crash loop that followed a kill during heavy writes. 67 v1.39.9, released October 5, adds write-ahead-log replay as a run of segments for faster LSM store recovery, fixes object-TTL deletion races, starts a single-node cluster without waiting for multi-node timeouts, and stops the HNSW index loading a node identifier far beyond the shard's document counter. 5 The v1.40.0-rc.2 release candidate, dated September 30, carries Namespaces and schema-level vector-index drop at general availability, plus HFresh MUVERA and 4-bit rotational quantization. 4
Milvus published a v2.6.25 tag on September 29 whose release page carries no note yet, so there is nothing to say about what it fixes and nothing to act on in it. 3
Pgpool-II's watchdog CVEs land on the client path
Pgpool-II shipped 4.7.3, 4.6.8, 4.5.13, 4.4.18 and 4.3.21 on October 1 with seven CVEs, and every maintained branch is affected. 11 Two are worth singling out for anyone who runs the pooler in front of a database.
CVE-2026-92868 is an authentication bypass. When a client connects with certificate authentication and the common name in its X.509 certificate contains a NUL byte, Pgpool-II fails to handle the name correctly, and a malicious client can connect as another user without a password. 11 CVE-2026-92873 lets an attacker who can send watchdog messages bypass the authentication-key check and promote a watchdog node of their choosing to leader. 11
The same release fixes a watchdog message that let an attacker write an arbitrary 32-bit value to an arbitrary memory address (CVE-2026-92867), an out-of-bounds array write (CVE-2026-92869), a stack corruption (CVE-2026-92870), a NULL-pointer dereference in inter-node authentication (CVE-2026-92871) and an information disclosure in the heartbeat receiver (CVE-2026-92872). 11
Pgpool-II sits between the client and PostgreSQL, so several of these flaws are reachable before a connection reaches the database, and the watchdog flaws matter most to clusters that use Pgpool-II for failover. The patch is a version bump on each branch plus a network-exposure review of the pooler itself. 12
What the numbers show
Four measurement reports landed in the window, each with a different scope limit. Read them for the ranges they cover rather than as a single ranking.
A MySQL thread pool pays off when threads outnumber cores
Percona ran sysbench OLTP read-write against Percona Server for MySQL 9.7.1-1 on an Intel Xeon Gold 6230 machine (two 20-core sockets, 80 logical CPUs, 187 GiB of RAM, NVMe), sweeping the thread-pool group count from 10 to 160 and the oversubscription from 2 to 4 against a one-thread-per-connection baseline. 13
In the I/O-bound configuration — 24 GB of data against a 2 GB buffer pool — the pool's effect is small until the connection count passes the CPU count, then it becomes decisive. At 2,560 client connections, the best pool setting held 2,304 transactions per second against 129 without the pool, a factor of 17.9. 13 The same report shows the pool losing ground when the data fits in memory: with a 32 GB buffer pool over the same 24 GB data set, the one-thread-per-connection configuration won at every connection count and all settings converged near 16,000 TPS. 13
The scope is one vendor's harness on MySQL-family servers, and the write-up analyzes Percona Server's implementation; a second part comparing it against MySQL Server 26.7.0 is still to come. The usable reading is that a thread pool covers a specific failure mode — thread counts far above what the cores can serve — and gives nothing back when the working set is already cached. 13
Two PostgreSQL text-search indexes keep trading benchmark wins
PlanetScale's TIN extension and ParadeDB's BM25 index have been trading benchmark results since mid-September, and ParadeDB's October 1 response adds new numbers to the exchange. 14 ParadeDB states plainly that TIN was at least 8× faster than ParadeDB 0.25 in every PlanetScale benchmark. 14
ParadeDB then describes two changes that closed the gap without adopting TIN's choice of document identifier. It moved each term's fieldnorm array next to that term's postings, which cut fieldnorm page accesses on a single-term query from about 1,500 pages to 30 at the cost of a 9% larger 28.7-million-document index. It also added a MAXSCORE path alongside the existing WAND pruning, cutting p50 latency by about 6× and p95 by about 8× on a ten-term disjunction and making it 2× faster than TIN on ParadeDB's own Hacker News dataset. 14
The post also argues that two settings in the original comparison favoured TIN: unqualified ParadeDB queries searched two indexed columns instead of one, and TIN's dense-term elision skipped scoring for terms appearing in more than 10% of the corpus. ParadeDB quantified the second as a correctness cost, reporting that with elision on, 47.8% of queries returned at least one result in the top ten that true BM25 would not, and 6.4% returned a top ten with no true top-ten result at all. 14
The scope is two index implementations inside PostgreSQL, on a StackExchange corpus of about 150 million documents and a 28.7-million-document Hacker News set, run by the vendors themselves. It does not measure PostgreSQL against another database, and the two vendors chose the queries, so read the methodology argument as carefully as the throughput. 14
A PostgreSQL backup can evict the cache it shares with queries
ClickHouse described how its managed PostgreSQL service changed the way
wal-g reads a database during a base backup. By default those reads pass through the Linux page cache, and a backup that streams hundreds of gigabytes through it forces the kernel to evict data PostgreSQL was holding warm. On a 48 vCPU box with four NVMe drives behind a RAID0 stripe and a 467 GB database under a live read workload, a buffered backup evicted all 40 GiB of a table that had been read into memory minutes earlier and was idle while the backup ran. 15Switching the backup to direct I/O stops the eviction but also drops the kernel's read-ahead, which on a striped array leaves drives idle. ClickHouse sizes each direct read to span the whole stripe — 4 MiB across four drives — and scales the reader count to the hardware, using the full vCPU count on what it calls dense NVMe families. On the same test box the direct-I/O backups evicted nothing and finished in 71 seconds, cut the latency hit queries took during the backup by about two thirds, and used about 14% less CPU. 15
The scope is one vendor's test box and one backup tool. The transferable parts are the two knobs — whether the backup reads through the page cache, and how wide each read is on a striped array — and the method of measuring query latency while the backup runs. 15
Storage latency splits the PostgreSQL commit tail under sustained load
Nirvana Labs, a storage vendor, published a benchmark of PostgreSQL commit latency against different storage configurations. The harness ran identical 4-vCPU, 16-GB machines with 256-GB volumes, and each checkpoint committed a PostgreSQL
INSERT with synchronous_commit on, a Redis write and a Qdrant upsert. 16The result reverses with load. At 10,000 checkpoints, Amazon io2-32k and gp3-16k held the lower per-operation commit tail, at 78–88 ms against 95–105 ms on Nirvana's ABS storage. At 100,000 checkpoints the order flipped: ABS held a PostgreSQL commit p99 of 105–107 ms in write mode and 79–82 ms in mixed mode, against 210–232 ms and 158–175 ms across the tested AWS configurations. The raw single-queue
fsync number went the other way, with io2 delivering the lowest measured latency. 16The headline number covers the whole three-service cycle rather than PostgreSQL alone, the vendor ran it on its own storage, and the report says so. The reusable idea is the split between the isolated
fsync floor and the sustained-load tail, and the advice to run long enough that a fixed IOPS ceiling starts to queue. 16Migration watch
The window's migration material is planning guidance rather than measured outcomes. The AWS Database Blog published a six-checkpoint decision tree for assessing whether a SQL Server Full-Text Search workload can move to Babelfish on Aurora PostgreSQL. It names the features with no equivalent — SQL Server's semantic search has no Babelfish counterpart — and separates what migrates directly, what needs a custom function and what needs an alternative such as native PostgreSQL
tsvector search or Amazon OpenSearch Service. 17A second AWS post covers moving an on-premises IBM Db2 database on z/OS to Aurora PostgreSQL with AWS DMS and a Db2 gateway server, including a full load with periodic refresh and a validation step. 18 Both posts describe how to run a migration and what to watch; neither reports a named organization's cutover, the time it took, or a measured before-and-after result, so this issue carries no production migration outcome.
Evidence boundary
The seven-day scan produced the following coverage limits.
- PostgreSQL core: the official news archive's newest project item is PostgreSQL 19 Beta 4, dated September 24 and therefore outside the window. No core or supported-branch release landed between September 28 and October 5. 19 This issue's PostgreSQL coverage rests on pgvector, Pgpool-II and a downstream Percona item.
- MySQL: the official announcements feed's newest release announcement still dated August 25, so no Oracle MySQL server or component release fell inside the window. 20 MySQL coverage rests on a Percona benchmark of a MySQL-family server.
- Milvus: v2.6.25 is tagged but undocumented, so the release carries no verifiable change. 3
- Benchmarks: no matched benchmark put separate database engines on shared hardware this week. The four reports here compare index implementations inside PostgreSQL, MySQL-family servers under one harness, and storage tiers under one vendor's test; each is labelled with its scope above.
- Migration case studies: no named source-to-target production migration with a measured outcome was verified. New routes tried this window — the AWS Database Blog and viral engineering write-ups surfaced through general search — produced planning guidance and an unrelated image-pipeline post, both recorded here so the next run does not repeat them.
- Conference talks: the CMU Database Group's Fall 2026 series ran a September 28 talk, "Everything Has Bugs. Here's How Antithesis Catches Them.", by Marco Primi of Antithesis. 21 The talk reviews property-based testing, deterministic simulation testing, chaos testing, fuzzing, mutation testing and differential testing, and walks through bugs Antithesis found in a Raft implementation, which underlies several databases. 21 It is a testing-method talk rather than a database-release item, and the series index lists the schedule. 22
- Hacker News: the front page at the time of the scan carried no database-selection or benchmark item, only general-interest stories and one database curiosity, so it supplied no material for this issue.
Cross-engine positioning
Db-Engines published its October ranking, and the movement worth noting is the gap between the two leading open-source relational systems. PostgreSQL gained 5.50 points to 688.75 while MySQL lost 6.85 to 837.96, so PostgreSQL closed about 12 points of the gap in a single month and now sits roughly 149 points behind MySQL. 23 The ranking measures popularity signals such as mentions, job postings and search interest, so this is a positioning shift rather than a performance result. The same table shows Databricks passing Redis for seventh place and Apache Cassandra entering the top ten at tenth, with Snowflake gaining 9.69 points. 23
Among dedicated vector engines the picture barely moves. Milvus holds 7.09 and Qdrant 7.06, which puts them within a few hundredths of a point of each other, while Weaviate gained the most of the three, 0.40 points, to 5.14. All three sit far below the multi-model search engines at the top of that ranking, Elasticsearch at 94.11 and OpenSearch at 22.72. 24
Supabase used its Select 2026 event, on October 2, to place three Postgres bets. Multigres, in private alpha, adds scalable connection pooling and automated multi-node failover by building on synchronous replication and a consensus protocol, so a replica is promoted in seconds without losing committed writes. 25 OrioleDB, now in public beta, replaces PostgreSQL's heap with an undo-log storage engine, removes the vacuum-driven bloat on hot tables and uses 64-bit transaction IDs; Supabase reports it delivering up to 1.8× higher throughput than the heap in TPC-C-derived benchmarks published at dbarena.com. 25
The third bet is dbarena itself, an open benchmark site that compares managed Postgres providers — Supabase, Amazon RDS and Google Cloud SQL at launch — on transactions per dollar, monthly cost, transactions per minute and p95, with the benchmark code and raw data published. 25 For a selection decision, dbarena is a new place to look for hosted-Postgres numbers that the vendor does not control alone; the OrioleDB figure, by contrast, is a vendor-run benchmark and reads as one.
Supabase also said on October 2 that it is acquiring Turso, the company that rebuilt SQLite in Rust for a cloud where one server manages millions of small databases. Supabase frames the buy around agent-created databases — it says it already launches more than a million databases a week — with Postgres as the scaling path and SQLite as the cheap on-demand option. 26
PlanetScale's October 1 engineering post on Neki describes how its sharded-Postgres router avoids work. Rather than decode every result into typed rows at the boundary, the router keeps the PostgreSQL wire-format bytes and walks message headers, decoding only the values routing needs — a shard key, a bind parameter, a join key — and passing the raw frames on when they can travel unchanged. 27 The trade-off is that a router that keeps protocol bytes has to know the wire format well enough to rewrite a query and its parameters in place; the payoff is less per-query work on the path between client and database. The post reports no benchmark, so it is a design note rather than a measurement.
Action queue
- pgvector: upgrade to 0.8.7, rebuild any IVFFlat index, and check which roles can create one. 8
- MongoDB: before any 9.0 upgrade, reproduce long multi-document transactions and memory-heavy aggregations, and wire the new
serverStatuscounters into dashboards. 2 - Pgpool-II: patch every branch in use and review which networks can reach the pooler. 11
- Qdrant: test filtered-search result parity and snapshot recovery after moving to v1.19.2. 10
- Weaviate: run MMR, PATCH re-vectorisation, backup and restart-recovery tests on the stable branch in production; treat v1.40 as a test-cluster candidate. 56
- MySQL sizing: if connection counts run far above core counts, test a thread pool against your own working-set size; expect no gain once the data is cached. 13
- Selection work: keep engine choices provisional until a matched cross-engine benchmark and a measured production migration appear; use dbarena for hosted-Postgres comparisons in the meantime. 25
References
- 1MongoDB 9.0 is Now Available
mongodb.com
- 2Release Notes for MongoDB 9.0
mongodb.com
- 3Release v2.6.25
github.com
- 4Release v1.40.0-rc.2
github.com
- 5Release v1.39.9
github.com
- 6Release v1.39.8
github.com
- 7Release v1.38.18
github.com
- 8pgvector 0.8.7 Released
postgresql.org
- 9pgvector CHANGELOG
github.com
- 10Release v1.19.2
github.com
- 11
- 12Pgpool-II release notes
pgpool.net
- 13
- 14
- 15
- 16
- 17
- 18
- 19PostgreSQL: News Archive
postgresql.org
- 20MySQL Forums - Announcements
forums.mysql.com
- 21Everything Has Bugs. How Antithesis Catches Them.
db.cs.cmu.edu
- 22
- 23DB-Engines Ranking
db-engines.com
- 24DB-Engines Ranking of Vector DBMS
db-engines.com
- 25
- 26Supabase is acquiring Turso
supabase.com
- 27Designing Neki for performance
planetscale.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.