AlloyDB is PostgreSQL with the storage layer replaced. That one change is where its advantages and its price both come from, and it is the thing to understand before deciding whether to migrate.
Topic 1: The Architecture
Cloud SQL is PostgreSQL on a VM with a persistent disk. A read replica is a second VM with a second copy of the data, kept current by streaming replication.
AlloyDB separates the two: compute nodes are stateless-ish, and storage is a distributed, regional service that stores the write-ahead log and materialises blocks on demand.
What falls out of that:
- Writes are cheaper. The primary ships log records rather than full page writes, so the disk amplification that dominates ordinary Postgres write cost largely disappears.
- Read pools share the storage. Adding read capacity does not copy the database; a read pool node attaches to the same storage layer. Scaling reads is fast and does not add write amplification.
- Continuous backup is intrinsic. Point-in-time recovery comes from the log the storage layer already holds, so restore is quick and the retention window is a setting rather than a backup schedule.
- The columnar engine keeps a column-oriented copy of chosen tables in memory, which turns analytical queries against your transactional data from minutes into seconds.
gcloud alloydb clusters create checkout \
--region=europe-west1 --network=prod-vpc \
--continuous-backup-recovery-window-days=14
gcloud alloydb instances create checkout-primary \
--cluster=checkout --region=europe-west1 \
--instance-type=PRIMARY --cpu-count=8
gcloud alloydb instances create checkout-reads \
--cluster=checkout --region=europe-west1 \
--instance-type=READ_POOL --read-pool-node-count=2 --cpu-count=8
Topic 2: The Columnar Engine
The feature most likely to change how you build things:
-- Tell it which tables to keep columnar
SELECT google_columnar_engine_add('orders');
SELECT google_columnar_engine_add('order_items');
-- What is actually in memory
SELECT * FROM g_columnar_relations;
The planner chooses between the row store and the columnar copy per query. A dashboard aggregating a year of orders reads the columnar copy; a point lookup by primary key reads the row store. Both are the same table, and the application changes nothing.
Where this genuinely helps: operational analytics against live transactional data — the reports that today either run against a replica at 3am or get exported to BigQuery on a delay.
Where it does not: a warehouse workload over terabytes of history. That is still BigQuery, and the decision matrix in the Cloud SQL lesson still applies. The columnar engine is memory-resident, so its usefulness is bounded by what fits.
Verify rather than assume. EXPLAIN shows whether the columnar scan was chosen, and a query that does not benefit will simply not use it.
Topic 3: Availability and Recovery
HA is a property of the instance, and the failover is faster than Cloud SQL’s because there is no data to catch up — the standby attaches to the same storage:
gcloud alloydb instances create checkout-primary \
--cluster=checkout --availability-type=REGIONAL --cpu-count=8
Continuous backup replaces the backup schedule. You choose a recovery window, and PITR to any second within it is a restore into a new cluster — the same rule as everywhere else: a restore does not rewind the original.
gcloud alloydb clusters restore checkout-recovered \
--region=europe-west1 --source-cluster=checkout \
--point-in-time=2026-08-19T14:30:00Z --network=prod-vpc
Cross-region replication gives you a secondary cluster for DR, promoted manually — the same shape as a Cloud SQL cross-region replica, with the same honest caveat: promotion is a decision and a procedure, not automatic failover.
Maintenance follows a window you set, and uses the same failover mechanism, so an application that reconnects cleanly experiences a brief blip rather than an outage. Test that reconnect behaviour; it is the difference between the two.
Topic 4: Connecting and Securing It
AlloyDB is private-IP only by default, which removes the worst Cloud SQL misconfiguration by construction.
# The Auth Proxy, with IAM authentication
alloydb-auth-proxy \
projects/acme/locations/europe-west1/clusters/checkout/instances/checkout-primary \
--auto-iam-authn
The pattern from the Cloud SQL lesson carries over intact: private IP, connector or Auth Proxy, IAM database authentication, and no password stored anywhere. Secrets, where you still need them, come from Secret Manager.
Connection pooling matters more here, not less. Read pools multiply the number of endpoints an application can open connections against, and Postgres connection limits still apply per node. PgBouncer or a pooling driver in front is the difference between using a read pool and exhausting it.
Topic 5: Cost, Honestly
AlloyDB bills for vCPU and memory per node, plus storage, plus backup. It is meaningfully more expensive than a comparable Cloud SQL instance, and the case for it is one of:
- Read scale-out that read replicas make awkward or expensive.
- Mixed workload — transactional plus analytical — where the columnar engine removes a whole export pipeline.
- Write-heavy workloads where Cloud SQL’s disk throughput is the bottleneck.
- Faster recovery than a Cloud SQL PITR restore of the same data volume.
If none of those describe your workload, stay on Cloud SQL. A well-sized Cloud SQL instance with correct indexes beats a badly-sized AlloyDB cluster at a fraction of the price, and “our database is at 60% CPU” is an indexing conversation before it is a migration.
The measurement in the hands-on task is deliberate: migrate on numbers you produced, not on a feature list.
Topic 6: Migrating
AlloyDB is wire-compatible with PostgreSQL, so the application usually does not change. The migration itself is ordinary Postgres work:
Database Migration Service handles the common path — a continuous migration from Cloud SQL or a self-managed Postgres, with a cutover window:
1. DMS creates the destination and performs a full dump.
2. It streams changes continuously (logical replication under the hood).
3. You verify row counts and run the application against the destination read-only.
4. Cutover: stop writes, wait for lag to reach zero, promote, repoint.
What to check before you commit to the cutover:
- Extensions. AlloyDB supports most common ones; verify yours specifically rather than assuming.
- Query plans. The planner and the storage layer differ, so a query that relied on a particular plan may behave differently.
EXPLAINyour top twenty queries on both. - Connection limits and pooling, as above.
- Anything that reads the replica, since read pools are a different endpoint from a Cloud SQL replica.
Have a rollback. Keep the source running and writable-capable until you are confident, and know what it would take to point back — which usually means not deleting the source for a week.
Try it yourself: enable the columnar engine on one large table and run the same aggregate query before and after, with EXPLAIN both times. The plan change and the runtime difference are the whole argument for the feature, and it takes ten minutes to see.
Common mistake: migrating to AlloyDB to fix a performance problem that is a missing index or an N+1 query. The new cluster is faster, the problem is masked at greater cost, and it reappears at the next scale increment — this time with a more expensive bill and fewer easy options. Profile first with pg_stat_statements, fix what the profile names, and only then decide whether the platform is the constraint.