AlloyDB

1. What it is

"A fully managed, PostgreSQL-compatible database service"

Built on a Google engine with disaggregated compute and storage, aimed at enterprise workloads including HTAP, low-latency AI applications and mission-critical deployments.

"PostgreSQL-compatible" is the phrase to read carefully: the wire protocol and the SQL are PostgreSQL's; the engine is not PostgreSQL. For a migration that means the client drivers and most SQL port directly, and anything depending on PostgreSQL internals — specific extensions, replication slots, on-disk layout — needs checking individually.

2. The object model

cluster (regional, a logical container)
  └── instance  (primary | read pool | secondary)
        └── nodes (virtual machines)

Instance type	What it does
primary	read/write. Exactly one per cluster. Either highly available — two nodes in different zones with automatic failover — or basic, a single node
read pool	read-only, for scaling reads. Multiple nodes, with automatic load balancing across them
secondary	cross-region replication, in a separate Google Cloud region

Three readings that change a design:

1. A read pool is one object, not N replicas. You scale it by node count and the service load-balances

across them. That is less operational surface than managing individual read replicas.

1. "Basic" is a single node. A basic primary has no automatic failover. The choice between basic and

highly available is the availability decision, and it is per instance.

1. Cross-region is a secondary instance in another region, not a property of the cluster. A cluster itself

is regional.

3. The columnar engine

It stores data in columnar format in memory, to make analytical scans over large tables efficient. That is what the HTAP claim rests on: transactional rows and analytical scans against the same database.

For an estimate, this is the row that can remove a component — an analytical copy of the operational database, with its pipeline — rather than just making a query faster. Whether it does is measurable against your own queries, and this document states no multiplier because the page does not.

4. Where it sits between Cloud SQL and Spanner

	Cloud SQL (PostgreSQL)	AlloyDB	Spanner
engine	PostgreSQL	PostgreSQL-compatible, Google-built	Google-built, GoogleSQL or a PostgreSQL interface
scope	regional, zonal HA	regional cluster, zonal HA, cross-region secondary	regional, dual-region or multi-region
scaling writes	one primary	one primary	horizontal
the reason to choose it	compatibility and familiarity	PostgreSQL compatibility with more headroom and HTAP	writes that must scale beyond one machine, or availability above a region

Choose on the write requirement first: if one primary is enough, the question is Cloud SQL or AlloyDB. If it is not, the answer is Spanner and the application changes (reference/databases/spanner.md).

Next: reference/databases/errors.md, guides/parity/databases.md.