Google announced direct Iceberg access in AlloyDB for PostgreSQL, now in preview, letting developers query Apache Iceberg tables stored in Cloud Storage directly from AlloyDB and join them with live operational data in a single SQL query. At the same time, AlloyDB sync and Lakehouse federation reached general availability. Together, the three integrations give AlloyDB distinct ways to work with the borderless Lakehouse, which keeps one open copy of data available to any engine.

The motivation is the convergence of operational and analytical systems. Live state typically lives in operational databases, while historical context sits in a lakehouse or data warehouse. AlloyDB now bridges these by bringing lakehouse data next to live transactions. The article frames several agent-driven use cases: a fraud agent checks a payment against five years of Iceberg history plus the last 30 days of database transactions; a shopping agent joins the live cart with lifetime value and return history; a pricing agent combines live inventory with demand and weather history; and data teams publish curated tables once to Iceberg so dozens of applications read them in place. In each case, history stays in the lakehouse while the decision runs in the database, using only the tables and permissions granted in AlloyDB.

Direct Iceberg access works by reading Iceberg tables from Cloud Storage using either a bucket path or the Lakehouse runtime catalog. A table is registered once and queried like any other PostgreSQL table, including joins with operational tables. Support is built into AlloyDB and accelerated by the AlloyDB columnar engine, so queries over lakehouse data run on the same database instance as the application, with no separate reader instance to manage, and they see the latest published lakehouse data. In Google’s testing on a 1 TB dataset in Cloud Storage, direct Iceberg access was reported as up to 7x faster on aggregation queries than Amazon’s comparable PostgreSQL-compatible service, and up to 3.5x faster on aggregation queries than the open-source PostgreSQL extension.

AlloyDB sync, now GA, addresses data that is read on every request but only changes on a schedule, such as a retail merchant risk score. Instead of maintaining a custom pipeline, AlloyDB sync copies lakehouse data from BigQuery into AlloyDB, once or on a schedule, and keeps it refreshed. The copy is a local AlloyDB table, so applications read it at local-table latency and can index it, serve it from read pools, or use it with the columnar engine and vector search. A sync can be started from the BigQuery console with one click or from SQL.

Lakehouse federation, also GA, is for organizations with analytical history already in native BigQuery tables. AlloyDB queries those tables in place and joins them with operational data in a single query. AlloyDB pushes filters, aggregations, and limits down to BigQuery, which performs most of the processing and returns only the results. Administrators can choose which project is billed for these queries and restrict which roles can use them. The post includes a customer quote from Loyal Guru’s co-founder and CTO, Javi Fernández, saying that AlloyDB with BigQuery provides the agility and performance to enhance the platform and anticipate trends.

Choosing among the three approaches depends on where the data lives and how the application reads it. Direct Iceberg access is best for historical data in Iceberg that an application joins with live data, accelerated by the columnar engine. AlloyDB sync is best for tables read constantly at the lowest latency, with freshness bounded by the last scheduled refresh. Lakehouse federation is best for history stored in native BigQuery tables, with BigQuery doing the processing. The article also cites Etsy as an example of unifying three petabytes with the borderless Lakehouse, joining data in place to accelerate pipeline queries by 60%. To try direct Iceberg access, users enable it on a PostgreSQL 18 instance and follow the provided guide for accessing Iceberg data from AlloyDB.