DB Engineering Weekly: May 11–18, 2026

This week's patch load is heavier than normal. PostgreSQL pushed 11 CVEs across five major versions — two of them sitting at CVSS 8.8. MongoDB's May 14 patch batch covers a time-series OOB write that reaches remote code execution. PgBouncer and pgAdmin each shipped their own CVE clusters. On the benchmark side, SpacetimeDB published a detailed end-to-end throughput test that deliberately disrupts the "just throw Postgres at it" default — worth reading even if you won't use SpacetimeDB, because the numbers isolate where traditional server-plus-database stacks bleed latency under contention. Meta's engineering blog posted a petabyte-scale MySQL migration case study with a shadow-testing architecture that's worth pulling into your own migration playbook.

Releases

PostgreSQL 18.4, 17.10, 16.14, 15.18, 14.23 — May 14

The PostgreSQL Global Development Group released coordinated updates to all five supported major versions, patching 11 CVEs 1. Four reach CVSS 8.8:

CVE	CVSS	Root cause	Impact
CVE-2026-6473	8.8	Integer overflow → allocation undersized → OOB write	Server crash
CVE-2026-6475	8.8	Symlink follow in `pg_basebackup` / `pg_rewind`	Source superuser overwrites arbitrary OS files
CVE-2026-6477	8.8	`libpq` `lo_*` functions misuse → server superuser overwrites client stack buffer	Affects `pg_dump`, `psql`
CVE-2026-6637	8.8	`refint` extension stack buffer overflow + SQL injection	Unprivileged DB user → arbitrary code as DB system user

Two more sit at 7.x:

CVE-2026-6476 (CVSS 7.2): pg_createsubscriber SQL injection via subscription name; requires pg_create_subscription privilege to exploit. Affects PG17–18 only.
CVE-2026-6479 (CVSS 7.5): SSL/GSS negotiation uncontrolled recursion → persistent DoS.

The remaining five (CVSS 3.7–6.5) cover a timing channel in MD5 password comparison (CVE-2026-6478), a logical replication ALTER SUBSCRIPTION SQL injection (CVE-2026-6638, PG16+), a timeofday() memory fragment leak (CVE-2026-6474), a CREATE TYPE multirange privilege bypass (CVE-2026-6472), and an OOB read in pg_restore_attribute_stats (CVE-2026-6575, PG18 only).

Upgrade path: binary replacement only — no dump/restore, no pg_upgrade. If you are running 18.0–18.3 you are exposed to all four 8.8-severity issues; patch this week.

Also patched: pgAdmin 4 pushed a security release fixing eight CVEs (CVE-2026-7813 through CVE-2026-7820) 2. If you run pgAdmin in any production-adjacent environment, treat this as urgent.

PgBouncer: Two CVEs (CVE-2026-6664: integer overflow in packet parsing → crash; CVE-2026-6665: SCRAM strlcat() return value not checked) were published against versions prior to 1.25.2, with the CISA vulnerability bulletin dated May 8 3. Azure Database for PostgreSQL and CloudNativePG have already pushed the upgrade; self-managed deployments should follow.

MongoDB 8.2.9 + 8.3.2 — May 14

MongoDB shipped simultaneous patches across four active branches (7.0.34, 8.0.23, 8.2.9, 8.3.2), covering three server CVEs 4:

CVE-2026-8053 is the most severe. An out-of-bounds write in the time-series bucket catalog triggers when inserting data with duplicate field names into time-series collections. An inconsistency in the internal field-name-to-index mapping allows a remote authenticated user to execute arbitrary code 5. MongoDB's Atlas fleet was proactively patched before public disclosure.

CVE-2026-8199 (CVSS 6.5): An authenticated user can drive excess memory allocation through bitwise match expressions ($bitsAllSet, $bitsAnySet, $bitsAllClear, $bitsAnyClear), contributing to OOM availability loss 6.

CVE-2026-8200 (CVSS 5.3 per NIST, 2.7 per MongoDB): Schema validation error log messages may not fully redact user data (CWE-532). Vendor scores this LOW; NIST scores MEDIUM 7.

MongoDB Compass: IBM published a separate bulletin for CVE-2026-34764 — an Electron use-after-free in offscreen rendering (CVSS 5.5) affecting Compass versions 1.40.0–1.49.3. Fix: upgrade to 1.49.4 8.

For self-managed MongoDB deployments: time-series users should treat CVE-2026-8053 as critical regardless of the vendor's "medium" severity label — remote code execution is remote code execution.

Milvus v3.0 Beta — May 9

Milvus shipped a v3.0 beta on May 9, 2026 — a major version bump from the v2.x line. The official English release notes were returning 403 at research time; the Japanese documentation mirror confirmed the release date. Given the version jump, breaking changes from v2.x are likely; review the release notes before planning an upgrade 9.

Benchmarks

SpacetimeDB 2.0 vs. PostgreSQL / PlanetScale / CockroachDB

SpacetimeDB published a detailed end-to-end benchmark comparing its collocated server+database platform against Node.js+Postgres, Bun+Postgres, Supabase, PlanetScale, CockroachDB, and Convex 10.

Test setup: Simplified bank transfer simulation on a single Intel 14900K (24 vCPU, ~$1,000/month). Client count = 2× CPU cores. Workload distribution follows a power-law (Zipf) — α=1.5 for high contention (hot accounts), α=0 for uniform distribution. 5-minute runs, 30-second warmup excluded.

High-contention (α=1.5) throughput:

Backend	TPS	p99 latency
SpacetimeDB TypeScript	303,920	11.7 ms
SpacetimeDB Rust	265,541	—
Node.js + SQLite	3,188	39.4 ms
Bun + Postgres	2,773	13.2 ms
Node.js + Supabase	2,534	197 ms
Node.js + Postgres	961	16.3 ms
Node.js + PlanetScale (SN)	235	2,504 ms
CockroachDB (5-node)	DNF	9,695 ms

The SpacetimeDB numbers are real but the comparison isn't apple-for-apple. SpacetimeDB is a collocated platform: server logic and database run in the same process, eliminating the network hop that all competing stacks carry. The benchmark authors acknowledge this and argue it's the correct comparison for production full-stack deployments — you're measuring what users actually experience, not an isolated DB query path.

A few things worth noting before drawing selection conclusions:

Isolation level: SpacetimeDB runs serializable isolation by default — stronger than Postgres's default read-committed. The PostgreSQL numbers would drop further at serializable.
CockroachDB under contention: The 5-node cluster produced 9,695 ms p99 and "did not finish" the high-contention run. This is a data point about distributed MVCC overhead under hot-row contention, not about CockroachDB's normal range.
PlanetScale HA cost: The HA configuration (192 vCPU, $67,349/month) delivered 248 TPS at α=1.5 — roughly $15,800 per thousand TPS per month, compared to SpacetimeDB's ~$3.6.
Pipelining: SpacetimeDB used 40-deep request pipelining per client. Applying the same to PostgreSQL clients showed minimal throughput change but extreme p99 degradation — consistent with Little's Law.

Decision relevance: If you are building real-time game backends or collaborative apps where server logic and DB are naturally collocated, the SpacetimeDB architecture is worth evaluating. For conventional microservices architectures with separate API and DB tiers, these numbers describe a different problem.

Migration case study

Meta: MySQL data ingestion at petabyte scale

Meta's data engineering team published a migration case study covering the full replacement of their MySQL-based social graph ingestion system — the pipelines that daily scrape several petabytes of social graph data from Meta's largest MySQL deployment into the data warehouse for analytics, ML training, and product development 11. The migration is complete: 100% of workloads moved, the legacy system decommissioned.

The engineering substance here is in the shadow testing architecture, not the schema translation.

Three-phase migration lifecycle (each phase gated by measurable criteria):

Pre-production shadow: New pipeline reads the same MySQL sources but writes to an isolated shadow table. Row count and checksum parity with production is continuously verified. Resource utilization must not regress. Core tables add dependency-team SLAs to the gate criteria.
Reverse shadow: New pipeline becomes the production writer; old pipeline demoted to shadow. This lets quality comparison continue while making rollback instant — no need to reconfigure legacy jobs when a problem surfaces.
Cleanup: Shadow job decommissioned after a stable monitoring window.

The CDC-specific addition is worth copying. Because CDC pipelines propagate bad data into every downstream partition, Meta implemented metadata-level flagging: delta partitions that fail the quality check auto-stop landing and alert; target partitions auto-select the last-good partition for re-merging. Rollback queries against flagged partitions are fast because the metadata index is pre-built.

At scale (tens of thousands of jobs), the automation tool continuously evaluates each job's stage advancement criteria against Scuba telemetry and promotes jobs automatically. Manual review is reserved for jobs that hit exceptions.

Trade-off for teams considering this approach: The shadow testing infrastructure — particularly the CDC rollback layer and the automated promotion logic — took significant engineering investment. For teams migrating a handful of pipelines, the three-phase structure is still sound; the automation overhead is not. The core insight transfers directly: reverse shadow before cutover, measure row count + checksum parity not just pipeline health, and flag bad CDC partitions at the metadata layer so corruption doesn't propagate.

Migration lifecycle: pre-production shadow → reverse shadow → cleanup, each phase gated by data quality criteria

Meta's three-phase migration lifecycle. Source: engineering.fb.com

Cross-engine positioning

A few signals this week worth tracking:

PostgreSQL 18 is in its 4th minor release (18.4, shipped September 2025 → May 2026). The 11-CVE patch load this month is the largest security bundle since 18 GA. The refint buffer overflow (CVE-2026-6637) is notable because it affects unprivileged DB users — an attack surface wider than most of the CVEs in PostgreSQL's historical record.

MongoDB's time-series path needs scrutiny. CVE-2026-8053 is a code execution vulnerability triggered by duplicate field names in time-series inserts. If you're using MongoDB's native time-series collections in production, this needs immediate patching — the vendor severity label ("medium") understates the blast radius.

Milvus v3.0 beta signals the project is preparing a major architectural revision. The English documentation was inaccessible at research time; evaluate the beta carefully before any production planning. The Milvus 403 issue on the English docs is a known problem documented in this channel's source notes — use the GitHub releases page or the Japanese mirror as fallback.

MySQL 8.0 EOL (July 31, 2026) is 10 weeks out. No new MySQL releases this week; expect migration activity to accelerate in the next two months.

PlanetScale's post-MySQL pivot: Multiple sources this week describe PlanetScale as a managed PostgreSQL competitor. The company originally built on MySQL/Vitess; the positioning shift toward Postgres is now reflected in how the market discusses its cost efficiency (as seen in the SpacetimeDB benchmark, where PlanetScale HA costs $15,800/thousand TPS vs. self-managed Postgres at ~$93).