DB Weekly: pgAdmin's auth bypass, and a four-engine PostgreSQL text-search benchmark (2026)

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

Two items carry the week. pgAdmin, the open-source client for PostgreSQL, fixed four vulnerabilities in its server mode, one of which let any client reaching it assert an administrator's identity without a credential 1. And a matched benchmark put four PostgreSQL text-search engines on one machine, one 85 GB corpus and one harness, the first measurement this brief has verified that places several engines side by side across workload shapes 2. The vector engines spent the week cutting contention out of their hot paths, and the Go client for Milvus reached a stable 3.0 with a breaking import path.

The week at a glance

Date (UTC-08:00)	Engine / Component	Verified change	Upgrade gate & trade-off	Immediate action
2026-09-17	pgAdmin 4 v9.18	Four CVE fixes, including a Webserver-mode authentication bypass and connection-string injection in the Backup, Restore and Maintenance tools 1	A client reaching a server-mode pgAdmin could assert any identity, an administrator's included; the Backup flaw could redirect the connection and the password exported in `PGPASSWORD`	Upgrade, or restrict header-asserted identity to named trusted proxies with a shared secret
2026-09-20	Milvus 3.0.2	Removed an atomic refcount hotspot in scalar filter evaluation measured at roughly 48% of leaf CPU time in search; added HTTP 429 with `Retry-After` on RESTful v2 DQL when the proxy query queue fills 3	Data-correctness fixes ride along: Storage V2 compaction could misalign packed column indexes, and an incomplete binlog chunk could be treated as fully read	Patch 3.0.x clusters, and teach clients to honour the 429 rather than retrying blindly
2026-09-16	Milvus 2.6.24	Lower peak memory during segment loading, knapsack-based force-merge planning, and a fix for strong-consistency queries failing with `channel tsafe stalled` under heavy upserts 4	The 2.6 branch receives the same hot-path work as 3.0, so staying on 2.6 remains a live option	Patch 2.6 deployments and re-run strong-consistency upsert tests on staging
2026-09-18	Milvus Go client v3.0.0	First stable 3.0 client: the module path moves to `client/v3`, protobuf types move to `milvus-proto/go-api/v3`, and `ExportSnapshot` returns a job ID instead of a path 5	Breaking at the import and type level; client telemetry is on by default; the release states no guaranteed compatibility with Milvus 2.6 servers	Upgrade the cluster before the client, and make the telemetry decision explicit
2026-09-14 to 2026-09-18	Weaviate v1.37.17, v1.38.15, v1.38.16, v1.39.5	One repair set across three branches, then a further batch: shifted `weaviate_module_error_total` labels, a qna-openai nil-response panic, a tombstoned HNSW entrypoint, orphaned schema class data 6 7	v1.38.16 removes the `/v1/modules` endpoint and the contextionary extension handlers	Check for `/v1/modules` callers first, then patch the branch you run
2026-09-19	Weaviate v1.40.0-rc.1	Release candidate carrying Namespaces GA, alter-schema drop-vector-index GA, HFresh MUVERA, and 4-bit rotational quantization 8	Pre-release: the feature set is frozen, the build is not	Read it for roadmap planning only
2026-09-16	PlanetScale TIN v1.0.2	Matched benchmark of four PostgreSQL 18.6 text-search engines on one instance: TIN, ParadeDB 0.25.2, pg_textsearch 1.4.0, and the built-in GIN index 2	Scope-limited to text search on a standalone single node, and the winning index ships on one managed platform	Calibrate expectations from the numbers, and price the platform dependency as part of the choice
2026-09-21	PostgreSQL logical replication slots	Documented failure mode: promoting a replica whose logical slots are not synchronized drops the change stream for every downstream consumer 9	The fix needs `failover = true` on each slot plus `hot_standby_feedback` and `sync_replication_slots` on, and that pair pins the primary's vacuum horizon	Audit CDC slots before the next planned failover
2026-09-21	Percona Server for MySQL 9.7.2-2	`DISTANCE()` and its `VECTOR_DISTANCE()` alias added with five distance metrics and runtime SIMD dispatch 10	Scoring without an approximate index turns an ordered similarity query into a full table scan	Use it on small or pre-filtered sets; wait for ANN indexing before redesigning retrieval
2026-09-15	Percona Server for MySQL 8.4.11-11	InnoDB buffer-pool work: narrowed LRU mutex scope on page reads, per-buffer-pool LRU manager threads, and a fixed inverted old/young check 11	A fork-only gain at present, and the same high-thread-count degradation is reported in upstream MySQL 8.4.11	Benchmark at your peak thread count before you schedule the upgrade

pgAdmin 4 v9.18: four vulnerabilities in the tool that reaches production

pgAdmin 4 v9.18 arrived on September 17 with 29 fixes and features, four of them security fixes tracked as CVE-2026-86861 through CVE-2026-86864 1. Server mode is the deployment several engineers share, and it is the one these flaws expose.

CVE-2026-86863 is the authentication bypass. In Webserver authentication mode a reverse proxy or identity provider hands pgAdmin a verified username through the WSGI environment, and the flawed get_user() fell back to reading the WEBSERVER_REMOTE_USER name from inbound request headers whenever that value was missing. A header is written by whoever sends the request, so any client able to reach pgAdmin could assert any identity, an administrator's included, without a credential. The fix makes header-asserted identity opt-in and limits it to a configured list of trusted proxies with an optional shared secret 12.

CVE-2026-86864 and CVE-2026-86862 are argument and connection-string injection. In the Backup tool the client-supplied database name was appended to the pg_dump argument vector as a bare positional value; because getopt_long permutes arguments, a value beginning with a dash could supply options such as --file and override the storage-confined output path, and because libpq expands a database name containing an equals sign into a full connection string, the same field could redirect the connection and the password exported in PGPASSWORD to a host of the caller's choosing. The name now travels through PGDATABASE, which libpq never expands, and the Restore and Maintenance tools received the same treatment for the value they passed to --dbname. CVE-2026-86861 closes a time-of-check to time-of-use gap in the File Manager's save_file endpoint behind the Query Tool: the path was validated and then opened with a plain open(), so a symbolic link planted between the two steps was followed and the write landed outside the user's storage directory 12.

The same release hardens two defaults: inline scripts now run under a per-request nonce instead of a blanket 'unsafe-inline' with 'unsafe-eval', and LLM API requests refuse HTTP redirects rather than following a Location header to a destination the allowlist never examined 12. Because the exposure is a network-reachable instance, the audit that finds unpatched copies should also confirm which of them are reachable from outside a private network.

Milvus: two patches on separate hot paths, and a client that breaks its import path

Milvus 3.0.2, released September 20, is a performance release with correctness fixes attached; Milvus 2.6.24, released September 16, is a resource-efficiency release for the previous branch 13.

Milvus 3.0.2 removed an atomic reference-count hotspot in the scalar filter evaluation path that the release notes put at roughly 48% of leaf CPU time in search, and cut the same per-chunk overhead on the search path by pinning a sealed-segment snapshot once per request 3. Filtered search is where most production vector workloads sit, since a query carrying a tenant or category filter pays for scalar evaluation on every candidate batch. The correctness fixes are what make the patch worth scheduling: Storage V2 compaction could drop valid physical group paths and misalign packed column indexes in compacted segments, an incomplete binlog chunk could be treated as fully read, queries could return incorrect results after a struct array field was dropped and re-added, and compaction logs could print collection encryption keys and object storage credentials 3. That last finding turns a routine patch into a log-retention and rotation task.

Milvus 2.6.24 makes the case for staying on the 2.6 branch. Segment loading now estimates memory at batch level, bounds column-group temporary memory and streams V3 index loading, which the release describes as substantially lowering peak memory, and force-merge planning moved to multi-round knapsack packing so merged segments track their configured target size. It also fixes strong-consistency queries returning channel tsafe stalled (error code 505) under heavy upsert workloads by isolating online write execution from segment loading on the query node, and stops a replica's channels from all landing on one query node and causing repeated out-of-memory kills 4.

The Milvus Go client reached version 3.0.0 on September 18 as a stable release for Milvus 3.0, and it states plainly that it is not guaranteed compatible with Milvus 2.6 servers 5. Three changes break a build: imports move to client/v3, applications using generated Milvus messages must migrate from milvus-proto/go-api/v2 to v3 because the two protobuf type sets are not interchangeable, and ExportSnapshot returns an int64 job ID instead of a snapshot path, so callers poll GetExportSnapshotState for progress. Client telemetry is also enabled by default, collecting request counts, errors, latency including p99, heartbeats and server-pushed commands, and ClientConfig.TelemetryConfig.Enabled set to false turns it off — a governance decision for regulated deployments and easier to settle while the dependency is open for the import-path change.

Weaviate: one repair set across three branches, and 1.40.0 at the gate

Weaviate's week was maintenance plus a preview. Between September 14 and September 18 the project published v1.37.17 and v1.38.15 on the same day, v1.39.5 the following morning, and v1.38.16 on September 18 6 7 14 15.

Reading the first three together is more useful than reading them one at a time, because the overlap is the signal. All three carry the fix for shifted weaviate_module_error_total labels and the nil-response panic in the qna-openai module, so monitoring built on that counter has been misattributing module errors on every affected branch; they also carry node-level query admission control, tolerance for an HNSW entrypoint whose node slot was nil, and schema handling that drops class data the schema no longer names 7 15. The one change that can break a running deployment is the removal of the /v1/modules REST endpoint and the contextionary extension and concept handlers in v1.38.16, which start returning errors to any health probe, inventory script or older client wrapper still calling them 6.

The 1.40.0 line stays out of production planning. Release candidates v1.40.0-rc.0 and v1.40.0-rc.1 both carry Namespaces at general availability, alter-schema drop-vector-index at general availability, HFresh MUVERA and 4-bit rotational quantization, with the feature set frozen and the build not 8 16. The list is worth reading this week for one question: whether dropping a vector index without a rebuild, or moving to 4-bit quantization, changes a capacity plan the reader currently holds.

The benchmark: four PostgreSQL text-search engines on one machine

On September 16, PlanetScale published TIN, a full-text search index for PostgreSQL, with a benchmark against the other text-search indexes available for PostgreSQL: ParadeDB 0.25.2, pg_textsearch 1.4.0, and the GIN index built into PostgreSQL 18.6 2. The publisher sells the platform TIN runs on, which is a bias to hold in view; the methodology is detailed enough to check.

All four ran inside an isolated container limited to 8 vCPUs and 32 GB of RAM on an AWS i7i.8xlarge instance with local NVMe storage, on PostgreSQL 18.6, with shared_buffers and maintenance_work_mem each at 24 GB and max_parallel_workers at 8. Traffic came from a forked build of the ParadeDB Benchmarker, modified to pre-warm before measurement and to add bytes-read and WAL-bytes metrics, running on the same instance. The corpus was a Stack Exchange question-and-answer export of 85 GB across 150 million documents, queried with 3,762 generated substrings of two to fifteen terms, each read as a conjunction, a disjunction, and a phrase 2.

Building an index over that corpus separated the engines before any query ran, and the build's memory demand is a real column rather than a footnote: the three engines other than TIN failed at the container's 32 GB, so builds were given the extra memory below and the container returned to 32 GB before query measurement began 2.

Index	Total build time	Index size	RAM required for the build
TIN 1.0.2	8m10s	50.7 GB	32 GB
ParadeDB 0.25.2	19m20s	52.1 GB	64 GB
pg_textsearch 1.4.0	26m49s	41.5 GB	128 GB
PostgreSQL GIN (18.6)	2h09m04s	28.0 GB	64 GB

Query results, on the 85 GB corpus and on an 8.0 GB Wikipedia extract where the index fits in shared buffers:

Workload	Engine	QPS	p99 latency	MB read per query	Updates completed in the run
Mixed conjunction, disjunction and phrase, top-10 by BM25, read-only	TIN	199	256 ms	65	—
Same workload, with a concurrent writer	TIN	172	284 ms	88	271,398
Same workload, with a concurrent writer	ParadeDB	6.0	7,990 ms	591	193,487
Conjunction and phrase, top-10, read-only	TIN	242	212 ms	73	—
Conjunction and phrase, top-10, read-only	ParadeDB	24	1,279 ms	668	—
Conjunction and phrase, top-10, read-only	GIN (18.6)	0.4	288,066 ms	595	—
Disjunction, top-10, with a concurrent writer	TIN	125	354 ms	77	270,279
Disjunction, top-10, with a concurrent writer	ParadeDB	2.2	12,634 ms	394	185,584
Disjunction, top-10, with a concurrent writer	pg_textsearch	3.5	8,409 ms	11,656	735
Count of matches, disjunction, Wikipedia extract, index resident	TIN	10,260	2 ms	1.7	—
Count of matches, disjunction, Wikipedia extract, index resident	ParadeDB	291	95 ms	22	—
Count of matches, disjunction, Wikipedia extract, index resident	GIN (18.6)	1.4	30,292 ms	2.5	—

Two features of that table carry more than the headline ratios. Two engines could not finish the mixed workload at all, because GIN exhausted memory performing disjunction searches and pg_textsearch handles only disjunction queries, and a benchmark line ending in an engine that could not complete locates the workload shape where a choice stops being available 2. The concurrent-writer rows then say what the read-only rows hide: pg_textsearch held 3.5 QPS for readers with and without writes and completed 735 updates in ten minutes against TIN's 270,279, which is what read traffic preventing write traffic from acquiring locks looks like from the outside.

Four boundaries decide whether any of this applies to a given reader.

Vendor-authored, on a single node. PlanetScale publishes the benchmark for the index it also sells, on a standalone instance with replication and operational overhead excluded as a reproducibility aid 2.
Text search only. Every number measures full-text indexing, with no joins and no mixed read-and-write traffic beyond one updating client, so a workload that also needs transactional reads on the same table gets an answer for its search half.
Four indexes inside one database version. The result speaks to where text search belongs inside a relational store and compares PostgreSQL's indexed search against nothing outside PostgreSQL.
The winner ships in one place. TIN is generally available for PlanetScale's Postgres and Neki databases; a team that wants these numbers on its own hardware has to weigh a platform move, and that cost appears in no column above. PlanetScale followed with Lead the next day, a feature-equivalent version of TIN that runs in continuous integration 17.

The cutover gate: logical replication slots on a promoted primary

PlanetScale's September 21 post works through what happens to PostgreSQL logical replication slots during a replica promotion, and its argument is that PostgreSQL's own defaults assume the reader has none 9.

Logical slots decode the write-ahead log into per-row change events for external subscribers such as a search index, an analytics store or a queue. A replica can be promotion-ready by every ordinary measure, connected and caught up with zero lag, and still lack a usable copy of those slots; promotion then proceeds, the database looks healthy, and the change stream breaks, with consumers missing every event since their last acknowledgement or stalling until someone takes a fresh snapshot. The fix needs failover = true on every logical slot at creation or through ALTER_REPLICATION_SLOT ... (FAILOVER true), the platform told each slot's name so it survives on the replica, and hot_standby_feedback and sync_replication_slots both on 9. Those last two are off by default for a reason, and the reason is the trade-off: hot_standby_feedback lets a replica pin the primary's vacuum horizon for correctness and adds bloat to the primary, while turning sync_replication_slots on without it means the copied slot state can be invalidated the first time vacuum runs past the slot's horizon. A team with long-running read transactions against replicas is choosing between a safer change stream and a heavier vacuum. The post also notes that the operator detects misconfigured slots and blocks planned cutovers that would drop one, then releases a blocked cutover after a grace period, which buys time to fix the configuration rather than removing the failure.

The same week brought a longer piece on the internals of Neki, PlanetScale's sharded PostgreSQL product, whose Replicator imports tables from an external PostgreSQL instance and buffers queries through the same mechanism that handles a primary change 18. One detail transfers to any sharded deployment: PostgreSQL tracks objects by OID rather than by name, a client may cache a column's type OID from the wire, and independent shards can assign a custom type different OIDs, so the design designates one shard as authoritative for translating them across the cluster.

MySQL: vector scoring arrives in a community fork, with a full-scan caveat

Oracle published no MySQL server release during the window; the official announcements feed still ends at the August 25 train of MySQL Server 26.7.1, 9.7.3 and 8.4.12, so the server baseline is the same one the previous issues reported 19. MySQL's movement this week came from Percona instead.

On September 21 Percona documented DISTANCE() and its VECTOR_DISTANCE() alias in Percona Server for MySQL 9.7.2-2, which scores two vectors directly in SQL with five metrics: EUCLIDEAN, EUCLIDEAN_SQUARED, MANHATTAN, COSINE and DOT 10. MySQL's native DISTANCE() and VECTOR_DISTANCE() functions exist only in HeatWave MySQL on OCI and cover three metrics, so adding the primitive to a server that runs anywhere widens where the capability is available and adds squared Euclidean and Manhattan distance. Distance evaluation dispatches at startup to the best SIMD tier the CPU offers, with the vendor reporting roughly 2–3×, 4–6× and 8–12× speedups over scalar at the SSE4.2/NEON, AVX2 and AVX-512F tiers — SIMD-tier claims rather than end-to-end query measurements. The same post states the caveat that decides how far the feature goes: without an approximate-nearest-neighbour index, ORDER BY DISTANCE(...) LIMIT k over a large table is a full table scan, correct and vectorized per row and still linear in table size, with HNSW and IVF named as the next milestone 10.

The second Percona item is an upgrade consideration for InnoDB. On September 15 Percona published the work inside Percona Server 8.4.11-11, which narrows the scope of the buffer-pool LRU mutex during physical page reads so only the LRU list insertion is serialized, restores per-buffer-pool LRU manager threads so queries stop doing eviction work inline, and fixes an inverted old/young check that made the background flusher rescan the same pages 11. Percona reports that on a host with 40 cores and hyperthreading, throughput keeps rising to 64 threads and that 8.4.11-11 avoids the abrupt high-thread-count degradation seen in 8.4.8 and 8.4.10, with a similar degradation reported in upstream MySQL 8.4.11. The figures are Percona's own, and the actionable part is the shape of the curve: a team whose MySQL boxes run well past their core count should measure that region before scheduling a minor-version upgrade.

MongoDB: driver maintenance only

MongoDB's engine moved nowhere this week, and its three driver releases carry small platform-specific fixes that belong in the patch queue and little more. MongoDB C Driver 1.30.11 and the parallel 2.5.4 release on September 17 fix a length check in bson_new_from_buffer, an allocation fault in Windows Secure Channel, and error handling in SCRAM authentication 20 21. MongoDB C++11 Driver 4.6.0 on September 16 requires C Driver 2.5.3 or newer and repeats the standing warning that ABI stability is unsupported for entities declared in the v_noabi namespace 22.

Evidence boundaries and current-window gaps

Several coverage clauses this channel is asked to fill each week produced nothing verifiable in this window, and the difference between an absent event and an unobserved one matters to a reader deciding whether to act.

PostgreSQL core updates. No core release appeared between September 14 and September 21. The news archive's newest window entries are pgAdmin 4 v9.18 on September 17 and pgAssistant 3.8.0 on September 16, both ecosystem releases; the core baseline remains the August 13 patch set of 18.6, 17.11, 16.15, 15.19 and 14.24 alongside PostgreSQL 19 Beta 3 23 24.
Oracle MySQL server releases. The feed ends at the August 25 train, so the MySQL material in this issue comes from a downstream fork and readers should treat it as such 19.
pgvector and Qdrant. The pgvector repository exposes no releases at all, so no version event exists to report 25. Qdrant's newest tag remains v1.19.1 from September 4, and its newest blog post, dated September 16, concerns multilingual retrieval rather than engine behaviour 26.
A matched benchmark across different database engines. Still absent. The TIN comparison measures four index implementations on one PostgreSQL version under uniform conditions, which stops short of a PostgreSQL-versus-MySQL-versus-MongoDB-versus-vector-store comparison under shared hardware.
A production migration case study with named source and target engines and a measured outcome. Still absent, and the routes tried this run are worth recording so the next one does not repeat them. A ScyllaDB conference-talk library surfaced exactly one candidate, a Postgres-to-ScyllaDB migration at tiket.com, published in March 2026 and therefore outside the window. Percona's blog carried an Oracle migration partnership announcement with no measured outcome. General and secondary searches returned vendor comparison pages and aggregated material with no first-party account dated inside the window.
Hacker News and CMU Database Group. The Hacker News front page carried no database story during the window. The CMU Database Group's fall 2026 series has its first talk on the calendar for September 21 at 16:30 US Eastern, after this issue's cutoff, so no talk aired inside the window and no recording exists; the subject is Apache Doris as a real-time analytics and search database for AI agents, presented by Owen Xiao 27.

Cross-engine positioning

Three judgments follow from verified material, and each names the constraint that binds it.

Inside relational stores, search is where the measured gap opened. The TIN benchmark shows a text-search index built around PostgreSQL's own tuple identifiers reading 48 to 97 MB per query where an alternative engine read roughly 11,600 MB, and it shows the built-in GIN index failing to complete a disjunction workload at all 2. The binding constraint is distribution: those numbers arrive with a managed platform. A team whose search needs have outgrown tsvector and GIN now has a comparison to reproduce and a migration question to price, which is a different position from the one where the only visible option was a separate search cluster.

Inside MySQL, vector support moved from scoring to indexing in name only. Percona's DISTANCE() puts five metrics and runtime SIMD dispatch into a server that runs anywhere, and the same post states that an ordered similarity query over a large table is a full scan until an approximate index exists 10. The missing index caps what the feature replaces today: a similarity filter over a pre-filtered candidate set is now cheap and local, while large-scale nearest-neighbour retrieval still points at a dedicated vector engine.

Inside vector engines, this week was contention removal rather than capability. Milvus removed an atomic refcount hotspot that its release notes measure at roughly 48% of leaf CPU time in search and cut per-chunk overhead on the query path, while Weaviate's stable output was a repair set backported across three branches and its capability news stayed in a release candidate 3 8. Neither engine moved a boundary a buyer chooses on; both made an existing boundary cheaper to live inside.

For market context rather than workload evidence, the DB-Engines popularity ranking puts Oracle first at 1122.27, MySQL second at 844.82, Microsoft SQL Server third at 698.69, PostgreSQL fourth at 683.26 and MongoDB fifth at 381.31 in its September 2026 snapshot, with PostgreSQL up 26.08 points and MySQL down 46.95 year over year 28. That ranking counts mentions, job postings and documented usage, updates monthly, and predicts nothing about throughput, latency or recovery.

Action queue for backend teams

P0 — act this week

Patch server-mode pgAdmin 4, or constrain its identity handling. The Webserver-mode bypass lets any client that can reach the tool assert an administrator's identity, and the Backup and Restore injection flaws can redirect a connection and the exported password to a host of the caller's choosing 12. Where the upgrade has to wait, restrict header-asserted identity to named trusted proxies behind a shared secret.
Patch Milvus 3.0.x for the compaction and binlog correctness fixes. Storage V2 compaction could misalign packed column indexes, an incomplete binlog chunk could be treated as fully read, and compaction logs could print encryption keys and object storage credentials 3. Teams that shipped logs off-host should treat the credential exposure as a rotation trigger.

P1 — validate in staging

Rehearse the Milvus Go client migration before taking it. The v3.0.0 client moves the import path to client/v3, migrates protobuf types to milvus-proto/go-api/v3, and requires polling for export job state, and it states no guaranteed compatibility with Milvus 2.6 servers, so the cluster upgrade leads 5.
Search for /v1/modules callers before applying the Weaviate wave. v1.38.16 removes that endpoint along with the contextionary handlers, and the repair set lands on the 1.37, 1.38 and 1.39 branches 6.
Audit logical replication slots against the next planned failover. Each slot needs failover = true, the platform needs its name, and hot_standby_feedback and sync_replication_slots must be on, with the vacuum-horizon cost understood before either is enabled 9.

P2 — evaluate

Reproduce the text-search benchmark on your own corpus. The published run used an 85 GB Stack Exchange export and an 8 vCPU, 32 GB container, so the transferable step is the harness: build each candidate index against your own documents, keep the container limit fixed, and measure with and without a concurrent writer 2.
Set the InnoDB high-thread-count expectation before a MySQL minor upgrade. Percona reports the abrupt degradation at high thread counts in 8.4.8, 8.4.10 and upstream 8.4.11, and the fix lives in Percona Server 8.4.11-11, so measure at your own peak concurrency 11.
Watch the Apache Doris talk on the CMU Database Group calendar. It is scheduled for September 21 at 16:30 US Eastern and concerns a real-time analytics and search database aimed at AI agents 27.

References

1
pgAdmin 4 v9.18 Released
postgresql.org
2
Introducing TIN: full-text search for Postgres
planetscale.com
3
Release milvus-3.0.2\
github.com
4
Release milvus-2.6.24\
github.com
5
client/v3.0.0\
github.com
6
Release v1.38.16\
github.com
7
Release v1.39.5\
github.com
8
Release v1.40.0-rc.1\
github.com
9
Blocking cutovers to save replication slots\
planetscale.com
10
DISTANCE() and VECTOR_DISTANCE(): Vector Similarity in Percona Server for MySQL 9.7\
percona.com
11
Performance improvements in Percona Server 8.4.11-11\
percona.com
12
pgAdmin 4 9.18 release notes
pgadmin.org
13
Milvus releases
github.com
14
Release v1.37.17
github.com
15
Release v1.38.15
github.com
16
Release v1.40.0-rc.0
github.com
17
Introducing Lead: TIN-compatible full-text search for CI
planetscale.com
18
The architecture of Neki
planetscale.com
19
MySQL Server Announcements RSS Feed
forums.mysql.com
20
MongoDB C Driver 1.30.11 Released
mongodb.com
21
MongoDB C Driver 2.5.4 Released
mongodb.com
22
MongoDB C++11 Driver 4.6.0 Released
mongodb.com
23
PostgreSQL News Archive
postgresql.org
24
pgAssistant 3.8.0 : continuous improvement loop for Postgres
postgresql.org
25
pgvector Releases
github.com
26
Qdrant Releases
github.com
27
Whatever Andy Found Interesting While Out At Sea — Fall 2026
db.cs.cmu.edu
28
DB-Engines Ranking
db-engines.com