AlloyDB Explained: Google's PostgreSQL-Compatible Database

What is AlloyDB for PostgreSQL?

AlloyDB (Google Cloud AlloyDB, sometimes written Alloy DB) is a fully managed, PostgreSQL-compatible database service. Google pairs its own database engine with a cloud-based, multi-node architecture and aims it at demanding workloads: hybrid transactional and analytical processing (HTAP), generative AI applications that need vector search close to the data, and mission-critical systems that need high availability.

Applications connect with the standard PostgreSQL protocol, so psql, pgAdmin and ordinary PostgreSQL drivers work, and each cluster is pinned to a PostgreSQL major version you choose (14 to 18 at the time of writing, with 17 as the default). Google keeps minor versions current through maintenance, and maintenance is designed to cause less than a second of downtime on primary instances while read pools stay available.

AlloyDB sits between Cloud SQL, which runs community PostgreSQL on a single primary VM, and Spanner, which scales writes horizontally across regions. Its main advantage over Cloud SQL is read scaling and analytics on a shared storage layer, while staying close enough to PostgreSQL that applications rarely need rewriting.

AlloyDB architecture: clusters, instances and nodes

Standard PostgreSQL couples the query engine and storage on one server. AlloyDB separates them. Compute runs on nodes (VMs); storage is a distributed engine that keeps data across several zones of the region and grows automatically. Resources are organised in three levels:

• Cluster: the regional container for your databases, logs and metadata.
• Primary instance: exactly one per cluster, for reads and writes. A highly available primary has an active and a standby node in different zones with automatic failover; a basic primary has a single node for non-production use.
• Read pool instances: read-only endpoints with up to 20 nodes in total across the cluster, load-balanced automatically.

Because every instance reads the same storage, adding read nodes does not copy the data or raise storage cost. AlloyDB also runs adaptive autovacuum, automatic memory management and an index advisor. For disaster recovery you can create secondary clusters in other regions, which AlloyDB updates asynchronously, and continuous backup lets you restore to any point within the retention window.

The AlloyDB columnar engine

The columnar engine keeps a copy of selected table columns in memory in a column-oriented format, together with a planner and executor that use it. It helps queries that scan many rows but few columns: selective filters, SUM, MIN, MAX, AVG and COUNT aggregates, some hash joins and JSON filters. You can enable it on the primary, on a read pool or both, and auto-columnarization can choose the columns for you based on the workload.

The documented limits are worth knowing before you rely on it. Enabling the engine requires a restart, and by default it uses 30% of the instance's memory. Every column a query fragment touches must be in the column store, frequent row updates invalidate columnar data until it is refreshed, partitioned tables must be loaded partition by partition, and for small tables (typically under 5,000 rows) or indexed columns the planner may prefer the row store.

AlloyDB AI and vector search

AlloyDB AI is a set of extensions for building AI features inside the database:

• vector, a version of pgvector customised for AlloyDB, for storing and indexing embeddings;
• alloydb_scann, an approximate nearest-neighbour index based on Google's ScaNN algorithm;
• google_ml_integration, for generating embeddings and calling registered models (including external models from OpenAI or Anthropic) from SQL;
• alloydb_ai_nl, which turns natural-language questions into SQL.

Cloud SQL for PostgreSQL also supports pgvector, so vector search alone is not a reason to move; ScaNN indexes and in-database model calls are the AlloyDB-specific parts.

AlloyDB Omni: AlloyDB outside Google Cloud

AlloyDB Omni is a downloadable, self-managed edition that shares core components with the managed service but runs on storage you choose: your data centre, another public cloud, cloud VMs or a laptop. Google distributes it as a container (for Docker, Podman or Kubernetes with an operator) and as RPM packages for RHEL 9 and Rocky Linux 9. It includes the columnar engine and AlloyDB AI. Production use is licensed by vCPU through subscriptions managed in the Google Cloud console.

Google states that, in its performance tests, AlloyDB Omni runs transactional workloads more than twice as fast and analytical queries up to 100 times faster than standard PostgreSQL. These are vendor figures we have not reproduced. Omni suits teams with data-residency rules, disconnected sites or a wish to avoid committing to a managed cloud service.

AlloyDB pricing vs Cloud SQL

AlloyDB has no licence fees or I/O charges; you pay for vCPUs and memory per node, storage, backups and network egress. Compared with Cloud SQL, three differences shape the bill:

• Compute rates are higher per vCPU and per GiB than both Cloud SQL editions, and an HA primary bills two nodes.
• Storage is billed on use and shared by all instances, whereas Cloud SQL bills provisioned disk per instance and each read replica has its own copy.
• Transaction logs for the first seven days of continuous backup are retained at no extra charge.

For a single small database, AlloyDB usually costs more than Cloud SQL. The gap narrows as you add read capacity, because read pool nodes share storage. The worked examples below compare an AlloyDB HA primary with an equivalent Cloud SQL Enterprise Plus HA instance. See also Google Cloud SQL vs AlloyDB.

When to use AlloyDB, and when not to

AlloyDB fits PostgreSQL applications that need many read replicas, reporting on live data without a separate warehouse, in-database AI features, or a 99.99% SLA for an HA primary. It also suits teams who want the same engine on Google Cloud and on-premises through Omni.

Look elsewhere for small or development databases where cost dominates (Cloud SQL's shared-core and Enterprise machines are cheaper), for engines other than PostgreSQL, for workloads that need horizontal write scaling across regions (Spanner), or for a pay-per-request serverless database (Firestore). Heavy warehouse-style analytics over very large data sets still belong in BigQuery; see BigQuery vs PostgreSQL.

Pricing

Prices from the provider's official pricing pages, checked 8 October 2026, region Iowa (us-central1), in USD, excluding tax. List prices only; discounts, commitments and your actual usage change the bill.

AlloyDB list prices for the N2 and C4A machine series: 0.06608 USD per vCPU-hour and 0.0112 USD per GiB-hour of memory on demand (0.04956 and 0.0084 with a one-year commitment, 0.0317184 and 0.005376 with three years). Regional cluster storage is 0.0004109 USD per GiB-hour and standard backup storage 0.000137 USD per GiB-hour. Data transfer into AlloyDB and within the same region is free. Google's free features page offers a 30-day AlloyDB free trial cluster with an 8 vCPU basic instance and up to 1 TB of storage.

Worked examples are estimates calculated from the list prices above; they are not quotes or measured bills.

Frequently asked questions

Sources

• AlloyDB overview
• AlloyDB: About the columnar engine
• AlloyDB AI
• AlloyDB Omni overview
• AlloyDB: Database version policies
• AlloyDB: Create a cluster and its primary instance
• AlloyDB free trial clusters
• AlloyDB pricing
• AlloyDB SLA
• Cloud SQL pricing
• Google Cloud Free Trial and Free Tier

Checked 8 October 2026.

How we research cloud database guides: our editorial method. CodeWithSQL earns nothing from the providers mentioned.