DB Weekly: three PgBouncer CVEs, and the memory that sets your vector-search bill (2026)

This weekly brief covers database engine changes, upgrade gates, and measured performance evidence for September 21, 2026 10:00 through September 28, 2026 10:00 (UTC-08:00).

Two items carry the week, and they sit at opposite ends of the production stack. PgBouncer, the connection pooler that fronts a large share of production PostgreSQL estates, released 1.26.0 with three CVEs, two of which an attacker can trigger without presenting a credential 1. And the argument over what vector search costs moved from algorithms to memory: an analysis published this week put the per-vector arithmetic in numbers, while Weaviate's own releases halved the memory its HNSW index spends on graph nodes 2 3.

The rest of the week stays on the schedule. PostgreSQL 19 pulled four features on its way to the release candidate, MongoDB patched three drivers and lost its chief executive, and a Percona field report documented a schema change that stalled a whole Galera cluster for dozens of minutes 4 5 6 7.

The week at a glance

Date (UTC-08:00)	Engine / Component	Verified change	Upgrade gate & trade-off	Immediate action
2026-09-23	PgBouncer 1.26.0	Fixes CVE-2026-19888, CVE-2026-6668 and CVE-2026-6669, two of them triggerable by unauthenticated clients; tracks `search_path` and `default_transaction_read_only` by default; removes online restart (`-R`) 1	The two pre-auth bugs take down the whole pooler, which is single-threaded; the new default tracking changes behaviour for clients that `SET` those parameters under transaction pooling	Upgrade, and rehearse the removed `-R` path before an emergency restart needs it
2026-09-22 to 2026-09-25	Weaviate v1.38.17, v1.39.6, v1.39.7	HNSW vertex cut from 48 to 24 bytes per node; LSM store performance work; ACORN tombstone deadlock fix; RAFT boot-time race and async-replication fixes; filtered batch delete capped at `QUERY_MAXIMUM_RESULTS` 8	The vertex change is a memory-footprint cut on the hot index; the RAFT and replication fixes target crash and stall paths	Patch the branch you run; the vertex change takes effect on the next restart
2026-09-24	PostgreSQL 19 Beta 4	Four features pulled: SQL/PGQ, online data-checksum toggling, `FOR PORTION OF` temporal updates and deletes, `ALTER TABLE ... MERGE/SPLIT PARTITIONS` 4	Anything planned around those four leaves the 19 migration plan; release candidate in early October, GA possibly October	Re-scope 19 upgrade work
2026-09-24	PyMongo 4.18.2	Three CVEs: a bson buffer-size guard overflow, per-host decoding in connection strings, and a client-side field-encryption check on KMS endpoints 5	All three sit in the driver, one reachable from a supplied connection string	Patch Python services
2026-09-28	MongoDB Node.js driver 7.7.0	A failed OIDC token fetch no longer poisons the client: the token-fetch mutex held the failure, and every later operation on that `MongoClient` failed until the process restarted 9	Affects long-lived Node services on OIDC or Atlas auth; the rest is dependency bumps	Patch, or accept a restart-to-recover failure mode
2026-09-24	MongoDB C Driver 1.30.12, 2.5.5	Windows Secure Channel allocation fix; polled-stream handling in the single-threaded topology scanner 10 11	Maintenance only	Take with the next build
2026-09-28	MongoDB leadership	CEO Chirantan Desai left for Meta after less than a year; Dev Ittycheria returns as interim CEO; shares fell 18% in morning trading 6	A vendor-relationship signal with no product or support commitment attached to it	Weigh it when assessing vendor risk
2026-09-28	Percona XtraDB Cluster + pt-online-schema-change	A production schema change with a selective `--where` triggered Galera flow control and a cluster stall; adaptive chunk resizing grew one transaction to hundreds of thousands of rows 7	Schema migrations on clustered replication carry an availability trade-off	Add `--chunk-time=0` and `--max-flow-ctl=0` to selective `--where` runs
2026-09-25	PlanetScale architecture guidance	Postgres data files are not portable between x86-64 and ARM64, so a cluster's architecture is fixed at creation 12	New clusters only; resizing and adding replicas keep the architecture	Treat architecture as a migration-class decision

PgBouncer 1.26.0: three CVEs, two of them before authentication

PgBouncer 1.26.0 shipped on September 23, and the text of all three security fixes is worth reading before the upgrade goes on a calendar 1.

CVE-2026-19888 is the oldest. PgBouncer before 1.26.0 did not check that the SCRAM client-final-message contained a nonce, and an unauthenticated remote attacker could crash it by sending a client-final-message without one. The bug also applies to users that do not exist, because PgBouncer runs a mock SCRAM exchange for those. It has been present since SCRAM support was added in PgBouncer 1.11.0, which puts it inside every deployment that has tracked modern releases for the last several years 13.

CVE-2026-6668 is an integer overflow in the packet buffer growth logic that put PgBouncer into an infinite loop. Triggering it required sending a large amount of data into a single packet buffer, which is possible without authenticating first when max_packet_size sits at its default. PgBouncer is single-threaded, so the hang stopped it serving every client and every database until the process was killed. The blast radius is the pooler, which for most estates means everything behind it 13.

CVE-2026-6669 arrives from the other side of the connection. PgBouncer did not bound the SCRAM iteration count it accepted from a server, so a malicious or compromised PostgreSQL server could make the pooler perform an unbounded amount of work during a single login and starve all other clients for the duration. The accepted count is now capped at 1,000,000 13.

Three behaviour changes in the same release deserve a staging pass of their own. PgBouncer now tracks all parameters PostgreSQL reports by default, which brings search_path on PostgreSQL 18 and above and default_transaction_read_only on PostgreSQL 14 and above under tracking; before this release, a client running SET search_path or SET default_transaction_read_only = true in transaction pooling mode changed the session state of other clients that later used the same server connection. pool_idle_timeout is added to reclaim pools that have gone unused, disabled by default because removing a pool also removes its statistics. And query_wait_timeout can now be set per user and per database instead of only globally.

Two more changes tell you the release is a patch-as-code event rather than a drop-in. Online restart — the -R takeover path — is removed, together with the SHOW FDS and SUSPEND admin commands that existed only to support it; the documented replacement is a rolling restart with so_reuseport. PgBouncer also now sends its own ParameterStatus messages at login (pgbouncer.version, pgbouncer.pool_mode, pgbouncer.max_prepared_statements), so drivers and client libraries can detect the pooler and adapt their behaviour. A new client_login_count statistic in SHOW STATS makes connection churn measurable for the first time.

The fixes list carries a few more that matter in transaction pooling mode. Late COPY messages no longer exhaust the pool, which also makes COPY work outside an explicit transaction in that mode. SCRAM pass-through no longer corrupts the cached credentials of a forced user, and the pass-through failure introduced in 1.25.1 after a server reconnect is fixed. A use-after-free crash is closed for the case where a replication client disconnects while its server connection is still logging in, and a single replication client can no longer evict every idle server in the pool 13.

The gate is a network question. Two of these three bugs need only a client that can reach the pooler's port, so the audit that finds unpatched instances should also establish which of them listen outside a private network. The second gate is procedural: if the runbook or the on-call notes still reference -R for a restart without dropped connections, that step now fails.

Vector search is priced in memory

The Next Platform published an analysis on September 22 that gathered the published measurements on approximate nearest-neighbour search into one place, and its argument is arithmetic rather than architecture 2. An in-memory HNSW index costs about 1.1 × (4 × dimension + 8 × M) bytes per vector, where 4 × dimension is the float32 vector itself, 8 × M is the graph's per-node connection overhead, and the 1.1 is roughly ten percent slack. Dimensionality sets the hardware tier more than document count does, because that per-vector figure multiplies by everything you store.

What is measured	Published figure	Origin and source
In-memory HNSW footprint per vector	about `1.1 × (4 × dimension + 8 × M)` bytes	OpenSearch documentation, via 2
One million 1536-dimension float32 vectors	about 6.1 GB before graph overhead	text-embedding-3-large embeddings, via 2
Ten million 1536-dimension float32 vectors	roughly 60 GB, RAM-resident for predictable latency	via 2
HNSW index size against raw vectors	2–5×	via 2
IVFFlat index size against raw vectors	about 1.1×	via 2
HNSW recall moved from 95% to 100%	roughly 7× in throughput	Lucene benchmark discussion, via 2
int8 scalar quantization	about 75% memory cut, raw vectors kept on disk for rescoring	Lucene, via 2
Binary quantization	32× memory reduction	via 2
Qdrant binary quantization at 4× oversampling	0.98 recall@100 on 1536-dimension OpenAI embeddings	Qdrant, via 2
Elasticsearch Better Binary Quantization	138M × 1024-dimension dataset from about 535 GB to about 19 GB	Elasticsearch, via 2
DiskANN	one billion points on a single 64 GB machine plus SSD, 95+% recall, thousands of queries per second	Microsoft Research, via 2
Disk-based against in-memory search, p90 latency	96 ms against 24 ms	OpenSearch, via 2
Amazon S3 Vectors	target of up to 90% lower cost on large vector datasets	AWS, via 2

The levers that move the number are compression and tiering, and they apply the same way on every engine. Quantization shrinks each vector's footprint at a controlled cost in precision and is usually paired with a rescoring step that re-ranks the top candidates against full-precision vectors held on cheaper storage. Disk-based ANN keeps the bulk of the index on SSD with a compressed copy in memory, which is how DiskANN reaches a billion points on a 64 GB machine; the OpenSearch p90 figures above price that trade at four times the in-memory latency. Read together, the table is a capacity-planning instrument: what you are buying is bytes per vector at a chosen recall level, and the recall-versus-throughput curve is steep and non-linear 2.

Weaviate's releases this week are the same argument arriving from the vendor side. v1.38.17 and v1.39.6, both published September 22, carry a backported change to shrink the HNSW vertex from 48 bytes to 24 bytes per node, plus a rework that embeds the graph connections inside the vertex so each node costs one heap object instead of several 3 14. Halving per-node graph memory is the same lever the analysis measures from the outside, applied inside one engine.

The same two releases carry a batch of LSM store performance work: per-segment probe timing now costs nothing unless debug logging is on, keyword memtable entries are pointer-free with allocation-free writes, segment node readers are pooled and read metric names pre-joined, and map values sort without reflection. Correctness work rides along, including a fix for an ACORN seed loop deadlocking against delete and reset tombstones, a deduplicated ACORN entrypoint, and an index write that could land inside a semantic migration's swap window 3 14.

v1.39.7 followed on September 25 and is mostly cluster-reliability work. It closes a boot-time data race by publishing the raft node atomically, guards the bootstrap candidates map against concurrent notifies, and loads the atomic raft node at the FSM barrier call sites; async replication retries a panicking hashtree init attempt and gates its hashbeat on readiness; and a shared wait-group drain is replaced with a reuse-safe latch. On the client-facing side, filtered batch delete is capped at QUERY_MAXIMUM_RESULTS with the cap now exposed in the gRPC BatchDeleteReply, filter and document-id resolution run in parallel, BatchStream gets soft memory backpressure, and an invalid class name returns 422 or 404 instead of 500 or 403. Slow-query log lines now summarize storage lookup timings 15.

The gate for a reader is a capacity question. If the plan for a vector workload was sized by vector count, the arithmetic above says it was sized in the wrong unit; the vertex change in Weaviate is a reason to re-measure resident memory after the next restart 15.

PostgreSQL 19 Beta 4 took four features back out

The fourth beta arrived on September 24, and its headline is subtraction 4. Beta 4 reverts SQL/PGQ property graph query support, reverts online enabling and disabling of data checksums, reverts the FOR PORTION OF clause that provided temporal updates and deletes, and reverts ALTER TABLE ... MERGE PARTITIONS and ALTER TABLE ... SPLIT PARTITIONS. It also removes the pg_get_role_ddl(), pg_get_tablespace_ddl() and pg_get_database_ddl() functions, and reverts the change that forced LC_COLLATE to C in the postmaster process.

The announcement states the reason in the project's own words: "The PostgreSQL community strongly believes that, first and foremost, PostgreSQL must be reliable," and the features were removed so they can be considered for a later major release after more development and review. The practical reading for anyone tracking the 19 line is that two of the features Beta 1 announced in June as headline items — graph queries and the online checksum toggle — are now out of version 19, and a migration plan that assumed them has to be rebuilt on what actually ships 4.

Beta 4 also carries a long fix list from Beta 3, most of it in areas that changed for this release: the foreign-key check performance feature, the new REPACK command (crashes, invalid indexes and materialized views, permission and error reporting), the new WAIT FOR command (a deadlock and clearer isolation-level errors), an empty FOREIGN_JOIN list in pg_plan_advice, CREATE PUBLICATION ... EXCEPT, logical replication initial table synchronization from an older server to v19, logical replication conflict detection, and the new autovacuum scoring system including TOAST tables. A crash is fixed for the case where a partition's concurrent detach did not complete, the COPY FROM SIMD optimization is corrected, and pgbench --continue-on-error now reports failed transactions separately.

The schedule is unchanged and close. The release candidate is planned for early October, and the project says general availability may also occur in October, with the beta period still open to behaviour and API changes 4.

MongoDB: three driver patches and a departing chief executive

PyMongo 4.18.2, published September 24, is a bug-fix release carrying three CVEs 5. CVE-2026-96749 hardened the bson buffer size guard against signed integer overflow. CVE-2026-96748 fixed connection string parsing so each host is percent-decoded individually. CVE-2026-96747 makes client-side field level encryption reject a KMS endpoint ending in .sock. The second one is the one to reason about, because connection strings arrive from configuration and environment rather than from the wire, and the fix changes how multi-host strings are parsed.

The Node.js driver reached 7.7.0 on September 28 with one fix that changes how a service fails 9. A single failed OIDC token fetch — a cloud metadata endpoint timing out, for example — used to leave the driver's token-fetch mutex holding that failure. Every later operation on the affected MongoClient then failed with the original error and never attempted a new token fetch, and only restarting the process restored authentication. A failed fetch now affects only the operation that triggered it, and the OIDC callback lock is re-armed after a rejection. The rest of the release is dependency bumps: bson to 7.3.2, mongodb-connection-string-url to 7.0.2 and @mongodb-js/saslprep to 1.5.0.

The C driver shipped two maintenance releases on the same day. 1.30.12 fixes an allocation in the Windows Secure Channel path, and 2.5.5 fixes handling of polled streams in the single-threaded topology scanner 10 11.

No MongoDB server release landed in the window. The most recent wave — 8.3.11, 8.0.32 and 7.0.43 — published roughly September 17, just before it 16.

The week's larger MongoDB event has no version number on it. Reuters reported on September 28 that Meta recruited MongoDB chief executive Chirantan "CJ" Desai to run a new enterprise AI business, less than a year after he took the role from Dev Ittycheria, and that MongoDB appointed Ittycheria interim CEO while it searches for a permanent replacement; the shares fell 18% in morning trading 6. Brokerage Piper Sandler told Reuters it viewed the share-price reaction as overdone. For a team choosing or renewing a database, the leadership change adds a vendor-risk input that a support contract and a changelog do not price, while the release and support commitments in force today are unaffected. The story reached the front page of Hacker News the same morning 17.

A production schema change that stalled a Galera cluster

Percona published a field report on September 28 describing a customer engagement that went wrong in a way worth copying into your own runbook 7. The setting was a Percona XtraDB Cluster, a table of roughly a billion rows, and a pt-online-schema-change run adding an index with a selective filter: --where "created_at >= NOW() - INTERVAL 30 DAY". About 10 million rows matched; the other 990 million did not, and because created_at rose in step with the primary key, every matching row sat at the end of the clustered index. Percona XtraDB Cluster is Percona's MySQL-compatible cluster built on Galera replication, so every copied chunk leaves the writer as a write set that all nodes must certify and apply.

The mechanism is a feedback loop inside the tool. pt-online-schema-change continuously resizes its copy chunks to hold each one near --chunk-time, 0.5 seconds by default, shrinking them when chunks run slow and growing them when chunks run fast. Scanning the long run of rows the filter discarded, every chunk finished almost instantly, so the adaptive algorithm kept concluding that chunks were too small and kept growing them. When the scan finally reached the matching rows, one transaction copied hundreds of thousands of rows, and in the reported case that figure reached into the millions.

The consequences arrived in sequence. Large write sets lengthen Galera's certification phase and grow the apply queues, which activates flow control; once flow control starts, cluster throughput drops sharply and application commits begin to wait. On the writer node, InnoDB printed MY-014084 — threads unable to reserve space in the redo log because the log_checkpointer consumer was lagging behind, with a suggestion to raise innodb_redo_log_capacity — and the same message appeared on the other nodes during apply. The observable symptoms are the ones to alert on: a rising flow-control percentage, a growing wsrep_local_recv_queue, replication lag between nodes, waiting application commits, and more frequent checkpoints on every node 7.

The outcome is stated plainly in the report: the schema change completed, but the impact on production traffic was severe, and the cluster had to be restarted after remaining locked for dozens of minutes.

The fix that removes the cause is to stop the tool from adapting. Setting --chunk-time=0 holds the chunk size fixed for the whole run, or you can set --chunk-size explicitly and leave --chunk-time out. Adding --max-flow-ctl=0 makes the tool pause copying at the first sign that any node has entered flow control and resume when the cluster recovers, which trades migration duration for cluster stability. Two secondary levers: --chunk-index can chunk on a secondary index whose ordering is uncorrelated with the filtered column, spreading matching rows across chunks, though a poorly chosen chunking index forces bad query plans; and the two-phase alternative is to delete the rows with pt-archiver first, then alter the table without a --where clause 7.

The gate is broader than this one tool. Any migration that copies a subset of a large table on a cluster with clustered replication can produce the same oversized write set, and the trade-off it exposes is migration speed against cluster availability.

Changing CPU architecture is a migration, not a resize

PlanetScale published guidance on September 25 on choosing aarch64 or x86-64 for a Postgres cluster, and the load-bearing fact is that the choice is permanent for that cluster 12. Postgres's on-disk files are not portable between the two architectures, so the usual move to new hardware — stand up a replica and promote it — fails, because a replica starts from a byte-for-byte copy of the primary's files and replays the write-ahead log rather than rebuilding the database. The worked example in the post is a signed-char mismatch: GCC and Clang default to signed char on x86-64 Linux and unsigned char on ARM64 Linux, so the byte 0xFF reads as −1 on one and 255 on the other, and pg_trgm's trigram ordering depends on char comparisons. Postgres addressed that specific case in version 18, per a linked mailing-list message, and other engine components can carry the same class of assumption.

What each architecture does better follows from how the cloud counts a vCPU. AWS Graviton and Google Axion, ARM server chips, do not hyperthread, so each vCPU is a whole core; that helps when many small queries arrive at once and leaves cores for parallel query workers and autovacuum. x86 server chips generally run at higher clock speeds, which helps a single CPU-bound query that does not use parallel workers. Vector-instruction width separates them for search workloads: AVX2 processes 256-bit vectors and AVX-512 extends that to 512 bits, while Graviton4 and Graviton5 use 128-bit vectors. TIN, PlanetScale's full-text search index, compares 256-bit page-level bitmaps, so it can intersect a page's worth of bits with one AVX2 AND; pgvector carries AVX-512 code for Hamming and Jaccard distance and falls back to general-purpose code on ARM 12.

If you do decide to switch, the move is a migration rather than a resize: create the tables and indexes on the new cluster and copy rows with logical replication, so the destination builds its own index entries under its own comparison rules. PlanetScale's own guidance is ARM as a default for ordinary reads and writes, x86 when a few CPU-heavy queries dominate the workload, and, if performance is the reason for the choice, running the real workload on both before committing at the concurrency you expect during peak.

What the window did not settle

No PostgreSQL core or supported-branch release. The news archive for the window holds only PostgreSQL 19 Beta 4 for the 19 line, and the supported-branch baseline remains the August 13 patch set 18.
No Oracle MySQL server or component release. The most recent entry in the announcements feed is still the August 25 release matrix, so MySQL-family coverage this week rests on Percona's fork material 19.
No Milvus release. The newest tag is 3.0.2, published September 20, inside the previous window 20.
No Qdrant release and no pgvector release. Qdrant's newest tag is 1.19.1 from September 4, and pgvector's changelog shows 0.8.6 from July 29 with 0.8.7 still unreleased 21 22.
No fresh matched cross-engine benchmark. The two benchmark-shaped items this week are the analysis above, which synthesizes other organizations' published measurements and ran no harness of its own 2, and a vendor comparison that extends last week's TIN material: TIN counted 1,054,718 matches for the partial query "to b" and ranked the top 30 in 11 ms on a three-node cluster, against about 3.6 seconds and an estimated 3,400 results for show hn on the application it was forked from, with monthly cost of $609 against $5,186 23. Both are scoped to one engine family, and neither placed separate engines on shared hardware.
No named source-to-target engine migration with a measured outcome. The week's production case is a schema migration on a MySQL-family cluster 7, and the week's resharding guidance cites Slack's move from workspace-keyed to channel-keyed sharding, an outcome Slack reported in its own engineering posts years before this window 24.
No CMU Database Group talk inside the window. The Fall 2026 series' September 28 slot, a talk from the testing company Antithesis, starts at 4:30 p.m. ET on the closing day, after the window ends 25.
The monthly popularity table sits outside the window. DB-Engines published its September table at the start of the month, on its own monthly schedule.

One more item belongs on this list as context. A Hacker News thread on Postgres's at time zone 'UTC' semantics reached 136 points on September 26, which is community signal about a correctness footgun rather than any engine's change, and it is worth reading on its own terms 26.

Cross-engine positioning

The one cross-event judgment the week supports is about where the exploitable surface sat. PgBouncer is a separate process that terminates client connections and forwards them to PostgreSQL; PyMongo is a driver compiled into the application. Both sit outside the engine, and both shipped fixes this week for defects reachable from the network: two of PgBouncer's three bugs need no credential at all, one of PyMongo's arrives through a connection string, and another through a bson payload 1 5. What binds these two into one observation is that both occupy the same position in a deployed system — the settled infrastructure between an application and its data, which is exactly the layer that gets audited least often and patched least urgently.

Under that, the standing positions moved in two directions. PostgreSQL 19's feature set is now narrower than it was in June, because four items announced with Beta 1 are out of the release and the release candidate lands in early October 4. Vector stores, meanwhile, are competing on memory management now that every one of them ships an approximate index: Weaviate cut per-node graph memory, Qdrant's releases have centred on quantized storage, pgvector's advantage sits in x86 vector kernels, and the week's analysis argues the practical consequence is that a buyer compares bytes per vector and a recall-versus-latency curve at a fixed memory budget 2 3 12.

Two further positions are worth noting without a version attached. PlanetScale continued publishing architecture and operations material for Neki, its sharded Postgres, covering resharding strategy and CPU-architecture choice, with no engine release in the window; the usable output for a reader is a set of decision criteria rather than a version to install 12 24. And MongoDB heads into October with an interim chief executive and a single-day share move of 18%, which changes how a buyer weighs vendor stability without changing a line of the drivers reviewed above 6.

Action queue

Patch PgBouncer to 1.26.0 wherever a pooler can be reached by an unauthenticated client, and stage the two behaviour changes — the default tracking of search_path and default_transaction_read_only, and the removal of -R — before either is needed in an incident.
Move OIDC-authenticated Node services to the MongoDB Node.js driver 7.7.0, and Python services to PyMongo 4.18.2.
Re-scope PostgreSQL 19 upgrade work: SQL/PGQ, FOR PORTION OF, online checksum toggling and partition split and merge are not in 19.
Re-size vector capacity from bytes per vector at your target recall, and re-run the recall-versus-latency test at the memory budget you intend to buy.
Add --chunk-time=0 and --max-flow-ctl=0 to any pt-online-schema-change run that filters with a selective --where on a cluster with clustered replication.
Treat CPU architecture as a migration-class decision on any new Postgres cluster, and test the real workload on both before committing.

References

1
PgBouncer 1.26.0 released - Fixes three CVEs
postgresql.org
2
Vector Search Is Now A Data Type, But The Money Math Has Not Gone Away
nextplatform.com
3
Release v1.38.17 - LSM store performance improvements
github.com
4
PostgreSQL 19 Beta 4 Released!
postgresql.org
5
PyMongo 4.18.2 Released
mongodb.com
6
Meta taps MongoDB CEO Desai to drive enterprise AI push
reuters.com
7
When pt-online-schema-change "where" Meets Galera
percona.com
8
Weaviate releases\
github.com
9
MongoDB NodeJS Driver 7.7.0 Released\
mongodb.com
10
MongoDB C Driver 1.30.12\
mongodb.com
11
MongoDB C Driver 2.5.5\
mongodb.com
12
When to choose x86-64 vs aarch64\
planetscale.com
13
PgBouncer changelog
pgbouncer.org
14
Release v1.39.6 - LSM store performance improvements, HNSW ACORN & HFresh index Fixes
github.com
15
Release v1.39.7 - RAFT boot-time race, async replication and batch delete Fixes
github.com
16
MongoDB Server Releases
mongodb.com
17
Hacker News: MongoDB CEO resigns to join Meta
news.ycombinator.com
18
PostgreSQL News Archive
postgresql.org
19
MySQL Forums Announcements
forums.mysql.com
20
Milvus releases
github.com
21
Qdrant releases
github.com
22
pgvector changelog
github.com
23
TIN Postgres search is faster, better, and cheaper
planetscale.com
24
Handling hot shards
planetscale.com
25
CMU Database Group Fall 2026
db.cs.cmu.edu
26
Hacker News: Footguns with Postgres "at time zone 'UTC'"
news.ycombinator.com

This weekly brief covers database engine changes, upgrade gates, and measured performance evidence for September 21, 2026 10:00 through September 28, 2026 10:00 (UTC-08:00).

The week at a glance

Date (UTC-08:00)	Engine / Component	Verified change	Upgrade gate & trade-off	Immediate action
2026-09-23	PgBouncer 1.26.0	Fixes CVE-2026-19888, CVE-2026-6668 and CVE-2026-6669, two of them triggerable by unauthenticated clients; tracks `search_path` and `default_transaction_read_only` by default; removes online restart (`-R`) 1	The two pre-auth bugs take down the whole pooler, which is single-threaded; the new default tracking changes behaviour for clients that `SET` those parameters under transaction pooling	Upgrade, and rehearse the removed `-R` path before an emergency restart needs it
2026-09-22 to 2026-09-25	Weaviate v1.38.17, v1.39.6, v1.39.7	HNSW vertex cut from 48 to 24 bytes per node; LSM store performance work; ACORN tombstone deadlock fix; RAFT boot-time race and async-replication fixes; filtered batch delete capped at `QUERY_MAXIMUM_RESULTS` 8	The vertex change is a memory-footprint cut on the hot index; the RAFT and replication fixes target crash and stall paths	Patch the branch you run; the vertex change takes effect on the next restart
2026-09-24	PostgreSQL 19 Beta 4	Four features pulled: SQL/PGQ, online data-checksum toggling, `FOR PORTION OF` temporal updates and deletes, `ALTER TABLE ... MERGE/SPLIT PARTITIONS` 4	Anything planned around those four leaves the 19 migration plan; release candidate in early October, GA possibly October	Re-scope 19 upgrade work
2026-09-24	PyMongo 4.18.2	Three CVEs: a bson buffer-size guard overflow, per-host decoding in connection strings, and a client-side field-encryption check on KMS endpoints 5	All three sit in the driver, one reachable from a supplied connection string	Patch Python services
2026-09-28	MongoDB Node.js driver 7.7.0	A failed OIDC token fetch no longer poisons the client: the token-fetch mutex held the failure, and every later operation on that `MongoClient` failed until the process restarted 9	Affects long-lived Node services on OIDC or Atlas auth; the rest is dependency bumps	Patch, or accept a restart-to-recover failure mode
2026-09-24	MongoDB C Driver 1.30.12, 2.5.5	Windows Secure Channel allocation fix; polled-stream handling in the single-threaded topology scanner 10 11	Maintenance only	Take with the next build
2026-09-28	MongoDB leadership	CEO Chirantan Desai left for Meta after less than a year; Dev Ittycheria returns as interim CEO; shares fell 18% in morning trading 6	A vendor-relationship signal with no product or support commitment attached to it	Weigh it when assessing vendor risk
2026-09-28	Percona XtraDB Cluster + pt-online-schema-change	A production schema change with a selective `--where` triggered Galera flow control and a cluster stall; adaptive chunk resizing grew one transaction to hundreds of thousands of rows 7	Schema migrations on clustered replication carry an availability trade-off	Add `--chunk-time=0` and `--max-flow-ctl=0` to selective `--where` runs
2026-09-25	PlanetScale architecture guidance	Postgres data files are not portable between x86-64 and ARM64, so a cluster's architecture is fixed at creation 12	New clusters only; resizing and adding replicas keep the architecture	Treat architecture as a migration-class decision

PgBouncer 1.26.0: three CVEs, two of them before authentication

PgBouncer 1.26.0 shipped on September 23, and the text of all three security fixes is worth reading before the upgrade goes on a calendar 1.

Vector search is priced in memory

What is measured	Published figure	Origin and source
In-memory HNSW footprint per vector	about `1.1 × (4 × dimension + 8 × M)` bytes	OpenSearch documentation, via 2
One million 1536-dimension float32 vectors	about 6.1 GB before graph overhead	text-embedding-3-large embeddings, via 2
Ten million 1536-dimension float32 vectors	roughly 60 GB, RAM-resident for predictable latency	via 2
HNSW index size against raw vectors	2–5×	via 2
IVFFlat index size against raw vectors	about 1.1×	via 2
HNSW recall moved from 95% to 100%	roughly 7× in throughput	Lucene benchmark discussion, via 2
int8 scalar quantization	about 75% memory cut, raw vectors kept on disk for rescoring	Lucene, via 2
Binary quantization	32× memory reduction	via 2
Qdrant binary quantization at 4× oversampling	0.98 recall@100 on 1536-dimension OpenAI embeddings	Qdrant, via 2
Elasticsearch Better Binary Quantization	138M × 1024-dimension dataset from about 535 GB to about 19 GB	Elasticsearch, via 2
DiskANN	one billion points on a single 64 GB machine plus SSD, 95+% recall, thousands of queries per second	Microsoft Research, via 2
Disk-based against in-memory search, p90 latency	96 ms against 24 ms	OpenSearch, via 2
Amazon S3 Vectors	target of up to 90% lower cost on large vector datasets	AWS, via 2

PostgreSQL 19 Beta 4 took four features back out

MongoDB: three driver patches and a departing chief executive

No MongoDB server release landed in the window. The most recent wave — 8.3.11, 8.0.32 and 7.0.43 — published roughly September 17, just before it 16.

A production schema change that stalled a Galera cluster

Changing CPU architecture is a migration, not a resize

What the window did not settle

No PostgreSQL core or supported-branch release. The news archive for the window holds only PostgreSQL 19 Beta 4 for the 19 line, and the supported-branch baseline remains the August 13 patch set 18.
No Oracle MySQL server or component release. The most recent entry in the announcements feed is still the August 25 release matrix, so MySQL-family coverage this week rests on Percona's fork material 19.
No Milvus release. The newest tag is 3.0.2, published September 20, inside the previous window 20.
No Qdrant release and no pgvector release. Qdrant's newest tag is 1.19.1 from September 4, and pgvector's changelog shows 0.8.6 from July 29 with 0.8.7 still unreleased 21 22.
No fresh matched cross-engine benchmark. The two benchmark-shaped items this week are the analysis above, which synthesizes other organizations' published measurements and ran no harness of its own 2, and a vendor comparison that extends last week's TIN material: TIN counted 1,054,718 matches for the partial query "to b" and ranked the top 30 in 11 ms on a three-node cluster, against about 3.6 seconds and an estimated 3,400 results for show hn on the application it was forked from, with monthly cost of $609 against $5,186 23. Both are scoped to one engine family, and neither placed separate engines on shared hardware.
No named source-to-target engine migration with a measured outcome. The week's production case is a schema migration on a MySQL-family cluster 7, and the week's resharding guidance cites Slack's move from workspace-keyed to channel-keyed sharding, an outcome Slack reported in its own engineering posts years before this window 24.
No CMU Database Group talk inside the window. The Fall 2026 series' September 28 slot, a talk from the testing company Antithesis, starts at 4:30 p.m. ET on the closing day, after the window ends 25.
The monthly popularity table sits outside the window. DB-Engines published its September table at the start of the month, on its own monthly schedule.

Cross-engine positioning

Action queue

Patch PgBouncer to 1.26.0 wherever a pooler can be reached by an unauthenticated client, and stage the two behaviour changes — the default tracking of search_path and default_transaction_read_only, and the removal of -R — before either is needed in an incident.
Move OIDC-authenticated Node services to the MongoDB Node.js driver 7.7.0, and Python services to PyMongo 4.18.2.
Re-scope PostgreSQL 19 upgrade work: SQL/PGQ, FOR PORTION OF, online checksum toggling and partition split and merge are not in 19.
Re-size vector capacity from bytes per vector at your target recall, and re-run the recall-versus-latency test at the memory budget you intend to buy.
Add --chunk-time=0 and --max-flow-ctl=0 to any pt-online-schema-change run that filters with a selective --where on a cluster with clustered replication.
Treat CPU architecture as a migration-class decision on any new Postgres cluster, and test the real workload on both before committing.

References

1
PgBouncer 1.26.0 released - Fixes three CVEs
postgresql.org
2
Vector Search Is Now A Data Type, But The Money Math Has Not Gone Away
nextplatform.com
3
Release v1.38.17 - LSM store performance improvements
github.com
4
PostgreSQL 19 Beta 4 Released!
postgresql.org
5
PyMongo 4.18.2 Released
mongodb.com
6
Meta taps MongoDB CEO Desai to drive enterprise AI push
reuters.com
7
When pt-online-schema-change "where" Meets Galera
percona.com
8
Weaviate releases\
github.com
9
MongoDB NodeJS Driver 7.7.0 Released\
mongodb.com
10
MongoDB C Driver 1.30.12\
mongodb.com
11
MongoDB C Driver 2.5.5\
mongodb.com
12
When to choose x86-64 vs aarch64\
planetscale.com
13
PgBouncer changelog
pgbouncer.org
14
Release v1.39.6 - LSM store performance improvements, HNSW ACORN & HFresh index Fixes
github.com
15
Release v1.39.7 - RAFT boot-time race, async replication and batch delete Fixes
github.com
16
MongoDB Server Releases
mongodb.com
17
Hacker News: MongoDB CEO resigns to join Meta
news.ycombinator.com
18
PostgreSQL News Archive
postgresql.org
19
MySQL Forums Announcements
forums.mysql.com
20
Milvus releases
github.com
21
Qdrant releases
github.com
22
pgvector changelog
github.com
23
TIN Postgres search is faster, better, and cheaper
planetscale.com
24
Handling hot shards
planetscale.com
25
CMU Database Group Fall 2026
db.cs.cmu.edu
26
Hacker News: Footguns with Postgres "at time zone 'UTC'"
news.ycombinator.com

DB Weekly: three PgBouncer CVEs, and the memory that sets your vector-search bill

The week at a glance

PgBouncer 1.26.0: three CVEs, two of them before authentication

Vector search is priced in memory

PostgreSQL 19 Beta 4 took four features back out

MongoDB: three driver patches and a departing chief executive

A production schema change that stalled a Galera cluster

Changing CPU architecture is a migration, not a resize

What the window did not settle

Cross-engine positioning

Action queue

References

Related content

DB Weekly: three PgBouncer CVEs, and the memory that sets your vector-search bill

The week at a glance

PgBouncer 1.26.0: three CVEs, two of them before authentication

Vector search is priced in memory

PostgreSQL 19 Beta 4 took four features back out

MongoDB: three driver patches and a departing chief executive

A production schema change that stalled a Galera cluster

Changing CPU architecture is a migration, not a resize

What the window did not settle

Cross-engine positioning

Action queue

References

Related content