Google AlloyDB: PostgreSQL-Compatible Database With 4× the OLTP Speed
AlloyDB is Google’s fully managed PostgreSQL-compatible database, launched in 2022. It runs your existing PostgreSQL application code and tools without modification, but replaces the PostgreSQL storage engine with a disaggregated architecture that delivers substantially higher throughput and the ability to run analytical queries against the same data without a separate warehouse.
The benchmark figure Google cites is 4× faster transactional throughput than standard PostgreSQL and 100× faster analytical queries compared to Cloud SQL PostgreSQL. Understanding where those numbers come from requires understanding the architecture.
Architecture: Separated Compute and Storage
Unlike Cloud SQL, where the database server manages its own storage, AlloyDB separates compute nodes from a distributed storage layer.
AlloyDB Architecture:┌─────────────────────────────────────────────────────────────────┐│ AlloyDB Instance ││ ││ Primary instance Read pool instances ││ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ││ │ Compute │ │ Compute │ │ Compute │ ││ │ (PostgreSQL │ │ (read-only) │ │ (read-only) │ ││ │ engine) │ └──────┬───────┘ └──────┬───────┘ ││ └──────┬───────┘ │ │ ││ │ │ │ ││ └────────────────────────┴────────────────┘ ││ │ ││ ▼ ││ ┌──────────────────────────────────────────────────────────┐ ││ │ Distributed Storage Layer │ ││ │ ┌──────────────────┐ ┌────────────────────────────┐ │ ││ │ │ Log Processing │ │ Multi-region replication │ │ ││ │ │ (WAL applied │ │ (synchronous within │ │ ││ │ │ at storage │ │ region) │ │ ││ │ │ layer) │ └────────────────────────────┘ │ ││ │ └──────────────────┘ │ ││ └──────────────────────────────────────────────────────────┘ │└─────────────────────────────────────────────────────────────────┘Key architectural differences from Cloud SQL:
Log processing at the storage layer: AlloyDB moves WAL (Write-Ahead Log) processing from the compute node to the distributed storage layer. The primary instance writes the log; the storage layer applies it. This reduces write amplification and allows read instances to read from the storage layer without going through the primary.
Shared storage for read instances: All read pool instances share the same underlying storage. A read instance can serve reads from data that was just written to the primary without replication lag in most cases.
The Columnar Engine: HTAP in One Database
Traditional databases force a choice: optimize for row storage (fast writes, point reads) or column storage (fast analytics). AlloyDB’s columnar engine maintains a columnar representation of hot data automatically alongside the row store.
Row store (on disk): Row 1: {order_id:001, customer:Alice, amount:89.99, date:2025-03-15} Row 2: {order_id:002, customer:Bob, amount:124.50, date:2025-03-15} ... Best for: INSERT, UPDATE, single-row SELECT
Columnar engine (in memory): amount column: [89.99, 124.50, 67.00, ...] date column: [2025-03-15, 2025-03-15, 2025-03-14, ...] ... Best for: SELECT SUM(amount) WHERE date = '2025-03-15' (scan only the relevant columns, not entire rows)The query planner automatically routes analytical queries through the columnar engine and transactional queries through the row store. There is no manual configuration to achieve this — AlloyDB chooses the optimal execution path.
This HTAP (Hybrid Transactional/Analytical Processing) capability means you can run real-time reporting queries against your operational database without exporting to BigQuery or maintaining a separate read replica for analytics.
Creating an AlloyDB Cluster
# Create a cluster (regional)gcloud alloydb clusters create prod-alloydb \ --region=us-central1 \ --network=projects/my-project/global/networks/default \ --password=secure-password
# Create the primary instancegcloud alloydb instances create prod-alloydb-primary \ --cluster=prod-alloydb \ --region=us-central1 \ --instance-type=PRIMARY \ --cpu-count=8
# Create a read pool (optional, for read scaling)gcloud alloydb instances create prod-alloydb-read-pool \ --cluster=prod-alloydb \ --region=us-central1 \ --instance-type=READ_POOL \ --cpu-count=4 \ --read-pool-node-count=2AlloyDB clusters require VPC peering to connect. There is no public IP option — all connections are private.
Connecting from PostgreSQL Clients
AlloyDB is wire-compatible with PostgreSQL. You connect with standard PostgreSQL clients and drivers using the AlloyDB instance’s private IP or via the AlloyDB Auth Proxy (similar to Cloud SQL Auth Proxy).
import psycopg2
# Direct connection (within VPC)conn = psycopg2.connect( host="10.128.0.5", # AlloyDB instance private IP port=5432, dbname="mydb", user="postgres", password="secure-password", sslmode="require",)
cursor = conn.cursor()cursor.execute("SELECT version()")version = cursor.fetchone()print(version)
# AlloyDB reports itself as PostgreSQL# 'PostgreSQL 14.x ... AlloyDB Enterprise ...'Existing PostgreSQL application code requires no changes. pg_dump, pgcli, Liquibase, Flyway, and standard ORM libraries all work without modification.
AlloyDB vs Cloud SQL PostgreSQL
┌──────────────────────────────────┬──────────────────────┬────────────────────┐│ Dimension │ AlloyDB │ Cloud SQL PG │├──────────────────────────────────┼──────────────────────┼────────────────────┤│ PostgreSQL compatibility │ Full (wire-compat.) │ Full ││ OLTP throughput │ ~4× higher │ Standard ││ Analytical query speed │ Columnar engine │ Standard row store ││ Storage layer │ Disaggregated │ Persistent Disk ││ Read scaling │ Read pool (shared │ Read replicas ││ │ storage, low lag) │ (async replication)││ HA configuration │ Automatic (included) │ REGIONAL optional ││ Maximum storage │ 64 TB │ 64 TB ││ Minimum cost │ Higher │ Lower ││ Public IP option │ No (VPC only) │ Yes ││ CMEK support │ Yes │ Yes │└──────────────────────────────────┴──────────────────────┴────────────────────┘The primary reason to choose AlloyDB over Cloud SQL PostgreSQL is throughput or analytical query performance. For applications that fit comfortably within Cloud SQL’s performance envelope and do not need in-database analytics, Cloud SQL is the more cost-effective choice.
AlloyDB Omni: Running AlloyDB Anywhere
AlloyDB Omni is a downloadable version of AlloyDB that runs on any infrastructure — on-premises, other cloud providers, or local development machines. It uses the same PostgreSQL wire protocol and includes the columnar engine.
# Run AlloyDB Omni with Dockerdocker run -d \ --name alloydb-omni \ -e POSTGRES_PASSWORD=mypassword \ -p 5432:5432 \ gcr.io/alloydb-omni/postgres:15
# Connect with any PostgreSQL clientpsql -h localhost -U postgres -d postgresAlloyDB Omni is free to use. It lets you develop and test against the same database engine that runs in production, including the columnar engine behavior.
Real-World Use Case: Fintech Transaction Platform
A payment processing company needs to:
- Handle 50,000 write transactions per second (OLTP)
- Run real-time fraud risk scores within 100 ms (OLAP on recent data)
- Generate compliance reports on the same dataset (heavy GROUP BY queries)
- Avoid maintaining separate OLTP and analytics databases
AlloyDB addresses all four requirements in a single database:
- High write throughput via the disaggregated storage architecture
- Fraud scoring queries use the columnar engine for sub-second aggregations on recent transactions
- Compliance reports run against the same instance’s columnar engine
- One database to monitor, patch, and backup instead of two
Summary
AlloyDB delivers PostgreSQL compatibility with storage disaggregation, a built-in columnar engine, and dramatically higher throughput than managed PostgreSQL on traditional Persistent Disks. The columnar engine enables HTAP — combining transactional and analytical workloads in one database. AlloyDB Omni extends the same engine to on-premises and multi-cloud deployments. The trade-offs are cost (higher than Cloud SQL for the same core count) and the requirement for VPC-only connectivity. For workloads that have outgrown Cloud SQL’s throughput or need in-database analytics, AlloyDB is the targeted upgrade path within GCP’s PostgreSQL ecosystem.