---
cuppy_hub: gcp
cuppy_path: reference/databases/alloydb.md
cuppy_section: docs
cuppy_doc: DKS8-AA0J
cuppy_doc_uuid: 62614ac6-fb8e-4e4c-ba48-bcb5adbd3308
cuppy_permalink: https://cuppy.io/gcp/d/DKS8-AA0J
cuppy_version: 1
cuppy_updated: 2026-10-23T16:16:52.575Z
cuppy_canonical: https://cuppy.io/gcp/docs/reference/databases/alloydb
cuppy_mcp: https://cuppy.io/mcp
cuppy_body_sha256: 77a83b11018299cb589b6b6f87ce861e7503b7b9aa7bfd43b5d593498535c1be
# cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks.
---


# 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.
2. **"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.
3. **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`.


---
<!-- cuppy -->
You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 91 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/gcp/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.
<!-- /cuppy -->