Google announced two AlloyDB previews on November 4, 2026: Express, a faster-starting database offering for development, and direct access to Apache Iceberg tables. Alongside them, AlloyDB sync and Lakehouse federation reached general availability. These are related data-platform developments with different readiness levels and purposes.
A smaller starting point for PostgreSQL development
Google says AlloyDB Express can provision a PostgreSQL-compatible database in under two seconds and pause compute after 15 minutes without activity. Queries wake it again. The preview includes a monthly free allowance, with storage and active compute charged under the published pricing model.
The company positions Express for prototypes, test pipelines, and coding agents that need isolated databases quickly. Its announcement describes centrally applied IAM and network controls and an upgrade path to a larger AlloyDB deployment that preserves the existing database’s data, schema, users, and connection strings. Those are vendor descriptions, not timings or migration outcomes independently tested here.
Three ways to reach historical data
The separate Iceberg announcement distinguishes direct access, synchronization, and federation. Direct Iceberg access is in preview: AlloyDB reads tables in Cloud Storage and joins them with operational tables using SQL. Its columnar engine executes those reads without requiring an application-maintained copy in a second database.
AlloyDB sync, now generally available, copies lakehouse data into AlloyDB on a chosen refresh schedule for latency-sensitive serving. Lakehouse federation, also generally available, queries native BigQuery tables with processing performed by BigQuery. They should not be treated as interchangeable guarantees about freshness, locality, or query cost.
The broader data-cloud context
Google’s same-day platform announcement also describes generally available cross-cloud interconnect and caching for AWS and Azure, plus catalog integrations built around open Iceberg data. Its direction is to give applications governed access to distributed information rather than require a separate bespoke pipeline for every new use.
The practical detail is where each workload runs and which layer enforces access. A shared table format helps interoperability, but permissions, catalog registration, and network reachability still determine whether a query can use a dataset.
Choose an evaluation by workload
Our analysis is to test Express first with representative development activity. Measure cold and warm connection behavior, inactivity pauses, and how the application handles an interrupted connection. Check that a temporary test database receives the intended network and role restrictions automatically.
For lakehouse access, begin with one useful join and explicitly record the allowed age of historical data. A direct read and a scheduled synchronized copy may produce the same answer in a demonstration while behaving differently during a late data arrival or a busy production period.
Measure total query work and resource contention alongside response time. A database serving customer transactions can be affected by a broad historical query, even when the SQL interface is convenient. Verify cancellation, limits, and error handling before adding an agent that can generate many queries.
Keep the maturity labels visible
Express and direct Iceberg access offer new evaluation paths. The generally available sync and federation features offer different operational choices today. Teams will make better decisions by matching each feature’s status to a real workload than by treating the whole announcement as a single production-ready bundle.