DB Weekly: MySQL unifies its tools as Milvus 3.0 moves vector indexes into the lake (2026)

The upgrade boundary moved in two different places this week. MySQL moved the boundary around the server, making its surrounding tools a single 26.7 release train. Milvus moved the boundary around the data, allowing indexes to sit over lake files instead of requiring a second vector copy. Neither change comes with a new production migration result or a matched cross-engine query benchmark in this week's verified material.

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

Decision table

Decision area	Verified change	Engineering read
MySQL release line	On August 1, MySQL announced Server 26.7.0, 9.7.2, and 8.4.11. Shell, Router, Operator, NDB Operator, and Connectors are on 26.7.0. Those tools now use a single 26.7 line; their 8.4 and 9.7 release series are discontinued. 1	The upgrade unit is now the server plus its toolchain. Test the 26.7 tools against every server line you operate before changing only the server image.
Milvus 3.0	The July 27 release adds read-only, zero-copy External Collections over Parquet, Lance, Iceberg, and Vortex, plus server-side ordering, aggregation, faceting, StructArray, and improved sparse retrieval. 2	The architecture choice is no longer only "Postgres extension or standalone vector store." Test whether lake-resident data can meet freshness, recall, and tail-latency targets without a serving copy.
PostgreSQL	The PostgreSQL security archive shows no PostgreSQL core release inside this window; its latest listed current item is the July 6 JDBC 42.7.12 security release. 3	There is no new core-version decision to make from this week's verified material. Keep existing PostgreSQL upgrade work scoped to the changes you can actually test.
MongoDB	No qualifying MongoDB release detail page published inside this window was verified in this pass.	Treat the quiet result as a coverage gap, not evidence that MongoDB is stable or unchanged. Do not recycle the previous week's lifecycle material.
Performance evidence	PlanetScale reports a sharded Postgres backup design that can exceed 50 GB/s at petabyte scale. Its worked example estimates about 22 hours for a 32 TB unsharded backup, 2.8 hours across eight shards, and 42 minutes across 32 shards at 500 MB/s per backup node. 4	This is useful evidence about recovery windows and parallelism, not a cross-engine query benchmark. It has no matched Postgres/MySQL/MongoDB/vector workload, p50/p99 table, or independent baseline.
Migration evidence	No in-window production postmortem with a named source engine, target engine, and measured outcome was verified. Milvus describes a product architecture; PlanetScale describes infrastructure operations.	Do not convert an architecture announcement into a migration success story. Keep cutover time, rollback, data freshness, and post-cutover correctness as open test gates.

MySQL changed the unit of upgrade

The August 1 MySQL announcement is more consequential for operators than the patch numbers alone suggest. It ships MySQL Server 26.7.0, 9.7.2, and 8.4.11, alongside 26.7.0 for MySQL Shell, Router, Operator, NDB Operator, and Connectors. The surrounding tools now follow one version line, while the 8.4 and 9.7 tool series are discontinued. MySQL says the current tools remain compatible with supported Server 8.4, 9.7, and 26.7, and that the 8.4 and 9.7 server series will focus on security and bug fixes. 1

That changes the shape of an upgrade review. A team that previously pinned mysql-router:8.4, mysql-shell:9.7, or an operator image to match the server line now has to check whether those pins still receive the intended maintenance path. The compatibility statement lowers the immediate risk of using 26.7 tools with an older supported server, but it does not remove the need to test authentication, routing, failover, schema operations, backups, and observability in the exact combination used in production.

The practical inventory is therefore four-dimensional:

server branch and patch level;
Shell, Router, Operator, NDB Operator, and connector versions;
replication and failover mode;
client behavior under the target authentication and routing configuration.

The release announcement does not publish a performance delta or a production migration result. It changes the maintenance rule. That is enough to justify a compatibility matrix, not enough to claim that 26.7 is faster or easier to operate.

Milvus 3.0 changes where the vector copy lives

Milvus 3.0 introduces External Collections: read-only collections defined over data that stays in object storage or open table formats. The announcement names Parquet, Lance, Iceberg, and Vortex. Milvus builds and serves vector, BM25, JSON, and scalar indexes over that external data, and reads the storage manifest to index only new fragments when the dataset changes. 2

This removes one familiar cost from the design discussion: keeping a second serving copy synchronized with the lake. It does not remove the other costs. External Collections are read-only, so writes still belong to the source system. Index freshness depends on discovering new fragments and building the corresponding indexes. Access control, object-store locality, restore behavior, and schema evolution remain part of the system rather than disappearing into the API.

Milvus also moves more result processing into the engine. The release lists ORDER BY, aggregation, faceting, StructArray for nested document or chunk structures and ColBERT vectors, plus a redesigned sparse index. The selection question therefore expands from nearest-neighbor latency to the amount of ranking, grouping, and multi-vector scoring the application must implement itself. 2

The announcement does not provide a customer cutover, recall comparison, p50/p99 result, or cost comparison against a duplicate-copy architecture. That missing evidence matters more than the feature list for an existing deployment. A production evaluation should compare the same dataset in two shapes:

a lake-resident External Collection;
a conventional serving copy maintained by ingestion or ETL.

Measure index build time after new fragments arrive, query freshness, recall at the chosen top-k, p50 and p99 latency, object-store reads, egress, recovery time, and the behavior of schema changes. The architecture is promising; the release post is not a migration proof.

The week's useful numbers are about recovery, not query speed

PlanetScale's July 31 engineering report describes backups for Neki, its sharded Postgres system. The worked design takes a consistent point-in-time snapshot by restoring a prior backup, replaying archived WAL, catching up the newest changes from the primary, then encrypting the result into object storage. The backup nodes are temporary and run one per shard so the production nodes carry less of the I/O and compute load. 4

The numerical example is concrete. A 32 TB unsharded database is assumed to compress to 20 TB. The full cycle transfers about 40,030 GB. At 500 MB/s, the report estimates about 22 hours. The same logical data split across eight shards takes about 2.8 hours when eight backup nodes run in parallel; across 32 shards, the estimate falls to about 42 minutes. The report also says its production design handles hundreds of thousands of queries per second on an eight-shard example and can exceed 50 GB/s at petabyte scale. 4

The trade-off is easy to misread. Sharding does not make the same bytes disappear. It makes the transfer parallel, while adding shard coordination, more nodes, more failure domains, and more restore paths. The number that matters for selection is the recovery objective: can the backup cycle finish before the next scheduled backup and preserve the required RPO?

PlanetScale also notes that its sharded MySQL path is similar in shape but uses VTBackup and MySQL binary-log replication instead of Postgres backup primitives and WAL. That is a useful operational contrast, but the report does not compare query throughput, latency, or recovery cost between the two engines under a shared workload. 4

What the missing evidence means

A weekly selection brief can be misleading when a release-heavy week is mistaken for a benchmark week. The verified material leaves three boundaries open:

No matched engine benchmark. The PlanetScale numbers describe one sharded Postgres backup design. They do not rank PostgreSQL, MySQL, MongoDB, or vector engines for OLTP, OLAP, or similarity search. No current-window source supplied the hardware, dataset, query mix, p50, p99, throughput, and baseline needed for that comparison.
No production migration outcome. Milvus 3.0 supplies a new architecture and MySQL supplies a new tool-version rule. Neither source reports a completed migration with source and target engines, outage duration, lag, rollback result, or post-cutover correctness.
No fresh signal for several tracked engines. The current pass did not verify an in-window PostgreSQL core release, MongoDB release, Qdrant or Weaviate release, CMU Database Group talk, or qualifying Hacker News benchmark thread.

Those are not reasons to pretend the week was empty. They tell a team which conclusions are safe. MySQL's tool-chain change is an upgrade-control fact. Milvus's lake-native path is an architecture hypothesis worth testing. PlanetScale's backup math is a recovery-design example. None is a universal engine-selection result.

Cross-engine positioning

MySQL is tightening the maintenance boundary around its ecosystem. The immediate consequence of the 26.7 tool model is less freedom to treat server and tools as independent release trains. Teams that rely on Router, Shell, or Operator need a matrix test, even when the server branch stays put.

PostgreSQL has no new core release signal in this window. That is a reason to avoid unnecessary churn, not a performance claim. The absence of a fresh release does not answer whether an existing workload should move to another engine.

MongoDB is unresolved for this edition. No current-window official release detail was verified. The correct engineering response is to keep the question open rather than reuse last week's lifecycle deadline as if it were a new event.

Milvus is pushing the vector decision toward data placement and retrieval semantics. A standalone vector service still has a clear role when low-latency serving and independent operational control dominate. Milvus 3.0 makes a different case: when embeddings already live in an open-format lake, zero-copy indexing and server-side result processing may remove an ETL copy and application-side query logic. That case still needs workload evidence.

Action queue

Build the MySQL compatibility matrix. Test the 26.7 tools against every supported server branch you run. Include connectors, authentication, Router failover, Operator reconciliation, backups, schema changes, and observability before changing production pins.
Run a two-path Milvus evaluation. Compare External Collections with the serving-copy design on the same lake data. Record freshness after new fragments, recall, p50/p99 latency, index-build time, object-store traffic, egress, schema evolution, and restore behavior.
Turn the PlanetScale example into an RPO test. Use your real compressed size, shard count, transfer rate, WAL or binlog churn, and backup cadence. Verify whether the cycle finishes before the next backup and whether a restore can complete inside the recovery objective.
Keep this week's numbers out of a query leaderboard. The next cross-engine benchmark should publish hardware, dataset, query mix, correctness target, throughput, p50, p99, and recovery behavior together. Without those fields, label the result as a system-design report.
Leave the missing release and migration signals open. Recheck MongoDB, PostgreSQL core, Qdrant, Weaviate, CMU, and HN in the next window. Do not backfill this issue with older material just to make the table look complete.