Amazon Aurora vs Google AlloyDB

Quick verdict

Amazon Aurora is AWS's MySQL- and PostgreSQL-compatible relational engine, managed through the Amazon RDS console and API. All instances in a cluster share one cluster volume that keeps copies of the data in three Availability Zones and grows automatically up to 256 TiB; a cluster has one writer and up to 15 Aurora Replicas. Aurora PostgreSQL supports PostgreSQL majors up to 18 (released on Aurora on 11 June 2026), with 13 now only in paid RDS Extended Support. Instances are either provisioned classes or Aurora serverless, which for Aurora PostgreSQL scales from 0 to 384 ACUs. See our Amazon Aurora guide and Aurora PostgreSQL guide.

AlloyDB for PostgreSQL is Google Cloud's fully managed, PostgreSQL-compatible service: a Google-built engine on disaggregated compute and regional storage. A cluster has exactly one primary instance (basic or highly available) and optional read pool instances with up to 20 nodes in total, all reading the same storage. The AlloyDB version policy lists PostgreSQL 14 to 18, with 18 as the default. AlloyDB adds a columnar engine, AlloyDB AI extensions and a downloadable edition, AlloyDB Omni. There is no MySQL edition. See our AlloyDB guide.

Side by side

Key differences

Similar architecture, different add-ons

At the core the two services look alike. Both replace PostgreSQL's local disk with a distributed storage layer that is replicated across zones and shared by every instance in the cluster, so adding a reader does not copy the data and failover does not need a full catch-up. Both keep the PostgreSQL wire protocol, so psql, pgAdmin, DBeaver and ordinary drivers connect unchanged, and both publish their own lists of supported extensions, which you should check before migrating.

The differences are in what each vendor built on top. Aurora leans on elasticity and AWS integration: serverless instances that scale in ACUs and can pause at zero, Global Database across Regions, Babelfish so SQL Server clients can connect over TDS, and Limitless Database for horizontal write scaling. AlloyDB leans on mixed workloads: the columnar engine, AlloyDB AI and an engine you can also run yourself as Omni. Google states that, in its tests, AlloyDB Omni runs transactional workloads more than twice as fast and analytical queries up to 100 times faster than standard PostgreSQL, and AWS makes its own throughput claims for Aurora against stock PostgreSQL. These are vendor figures that we have not reproduced, and neither vendor measures against the other.

Analytics: in-database columnar engine or zero-ETL to a warehouse

If reporting queries must run on live operational data, the two clouds take opposite approaches. AlloyDB keeps a columnar copy of selected columns in memory and lets the planner use it for scans, aggregates and some joins, on the primary or on a read pool. Google documents the limits: enabling it needs a restart, by default it uses 30% of instance memory, frequent row updates invalidate columnar data until it is refreshed, and small or indexed tables may still use the row store.

Aurora moves analytics out of the database. A zero-ETL integration replicates tables from an Aurora cluster into Amazon Redshift or an Amazon SageMaker lakehouse in near real time, where the warehouse does the heavy lifting. AWS documents conditions for Aurora PostgreSQL sources, such as primary keys on every replicated table, UTF-8 databases and at least one data filter pattern, and the integration cannot use a Limitless Database cluster as its source. A typical query that either approach is meant to serve:

-- PostgreSQL: monthly revenue by region on live order data
SELECT region,
       date_trunc('month', ordered_at) AS month,
       SUM(amount) AS revenue,
       COUNT(*) AS orders
FROM orders
WHERE ordered_at >= now() - interval '12 months'
GROUP BY region, date_trunc('month', ordered_at)
ORDER BY month, region;

Scaling, serverless and multi-region

For reads, Aurora allows up to 15 replicas and AlloyDB up to 20 read pool nodes per cluster. For capacity that follows demand, only Aurora has a serverless option: an Aurora serverless instance scales between a minimum and maximum you set, up to 384 ACUs for Aurora PostgreSQL, and at a minimum of 0 ACUs it pauses when idle. AlloyDB instances use fixed machine shapes that you resize; the smallest 1 vCPU shape is intended for development only and has no uptime SLA.

For writes beyond one primary, Aurora PostgreSQL offers Limitless Database, which shards data across multiple writers inside one database. AlloyDB has no equivalent; Google's option for horizontal write scaling is a different product, Spanner. Across regions, Aurora Global Database replicates to up to 10 read-only secondary Regions, and AlloyDB streams data asynchronously from a primary cluster to secondary clusters in other regions. Both can promote a secondary for disaster recovery.

Portability and lock-in

Both services are managed-only on their own clouds, but AlloyDB has an escape hatch that Aurora does not: AlloyDB Omni is a downloadable edition, distributed as a container and as RPM packages, that runs in your data centre, on other clouds or on a laptop and includes the columnar engine and AlloyDB AI. Production use is licensed per vCPU. Aurora has no self-managed edition.

For a real exit, the more important point is that both speak PostgreSQL. Data and schema can be moved with standard tools such as pg_dump or logical replication, as long as you have avoided engine-specific features (Babelfish, Limitless, AlloyDB AI functions, ScaNN indexes) or planned how to replace them.

Pricing and licensing

Amazon Aurora PostgreSQL (US East, N. Virginia, USD, from the rates in AWS's Aurora pricing examples on 7 November 2026): serverless capacity USD 0.12 per ACU-hour on Aurora Standard or USD 0.156 on Aurora I/O-Optimized; a provisioned db.r6i.large (2 vCPUs, 16 GiB) at USD 0.29 per hour on Standard or USD 0.377 on I/O-Optimized; storage USD 0.10 per GB-month on Standard or USD 0.225 on I/O-Optimized; read and write I/O USD 0.20 per million requests on Standard and no charge on I/O-Optimized. Backup up to 100% of cluster storage is included. A Free plan for new customers covers Aurora PostgreSQL serverless instances with up to 4 ACUs and 1 GiB of storage per cluster. Reserved instances and Database Savings Plans lower the rates for commitments.

Google AlloyDB (Iowa, us-central1, USD, from cloud.google.com/alloydb/pricing on 7 November 2026): USD 0.06608 per vCPU-hour and USD 0.0112 per GiB-hour of memory on demand (USD 0.04956 and 0.0084 with a one-year commitment, 0.0317184 and 0.005376 with three years); regional cluster storage USD 0.0004109 per GiB-hour; standard backup storage USD 0.000137 per GiB-hour. A highly available primary bills two nodes. There are no I/O charges, and the first seven days of transaction logs for continuous backup are free. A 30-day free trial cluster offers an 8 vCPU basic instance with up to 1 TB of storage.

As arithmetic on these list prices: an AlloyDB HA primary with 4 vCPUs and 32 GiB per node is 2 x (4 x 0.06608 + 32 x 0.0112) = about USD 1.25 per hour before storage, and two Aurora db.r6i.large instances (writer plus one replica, 2 vCPUs and 16 GiB each) on Aurora Standard are 2 x 0.29 = USD 0.58 per hour before storage and I/O. The shapes, regions and I/O models differ, so these numbers show how each bill is built, not which service is cheaper; price your own shape in each vendor's calculator.

Pricing checked on the vendors' official pages on 7 November 2026. Prices change; confirm before buying.

Where each one leads

Limitations

When to choose each

When neither is right

• Your database is small or a development system: standard managed PostgreSQL is cheaper; see Aurora PostgreSQL vs RDS PostgreSQL and Google Cloud SQL vs AlloyDB.
• You need serverless PostgreSQL with branching and per-use billing: see Neon vs AWS RDS and Supabase vs Neon.
• You need globally distributed writes with strong consistency: see CockroachDB vs PostgreSQL, or consider Google Spanner.
• Your workload is mainly large-scale analytics: see BigQuery vs PostgreSQL and Redshift vs PostgreSQL.

Final recommendation

Frequently asked questions

Sources

• Aurora User Guide: Working with Amazon Aurora PostgreSQL
• Aurora PostgreSQL release calendars
• Aurora User Guide: How Aurora serverless works
• Aurora User Guide: Aurora zero-ETL integrations
• Aurora User Guide: Aurora machine learning with Aurora PostgreSQL
• Amazon Aurora pricing
• Amazon Aurora SLA
• AlloyDB overview
• AlloyDB: Database version policies
• AlloyDB: About the columnar engine
• AlloyDB Omni overview
• AlloyDB pricing
• AlloyDB SLA

Checked November 2026.

How we research comparisons: our editorial method.