The curious case of Google's AlloyDB | boringSQL

LIVE

boringSQL Live Session #3<br>19:30 CEST · 17:30 UTC · 1:30 PM ET<br>· VACUUM at the Page Level

Reserve your spot →

Table of Contents

The log is the database

Vacuum, rescheduled

The in-memory columnar store

When it helps, when it doesn't, when it hurts

AlloyDB Omni: same name, different product

Read pool economics

AlloyDB AI: the part that's interesting without GCP

Cross-region: DR, not active-active

What "fully compatible" actually covers

The governance question

When AlloyDB makes sense

The numbers

What Google got right, and what it costs

Disclaimer

Google launched AlloyDB in 2022. They claimed it is fully compatible with PostgreSQL. Can be up to 100 times faster for analytical queries than vanilla Postgres. Four years later, I haven't personally seen it gain significant traction. But it comes in discussions. When people ask me what AlloyDB actually is, I was able to pin point the features, but wasn't really sure what it delivers.

Over the past 12 months, I’ve evaluated AlloyDB. This article shares my key findings. I tried to keep it as objective as the topic allows, and where it isn't, the text says so. I won't pretend to be objective about the verdict. It depends less on one feature and more on where compatibility ends. And as it goes, "it depends" a lot on your workload and needs.

Let's start with the first claim. What does "fully compatible" mean? In this case it covers the wire protocol. Your psql connects, ORMs work, migration means changing connection string and you are done. What it does not cover is nearly everything you know about the Postgres storage internals and query executor. The 8KB pages that define storage layout for vanilla engine, are no longer the durable representation of your data. The WAL is no longer a recovery mechanism. It becomes the database. VACUUM is there, but runs inside storage layer you don't know and and schedule you can't control. And the tuning options differ from what you are be used to.

This creates the curious case. The compatibility claim is true, and the engineering behind AlloyDB backs it up. It's just narrower than the word "fully" migth suggest. AlloyDB is a different database behind the PostgreSQL protocol.

AlloyDB’s compatibility claim holds at the wire protocol, but the underlying engine diverges immediately at the storage layer.

Gartner defines HTAP, or hybrid transaction/analytical processing, as a new application architecture. It "breaks the wall" between transaction processing and analytics. This allows for better decision-making and real-time insights in business.

The short version for the impatient. AlloyDB is not the database you reach for to host a side project or run a small app cheaply. It’s an enterprise HTAP engine for teams using GCP or looking to expand there. It handles both transactional and analytical workloads on one dataset. Usually, there's little to no ETL needed, which means less data copying between an OLTP store and a warehouse. It discusses PostgreSQL's wire protocol. The engineering behind it is solid. However, every feature comes at a cost-both in money and in how much existing PostgreSQL knowledge you can use. The economics aren't static, though. It changes increasingly in favor AlloyDB as the data grows and peak demand increases.

What I'd verify before betting a migration on it:

Whether your extensions survive the move. The allowlist differs between managed AlloyDB and Omni in ways you won't guess (plv8 and postgis trade places); timescaledb and pgrx are on neither.

Whether the columnar store is actually resident before you trust a benchmark number, yours or mine. It can be enabled and silently empty.

The read pool's economics for your read shape. Bursty business-hours reads and flat around-the-clock reads land on opposite sides of the break-even.

Write contention at your scale. My own run inverted between SF10 and SF100, and not in the direction the pitch suggests.

ScaNN recall at your vector count.

The log is the database

In standard PostgreSQL the query engine and the storage engine run as a single process, and that process owns its storage. It writes 8KB pages to disk and writes WAL records so that the system can reconstruct those pages after a crash. The pages hold the data, the log is there to repair them, and under normal operation the compute node pays for both.

AlloyDB inverts this. The compute node never writes full database pages to durable storage. Instead, it sends Write-Ahead Log (WAL) records to a distributed storage layer built on top of Colossus, Google's cluster file system. In this storage layer, a dedicated Log Processing Service (LPS) processes log records. It updates database pages asynchronously. When processing queries, the compute node fetches these pages as needed into its memory buffer pool. It also utilizes an ultra-fast local SSD block cache to cut reads from durable storage and accelerate page retrieval. Ultimately,...