<p><strong>TLDR:</strong> Google Cloud Next '26 dominated today with a wave of database announcements under the “Agentic Data Cloud” banner. Spanner is now downloadable for on-prem and multi-cloud deployments. AlloyDB is pushing into serious vector territory with 10 billion vector support and 6x faster HNSW queries. Separately, a new Postgres extension landed that brings ClickHouse-style columnar storage directly into the heap via custom Table Access Methods.</p>
<hr>
<h2>Spanner Omni: Spanner outside Google Cloud</h2>
<p>Google announced Spanner Omni, a downloadable edition of Spanner that runs on-prem, on other clouds, or on Kubernetes. It keeps ACID compliance, horizontal scalability, and multi-model support (SQL, graph, vector, full-text). The time synchronization problem — normally solved with GPS and atomic clocks via TrueTime — is handled by a software-based alternative. A developer preview is available now for non-production use; commercial access is early access only.</p>
<h2>Google Cloud database updates at Next '26</h2>
<p>The full list is long. AlloyDB scales to 10 billion vectors with 6x faster queries than standard PostgreSQL HNSW, and managed remote MCP servers hit GA for AlloyDB, Bigtable, Cloud SQL, Firestore, and Spanner. MCP Toolbox for Databases 1.0 now supports 40+ databases. New AI functions land in AlloyDB (ai.analyze_sentiment, ai.summarize), and live joins between AlloyDB transactional data and BigQuery/Iceberg are now possible without data movement. Bigtable gets an in-memory tier for sub-millisecond reads, and Memorystore for Valkey 9.0 reaches GA with managed Redis migration paths.</p>
<h2>storage_engine 1.0.7: columnar and row-compressed TAMs for Postgres 16-18</h2>
<p>A new Postgres extension ships two custom Table Access Methods: <code>colcompress</code> (column-oriented, vectorized execution, chunk-level min/max pruning, MergeTree-style ordering) and <code>rowcompress</code> (batch-compressed rows, deleted bitmasks for UPDATE/DELETE, LRU decompression cache). Both support parallel scan. This targets analytics and HTAP workloads as drop-in alternatives to the default heap — no fork, no separate engine, just a different TAM registered at table creation time.</p>
<h2>LLM agents for join order optimization: actually useful</h2>
<p>A UPenn/UCB research prototype puts an LLM agent in an offline tuning loop — not in the query hot path. Given 50 iterations to test join orderings on the Join Order Benchmark with a scaled IMDb dataset, a frontier model achieved 1.288x geomean latency improvement over the default optimizer, with P90 latency dropping 41%. It outperformed perfect cardinality estimates and BayesQO. The key insight is that LLMs handle difficult predicates like LIKE clauses better than traditional cardinality estimators, which tend to fall apart there.</p>
<hr>
<h2>Also notable</h2>
<ul>
<li><strong>VictoriaMetrics at Naver Search scale:</strong> 1.25 billion active time series, 555 trillion data points across 180 storage nodes, ~20M data points/second ingestion — the post covers two zero-downtime migration strategies for hot and warm tiers after a 58x container growth from a Kubernetes migration caused cardinality explosion.</li>
<li><strong>DAX many-to-many relationship cost:</strong> Testing on a 1.4 billion row fact table shows many-to-many cardinality relationships increase storage engine CPU cost nearly 20x versus regular one-to-many, and also disable Fusion optimization — avoid them for high-cardinality columns.</li>
<li><strong>Columnar storage as normalization:</strong> A conceptual post argues that columnar storage is just extreme normalization — each column becomes a table keyed by row ordinal, and row reconstruction is literally a join. Useful mental model for explaining columnar to people who think in relational terms.</li>
<li><strong>NL2SQL agent quality depends on the data catalog:</strong> A Korean beauty app team built an internal BigQuery bot using Claude’s Tool Use API; their core finding is that hallucinated table names were the main failure mode, and forcing the agent to look up DataHub metadata before writing any SQL fixed it.</li>
<li><strong>Spotify’s Honk agent for pipeline migrations:</strong> Background coding agents automated ~1,800 downstream data pipeline migrations from deprecated datasets, shipping 240 PRs and saving an estimated 10 engineering weeks; the bottleneck was context engineering and framework standardization, not the model.</li>
<li><strong>Snowflake ingestion TCO:</strong> Hidden costs — Snowflake credit waste from inefficient merge queries, engineering maintenance, and architectural lock-in — often make cheaper-looking ingestion platforms more expensive overall; the post recommends a proof of concept with real data before committing.</li>
<li><strong>AutoCDC in Databricks Lakeflow:</strong> Declarative SCD Type 1/2 and snapshot CDC reduces 40-200+ lines of custom MERGE logic to 6-10 lines; Navy Federal Credit Union and Block are cited as early adopters.</li>
<li><strong>DuckDB + spatial for 3.4M solar panels dataset:</strong> A walkthrough converting GeoPackage to Parquet with ZSTD compression and Hilbert curve ordering, then running exploratory queries — a clean example of DuckDB’s spatial and H3 extensions working together.</li>
<li><strong>Azure Accelerate for Databases:</strong> Microsoft’s new migration program offers up to 35% savings via spend-based plans and zero-cost delivery support; Thomson Reuters migrated 18,000 databases totaling 500TB to Azure SQL Managed Instance as the flagship case study.</li>
<li><strong>Engram by Weaviate:</strong> A managed memory service for AI agents using async pipelines to extract, deduplicate, and reconcile memories, with configurable topics, multi-tenancy scopes, and Temporal for durable execution — positions itself as an alternative to ever-growing context windows.</li>
</ul>


Query optimization, schema design, and data store coverage across PostgreSQL, MongoDB, Redis, and more.

Databases Digest

Google Cloud Next '26 brought a wave of database announcements: Spanner Omni is now downloadable for on-prem and multi-cloud Kubernetes deployments with software-based TrueTime replacement; AlloyDB scales to 10 billion vectors with 6x faster HNSW queries and gains new AI functions; MCP Toolbox for Databases 1.0 supports 40+ databases. A new Postgres extension (storage_engine 1.0.7) ships two custom Table Access Methods — columnar and row-compressed — targeting analytics and HTAP workloads without forking Postgres. A UPenn/UCB research prototype uses LLM agents in an offline tuning loop to optimize join ordering, achieving 1.288x geomean latency improvement and 41% P90 reduction. Additional highlights include VictoriaMetrics at Naver's 1.25 billion time-series scale, Spotify's Honk agent automating 1,800 pipeline migrations, DuckDB spatial queries on 3.4M solar panels, and Weaviate's Engram managed memory service for AI agents.

Google Cloud Next drops Spanner Omni and AlloyDB vector scaling, storage_engine 1.0.7 brings columnar TAMs to Postgres