DB Weekly: MySQL's release matrix widens, while PostgreSQL and Weaviate tighten operations (2026)

The week from August 24, 2026 at 10:00 a.m. through August 31, 2026 at 10:00 a.m. (UTC-08:00) produced three usable operational signals. MySQL coordinated server, client, connector, and NDB releases; pg_statviz 1.2 added PostgreSQL 19 visibility and lock analysis; Weaviate shipped repairs across both the 1.39 and 1.38 stable lines. The evidence changes upgrade sequencing and observability work more clearly than it changes engine-performance or migration choices.

The benchmark and production-migration fields remain empty for this window. That boundary matters: teams can decide what to stage and patch from the releases below, while a database-selection decision still needs workload measurements and a named migration outcome.

Decision table

Date	Engine or ecosystem	Verified change	Decision boundary	Immediate check
August 25	MySQL	Server `26.7.1`, `9.7.3`, and `8.4.12`; Shell `26.7.1`; Connector/ODBC `26.7.1`; NDB Cluster `26.7.1`, `9.7.3`, `8.4.12`, and `8.0.49`	Server and NDB Docker-only scope differs from the surrounding tool releases; 8.4 and 9.7 focus on security and bug fixes	Inventory every server image, client, connector, and NDB node before a coordinated canary. 1
August 25	PostgreSQL ecosystem	`pg_statviz` 1.2 supports PostgreSQL 19 counters and settings, adds blocking-lock analysis, and adds an optional OpenAI-compatible provider	PostgreSQL 19 beta evaluation gains a lightweight snapshot path for WAL, I/O-worker, autovacuum, and lock-wait observations	Install it beside a PostgreSQL 19 beta or staging cluster and compare its snapshots with incident timelines. 2
August 26-27	Weaviate	`v1.39.2` and `v1.38.13` repair shard lifecycle, replication, aggregation, Docker, credential-export, and branch-specific vector/MCP paths	The release pages list fixes across stable branches, with no entries under Breaking Changes or New Features	Test shard teardown, async replication, Docker rebuilds, API-key hash export/import, and branch-specific recovery paths. 3 4

MySQL's release matrix widens the upgrade surface

The August 25 MySQL announcement is useful because it names the surrounding components alongside the server versions. MySQL Server 26.7.1, 9.7.3, and 8.4.12 are listed as Docker-only releases. MySQL Shell 26.7.1 and Connector/ODBC 26.7.1 are listed separately. MySQL NDB Cluster adds 26.7.1, 9.7.3, 8.4.12, and 8.0.49, with the Docker-only qualification attached to those NDB lines as well. The announcement recommends the releases for production use. 1

The operational change is the boundary between the server image and the tools that connect to it. The announcement says that clients, tools, and connectors should use their latest versions regardless of the server version, and that those components support MySQL Server 8.4 and 9.7. A server-image patch can therefore leave a separate client or connector rollout decision in its path. 1

The release posture also differs by line. The announcement says that the 8.4 and 9.7 series focus on security and bug fixes only. That wording gives operators a maintenance expectation for those series; it supplies no workload-performance claim and no reason to alter a database choice by itself. 1

The staging plan should track four independent surfaces:

Server images: verify the Docker-only packaging boundary for the selected server line, then run startup, replication, backup, and rollback checks.
Clients and connectors: test the newest Shell and Connector/ODBC versions against each server version that production still runs.
NDB deployments: treat NDB Cluster as its own matrix, including the older 8.0.49 line, instead of assuming the standard MySQL Server test covers it.
Upgrade evidence: record which component changed in each canary. A green server rollout does not establish that an ODBC application, Shell automation job, or NDB cluster has seen the same change.

PostgreSQL 19 visibility arrives through pg_statviz

pg_statviz 1.2 is a PostgreSQL ecosystem release, rather than a PostgreSQL core release. The project describes it as an extension and utility pair for time-series analysis and visualization of PostgreSQL internal statistics. The August 25 release adds PostgreSQL 19 support and says it was tested across PostgreSQL 13 through 19, including PostgreSQL 19 beta 3. 2

The PostgreSQL 19-specific additions are concrete. pg_statviz captures the wal_fpi_bytes counter from pg_stat_wal. It also records PostgreSQL 18 and 19 settings for I/O workers, effective WAL level, and autovacuum scoring in snapshot_conf. Those fields give a beta evaluator a way to connect WAL and maintenance configuration to a time series instead of relying only on point-in-time configuration captures. 2

The new blocking-lock module records blocked and blocking session counts and breaks them down by lock type, including relation, transactionid, and tuple. It uses pg_blocking_pids(), which lets the module count sessions that are waiting behind an earlier session in the lock queue, including soft blocks. The project says the table size stays independent of the number of sessions involved, and that sustained blocking receives a deterministic minimum severity rather than an AI-generated healthy verdict. 2

The release adds an openai provider for OpenAI-compatible APIs. Operators select the endpoint and model through OPENAI_BASE_URL and OPENAI_MODEL. The AI extra adds the dependency, while an installation without the AI option keeps the zero-dependency behavior; the project says analysis remains optional and opt-in. 2

The useful test is operational. Put pg_statviz 1.2 on a PostgreSQL 19 beta or staging cluster, enable the lock module, and create a known wait chain. Check whether the snapshot captures the expected blocker, waiters, lock type, and duration. Then compare wal_fpi_bytes, snapshot_conf, and autovacuum observations against the same workload's logs. Keep the AI provider disabled until the deterministic metrics and export path work; the release does not require AI for its PostgreSQL 19 or lock analysis.

Weaviate repairs two stable branches at once

Weaviate released v1.39.2 on August 26 and v1.38.13 on August 27. Both release pages put their changes under Fixes. Neither page lists entries under Breaking Changes or New Features. The overlap makes the right unit of analysis a coordinated maintenance wave across stable branches, rather than two feature releases. 3 4

The shared fixes target failure paths around shard state and deployment operations. Version 1.39.2 makes the resource scanner's shard status check-and-set atomic, drains in-flight references before shard teardown, stops retrying an unload after collection close, batches async-replication root pre-filtering per target node, and repairs remote shard aggregation after JSON round trips. The same release adds per-namespace collection-count metrics, DB user API-key hash export/import endpoints, a minimum OpenSSL pin for cached Docker builds, and the DigitalOcean generative module. 3

Version 1.38.13 backports several of those operational repairs and adds branch-specific fixes. The page lists named-vector source-property handling during re-vectorization, HFresh centroid decoding during split and merge reassignment, and a stateless MCP endpoint that rejects GET with HTTP 405. 4

The action is a failure-path test, not a feature migration. Exercise shard drop and collection close while requests remain in flight. Run async replication with multiple classes and target nodes. Rebuild cached Docker images and inspect the OpenSSL package actually pulled into the image. Test API-key hash export and import in a disposable environment. A deployment on 1.38 should add the HFresh, named-vector, and MCP cases to the same test run because those fixes are branch-specific.

Evidence boundary for this week

The configured seven-day search closed with a release and operational signal set, while four promised evidence areas remain open:

Benchmarks: no matched cross-engine result supplied workload type, hardware or environment, throughput, latency percentiles, and a comparison baseline in one qualified source. This issue therefore carries no performance leaderboard.
Migration case studies: no current-window production report supplied a named organization, source engine, target engine, outcome, trade-offs, and lessons learned together. Release planning can proceed, while migration claims require a later case study.
Conference talks: searches of the CMU Database Group and Carnegie Mellon Quarantine DB Talks routes returned older material without a verifiable August 24-31, 2026 publication or event date and the required technical fields.
Engine coverage: the window produced no verified MongoDB or pgvector item. Milvus exposed a 2.6.23 release entry whose release note was still pending, so the tag supplies a release lead without a feature, fix, compatibility, or performance claim. The current-window search also produced no qualified Weaviate benchmark or MongoDB migration report.

These gaps limit what the week can say about database selection. The verified material supports patch sequencing, observability checks, and vector-service repair testing. It cannot establish that one engine is faster, cheaper, easier to migrate, or better for a given workload.

Cross-engine positioning

The three confirmed signals share one constraint: operational boundaries are becoming more explicit than workload differences in this week's evidence. MySQL names separate server, tool, connector, and NDB release surfaces. pg_statviz turns PostgreSQL 19's new statistics and lock queues into fields that can be checked during beta evaluation. Weaviate repairs shard, replication, image, credential, and branch-specific paths across two stable lines. 1 2 3 4

That pattern supports a bounded conclusion: teams choosing or upgrading a database this week should spend engineering time first on component inventory, staging observability, and failure-path testing. The releases do not supply the workload numbers or production migration outcomes needed to move a database-selection decision on performance grounds.

Action queue

MySQL: build a matrix covering Server 26.7.1, 9.7.3, and 8.4.12, Shell 26.7.1, Connector/ODBC 26.7.1, and the four NDB Cluster versions. Mark Docker-only surfaces separately, then run a patch canary for each application connection path. 1
PostgreSQL: deploy pg_statviz 1.2 beside a PostgreSQL 19 beta or staging cluster. Validate wal_fpi_bytes, snapshot_conf, soft-block detection, lock-type breakdowns, and export before considering the optional AI provider. 2
Weaviate: test shard teardown, async replication, aggregation, cached Docker rebuilds, API-key hash export/import, and branch-specific HFresh, named-vector, and MCP behavior on the stable line you operate. 3 4
Selection work: keep performance and migration decisions open until a qualified benchmark and a production case study provide the missing workload and outcome fields.