The one thing to understand first
AlloyDB is Google’s cloud-native, PostgreSQL-compatible answer to Aurora. Like Aurora it splits compute from a smart, distributed storage layer that understands the WAL. Its distinctive twist is a built-in columnar engine that lets the same database serve fast transactional and analytical queries — a hybrid (HTAP) design.
Disaggregated storage with a log-processing service
In AlloyDB the primary ships WAL to a regional storage layer rather than writing pages to a local disk. A log processing service continuously replays that WAL to materialize and cache data blocks, so the storage layer always holds current pages without the compute tier doing checkpoint-style page flushing. Storage is replicated across zones for durability and can scale independently of compute. This is the same disaggregation principle as Aurora, implemented Google’s way.
Read pools that share storage
Instead of individually-provisioned read replicas each with their own disk, AlloyDB offers read pools: groups of read-only nodes that attach to the shared storage layer. You scale read throughput by adding nodes to a pool, and because they share storage they stay current with low lag and start quickly — again echoing Aurora’s shared-storage replica model.