Database News Roundup — Aurora DSQL Insights, RDS Region Switch, AlloyDB ScaNN at 10B Vectors (Aug 21, 2026)

Today’s vendor feeds had an unusually practical batch: per-statement visibility for Aurora DSQL, switchover orchestration for RDS in multi-Region recovery plans, a thorough AWS walkthrough of multilingual full-text search migration to PostgreSQL, a four-level ScaNN tree in AlloyDB that pushes vector search to 10 billion rows, and customer-managed keys for Timestream for InfluxDB. Here is what changed and what it means if you run these systems.

Aurora DSQL gets per-statement CloudWatch Database Insights

Aurora DSQL now emits a CloudWatch Database Insights metric with per-statement, cluster-level performance detail: sampled wait states and normalized SQL statements, per the announcement. Until now, DSQL’s serverless model left operators with thin visibility compared to what pg_stat_statements gives you on RDS or self-managed Postgres — you could see cluster-level aggregates, but attributing latency to a specific statement shape was guesswork.

This narrows that gap. Sampled wait states are the part to watch: they tell you whether time is going to I/O, locks, or CPU without you having to query anything. If you are evaluating DSQL for a workload, per-statement monitoring was one of the legitimate blockers, and this removes a good chunk of it. Verify in the announcement which regions and pricing tier Database Insights for DSQL lands in before you plan around it.

ARC Region switch can now orchestrate RDS read-replica switchovers

Amazon Application Recovery Controller (ARC) Region switch added an RDS Switchover Read Replica execution block, so multi-Region recovery plans can include promoting an RDS read replica as an automated step — the announcement calls out RDS for Oracle with Data Guard in multi-Region workloads first. Region switch is AWS’s orchestrated failover tooling; the point of an execution block is that the database promotion becomes a declared, tested step in the plan rather than a runbook someone follows at 3 AM.

Two things to check before relying on it: which engines beyond Oracle the block supports today, and how it handles the unplanned-failover case — a switchover is a clean, planned promotion, and real regional failures are rarely clean. If your DR plan currently says “someone promotes the replica,” this is worth a look either way; the orchestration forces you to rehearse the promotion path.

AWS publishes a field guide for multilingual FTS migration from SQL Server to PostgreSQL

The AWS Database Blog posted a deep walkthrough of migrating multilingual full-text search from SQL Server to Aurora/RDS PostgreSQL, and it leads with the trap that actually bites people: after a technically correct migration, searches silently return different results. cafe stops matching café, stemming diverges, compound-word behavior changes.

The core mental model the post lays out: SQL Server splits behavior across collation, the indexed column’s language, and the catalog’s ACCENT_SENSITIVITY, while PostgreSQL splits it across collation (libc or ICU) for comparison and text search configurations for tokenization and stemming. The practical recipes are all there — an unaccent-based custom configuration for accent-insensitive French search, per-language GIN expression indexes with WHERE lang = ..., and pg_bigm bigram indexing for CJK text. The honest limitations section is worth reading before you promise anyone parity: file-based dictionaries (ispell, thesaurus, custom stoplists) cannot be installed on Aurora/RDS, so synonym handling moves to tables and functions, Dutch and German configs do not split compounds, and Hebrew has no built-in stemmer at all. If you have an FTS migration queued, budget the validation pass the post’s checklist describes — that is where these projects actually succeed or fail.

AlloyDB’s ScaNN index scales to 10 billion vectors with a four-level tree

Google Cloud published the engineering details behind AlloyDB’s ScaNN index reaching 10 billion vectors: the tree-based index gains a four-level architecture (in preview), up from two- and three-level configurations. Each added level subdivides the search space further — Google’s framing is search complexity moving from O(N^1/2) at two levels to O(N^1/4) at four — and the build side uses balanced tree shapes and condensed sampling to stay within memory limits.

Their reported numbers: ≤51 ms p95 latency at 95% recall on 10 billion vectors. Those are Google’s internal test figures, so treat them as a ceiling rather than a guarantee for your embedding distribution, but the direction matters for anyone on PostgreSQL-flavored vector stores: pgvector’s HNSW is excellent at millions of vectors and gets expensive to keep in memory as you approach hundreds of millions. A tree-based index that trades a bit of recall for a much smaller memory footprint is the right shape for that scale. If you are on AlloyDB and hitting HNSW memory walls, the preview is worth benchmarking against your real queries — recall numbers on vendor benchmarks and on your data routinely differ.

Timestream for InfluxDB adds customer-managed KMS keys

A short one: Timestream for InfluxDB now supports customer-managed KMS keys for encryption at rest, covering InfluxDB 2 instances, InfluxDB 2 read replicas, and InfluxDB 3 clusters. You pick a symmetric KMS key at resource creation. This is a compliance checkbox, not a performance feature — relevant if your organization requires CMK for audit or key-rotation policy reasons, and a non-event otherwise. Note that, as with most AWS CMK launches, the key choice happens at creation; check the announcement for whether existing instances can be re-keyed or need replacement.

That is the day. The DSQL monitoring addition and the AlloyDB ScaNN work are the two items with real architectural consequences; the FTS migration guide is the one to bookmark for your next heterogenous migration. We will be back with the next roundup when the vendors ship something worth your time.