Fourth in a series of dispassionate tours of managed PostgreSQL services. Previously: RDS, Aurora, and Cloud SQL. AlloyDB is Google’s distributed-storage PostgreSQL, the closest architectural parallel on GCP to Aurora on AWS, with enough distinctive differences to be worth understanding as its own thing rather than “GCP’s Aurora.”
Overview
AlloyDB for PostgreSQL is Google Cloud’s managed, PostgreSQL-compatible database service. It pairs a PostgreSQL-derived query engine with a custom distributed storage layer, adds an in-memory column-store engine for analytical queries, and bundles a set of ML-assisted operational features. The compute layer runs the forked engine; the storage layer is a Google-managed, log-structured, distributed service that processes WAL records and serves data pages to the compute instances.
If that sounds like Aurora, it is structurally similar: separation of compute and storage, redo-based replication to a shared storage volume, readers reading from the same distributed volume as the writer. It is also structurally distinct in several ways that matter operationally.
The storage layer is described by Google as “intelligent,” meaning it performs WAL processing, continuous cleanup of old row versions, and page materialization closer to storage rather than strictly on the compute node. Whether that is an architectural advantage or a more elaborate description of an Aurora-equivalent design depends on the workload.
AlloyDB has a columnar engine, an in-memory column store that coexists with the row-oriented heap and is used automatically by the query planner for suitable analytical queries.
It also has a self-managed variant, AlloyDB Omni, which runs the same engine outside of Google Cloud: on-premise, on other clouds, on Kubernetes. This is an unusual choice. Neither Aurora nor Cloud SQL has a corresponding “run it yourself” path, and Omni changes the portability story substantially.
Finally, Google has a history of contributing upstream to PostgreSQL, and some of the ML-assisted features in AlloyDB (index advice, vacuum tuning) show visible lineage to its research on learned database systems.
This post covers AlloyDB on Google Cloud, with notes on where Omni is meaningfully different.
Architecture
The storage layer
AlloyDB’s storage is a distributed log-structured service. The primary sends WAL records to the storage layer; the storage layer persists those records redundantly and, in Google’s framing, “processes” them, applying them to pages, maintaining row-version metadata, and performing vacuum-like operations continuously rather than batching them into a periodic vacuum pass on the compute node.
The storage layer replicates across zones within a region for durability: writes are durable across zones before the primary acknowledges the commit. The specific replication factor (how many copies, how many zones, what quorum) is less explicitly documented than Aurora’s “4 of 6 across 3 AZs.” Google describes the architecture at a higher level and has historically shared fewer implementation specifics. This is a recurring theme, and one of the few genuine operational drawbacks of the platform; more on it below.
Commit latency on AlloyDB is typically low single-digit milliseconds for a healthy regional deployment, bounded by the round trip to the storage service plus the storage service’s durability commit. Broadly Aurora’s range.
Clusters, primary instances, and read pools
An AlloyDB deployment is organized as a cluster. A cluster has exactly one primary instance (the writer), zero or more read pool instances (each of which can have one or more nodes), and optionally one or more secondary clusters in other regions for cross-region replication, discussed below.
A read pool is a named, load-balanced set of read-only nodes. This differs from Cloud SQL, where each read replica is an independent billed instance addressed individually. An AlloyDB read pool presents a single endpoint, and the pool can be resized without changing the endpoint or the application’s connection configuration.
A cluster can have multiple read pools: one small pool for application traffic, a separate larger pool for analytics. That gives a finer-grained isolation model than the “add more readers to the cluster” approach.
Read semantics and lag
As with Aurora, AlloyDB readers share the primary’s storage volume. Replica lag is not streaming-replication catch-up lag; it is buffer-cache staleness lag. A reader’s local buffer cache can hold an older page version than what storage has. Typical observed lag on a healthy cluster is in the tens of milliseconds. Not zero.
Read-after-write correctness on a reader still requires the application-level handling that any asynchronously-replicated system requires: read from the primary for just-written data, or use session-level consistency tokens if available.
Failover
A primary failure triggers promotion. Because storage is shared, promotion does not copy data or replay WAL; it rebinds the primary role to another compute instance. Every AlloyDB primary configured for HA runs an active node and a standby node in different zones, and failover swaps the two.
A single-instance cluster (primary with no HA standby) has no in-region peer to fail over to and requires instance recreation, which takes materially longer. If you are running AlloyDB and care about availability, configure the standby. This is not the place to save money.
Cross-region: secondary clusters
AlloyDB supports cross-region replication via secondary clusters. A secondary cluster is a read-only replica of a primary cluster in a different region, with its own compute and storage. Replication is at the storage layer, asynchronous, with cross-region lag typically sub-second. A primary can have up to five secondary clusters, and each secondary can carry its own read pool of up to twenty nodes, so the model fans out for both DR and geographically-distributed reads.
There are two ways to flip a secondary into a writer, and they are not the same operation.
Promotion is the disaster-recovery path. You promote a secondary when the primary region is gone or going. It is one-way: the secondary becomes an independent read-write cluster, the old primary is disconnected, and rebuilding replication in the other direction is a separate re-provisioning. Because replication is asynchronous, promotion can lose the last sliver of unreplicated writes.
Switchover is the planned path, and it is newer. For a cross-region setup, AlloyDB now supports a coordinated switchover between primary and secondary with zero data loss: it quiesces the primary, lets the secondary catch up, swaps the roles, and re-establishes replication in the reverse direction automatically. This is the operation you want for a planned regional migration or a DR drill. Promotion is what you reach for when you no longer have the luxury of a clean handoff.
What AlloyDB still does not have is write forwarding. Writes go to the primary region. A secondary is read-only until promoted or switched over. Workloads that need active-active or write-from-anywhere across regions will not find it here.
The columnar engine
AlloyDB includes a columnar engine, an in-memory column store that runs alongside the row-oriented heap. Tables and columns can be materialized into it explicitly, or selected automatically based on workload patterns; the relevant knob is google_columnar_engine.enable_auto_columnarization. The query planner is aware of the column store and uses it for queries where column-oriented access is faster.
Mechanically, this is a separate in-memory data structure on the compute node, populated from the row store and maintained in the background. The benefit is that analytical queries (aggregations over large scan ranges, narrow column projections) run against columnar data and skip the page-and-row overhead of heap access. More recently, the columnar engine can also accelerate vector search over ScaNN and HNSW indexes, which folds the analytical-acceleration path into AlloyDB AI’s vector story.
Google’s headline number for the columnar engine is 100x for analytical queries versus stock PostgreSQL on the same data, and it is product-page-shaped. Independent testing tends to land at “10x to 100x, for the right query.” Real-world speedups depend on whether the relevant tables are materialized in the column store, whether the query shape fits columnar access, how much of the columnar data fits in memory, and how good the planner’s decision is about when to use the columnar path. Teams considering AlloyDB for HTAP should benchmark their own queries rather than treat the headline number as a floor.
AlloyDB AI and pgvector / ScaNN
AlloyDB AI is the branded bundle of vector-search and ML-inference features. Its practical components:
pgvector with Google enhancements. AlloyDB ships pgvector and has made a point of tracking upstream closely, with some Google-specific optimizations layered on.
ScaNN. Scalable Nearest Neighbors, Google’s vector-search algorithm, exposed as an index type. ScaNN has a different tradeoff profile than pgvector’s HNSW and IVFFlat indexes: it targets high-recall, high-throughput scenarios and has its own tuning knobs. Whether ScaNN or HNSW is the right choice for a given workload is an open question that depends on data characteristics and query patterns. Benchmark it.
Integration with Vertex AI. Query-time invocation of Vertex AI models (embedding generation, prediction, classification) directly from SQL. A clean integration for workloads that want inference to happen next to the data, and GCP-specific.
AlloyDB has also accumulated the now-obligatory generative-AI operational features: a conversational SQL tool (QueryData, in preview) and Gemini Cloud Assist investigations for AI-assisted troubleshooting. The latter now requires a Premium Support contract. Treat these as conveniences to evaluate on their merits, not as reasons to choose the platform.
Extensions and the allow-list
AlloyDB maintains an extension allow-list, similar in spirit to Cloud SQL’s and Aurora’s. The commonly-needed extensions are present. The list is not identical to Cloud SQL’s; an extension on one is not automatically on the other. Custom C extensions are not supported on managed AlloyDB. On Omni, the extension story is more open, because the environment is yours.
AlloyDB Omni
AlloyDB Omni is the downloadable, self-managed variant of the AlloyDB engine. It ships as a container (google/alloydbomni), runs on a VM, bare metal, or Kubernetes, on any cloud or on-premise, and uses local storage rather than the Google-managed distributed storage service. It is source-compatible with the managed service at the query and application level.
Omni exists for two customer-visible reasons: development and test environments that do not depend on Google Cloud, and organizations with regulatory or sovereignty constraints that need the engine in environments where Google Cloud cannot go.
The operational model for Omni is closer to self-managed PostgreSQL than to managed AlloyDB. The columnar engine and the Vertex AI integration are available (the latter with appropriate configuration and network access). The managed features (automated backups, PITR, read pool scaling, cross-region replication) are not. Those are yours to operate.
Omni gives AlloyDB a portability story that Aurora does not have. It does not eliminate lock-in: the engine, the optimizer, and the columnar engine are all Google’s. But “running the same engine somewhere else” is a supported operation rather than a migration.
Features
Automated vacuum and visibility management
AlloyDB’s storage layer performs continuous background work on row versions, cleaning up old versions without the customer running or tuning VACUUM. The observable effect is that autovacuum-shaped operational problems (bloat accumulation, autovacuum running too aggressively or not aggressively enough, long-running transactions starving vacuum) are less prominent than on stock PostgreSQL.
Less prominent is not eliminated. A workload with very long-running read transactions still pins row versions, and the storage service cannot clean those up. The MVCC constraints still apply. What AlloyDB changes is the routine operational work of keeping vacuum healthy, not the mathematics underneath.
Index advisor
AlloyDB includes an automated index advisor that analyzes query workloads and recommends indexes. It is enabled by default and now also recommends vector indexes (ScaNN) in addition to conventional ones. Conceptually this is a query-log-driven analysis, similar to hypopg plus a workload analyzer; recommendations surface in the console, and applying them is a manual decision.
An index advisor is useful. It is not a substitute for a DBA’s judgment about whether an index earns its write-amplification cost, and it does not reliably recommend dropping indexes that have gone unused, which on a long-lived system is often the more valuable operation.
Query Insights
Broadly similar to Cloud SQL’s Query Insights: top-query analysis, wait-event breakdown, plan capture. Teams moving between the two will find the tooling familiar.
Backup and PITR
Continuous backup with point-in-time recovery, configurable retention, and cross-region backup copies. The mechanics are similar to Cloud SQL and Aurora: continuous WAL capture in the storage layer plus periodic materialized snapshots, with PITR implemented by replaying to a point.
Networking
AlloyDB uses the same Private Services Access and Private Service Connect networking model as Cloud SQL. PSC is the newer, more featureful path; PSA is the older one. The same advice applies: prefer PSC. AlloyDB is younger than Cloud SQL, so there is less PSA legacy to drag along, but new deployments should still standardize on PSC.
IAM authentication
IAM authentication works similarly to Cloud SQL. The AlloyDB Auth Proxy plays the same role as the Cloud SQL Auth Proxy: a client-side authenticated connection endpoint that uses IAM credentials. The two are separate tools that behave alike.
Major version support
AlloyDB tracks upstream PostgreSQL with a lag, and because the engine is forked and the storage layer is specific, supporting a new major version takes porting work. Google states a target: managed AlloyDB aims for compatibility within five months of a community GA release, and Omni within eight. In practice the lag has run longer for some versions. PostgreSQL 18 reached GA on AlloyDB in May 2026, against a community GA the previous September. The default major version for new clusters is currently PostgreSQL 16; you choose the major version at cluster creation, and a cluster keeps it for life unless you run an in-place major-version upgrade.
Newer in 2026: AlloyDB now offers Extended Support for major versions past their community EOL, three years of continued security and bug fixes for a fee, with clusters auto-enrolled when their version reaches EOL. The mechanics will be familiar to anyone who has bought back-patched PostgreSQL support before; the difference is that here you are buying it for Google’s fork, from Google.
Migration in: Database Migration Service
Database Migration Service supports Cloud SQL to AlloyDB and third-party-PostgreSQL to AlloyDB as documented paths. The mechanics are logical-replication-based with a cutover, like other DMS flows.
Non-brochure concerns
The “intelligent storage” framing is thinner than Aurora’s
Google describes AlloyDB storage in higher-level terms than AWS describes Aurora storage. AWS has published detailed material on Aurora’s replication protocol, quorum choices, and write path. Google has stayed more abstract. This is a documentation-and-communication observation rather than a claim about the architecture, but it matters operationally: the customer has less visibility into what is happening under the instance. For teams used to reasoning about performance anomalies from published internals, AlloyDB can feel constraining.
Columnar engine benefits are workload-specific
The 100x number is achievable for specific analytical queries on specific data: wide scans with aggregation over columnar-eligible columns. For the common OLTP query that looks up a handful of rows by index, the columnar engine is irrelevant. Teams evaluating AlloyDB for HTAP should benchmark their actual query mix and not assume the headline generalizes.
There is also a storage cost. Columnar data is materialized in addition to the row-oriented heap, not instead of it. A table in the column store consumes memory for both representations. On large tables, that has real memory and sizing implications.
Fork lag versus upstream
AlloyDB is a fork. It lags upstream on major versions (now bounded by a stated target, but still a lag), and some behaviors differ from stock PostgreSQL because of the storage layer. Tuning advice that assumes stock on-disk WAL, stock checkpoint behavior, or stock autovacuum does not always translate.
Vendor lock-in, narrowed by Omni
The lock-in story differs from Aurora’s primarily because of Omni. An organization that commits to managed AlloyDB and later needs to leave Google Cloud has two paths: logical replication to a different PostgreSQL variant (the classic path), or lifting the workload onto Omni (the distinctive path).
The second path is less migration-shaped and more operations-shaped. It does not eliminate the work of taking over an engine’s operation, but it avoids the data-model and behavior-difference problems that switching to a different PostgreSQL variant introduces. The engine is portable; the managed-service experience is not.
No true SUPERUSER
Same constraint as Cloud SQL, RDS, and Aurora. alloydbsuperuser provides the elevated privileges appropriate to a managed service. Operations requiring true SUPERUSER are not permitted on managed AlloyDB. On Omni you have full SUPERUSER, because it is your install.
The columnar engine is in-memory
The column store lives in memory, bounded by what the compute instance can hold. For tables whose full columnar representation will not fit, the engine keeps the most useful subset. This is generally invisible, but it is worth knowing when reasoning about whether a workload will see the claimed speedups. If the important columnar data does not fit in memory, the benefit degrades.
Operational track record
AlloyDB is newer than Aurora, Cloud SQL, and RDS. The corpus of public postmortems, mailing-list threads, and independent operational experience is smaller. A team running AlloyDB in production leans on Google documentation and Google support as the primary knowledge base to a greater degree than with the older services. That is a knowledge-availability observation, not a knock on the product, and it resolves with time.
Read pool sizing and cost
Read pool nodes are full compute instances. “Adding a node to the read pool” costs the same as “adding an instance.” The single-endpoint, load-balanced convenience is real; the cost model is still per-node.
Cross-region replication does not include write forwarding
Writes go to the primary region. A secondary in another region is read-only until promoted or switched over. Active-active and write-from-anywhere are not available.
Scaling is disruptive
AlloyDB compute instances can be resized, but a resize involves an instance restart and, on an HA deployment, a failover. Both scale-up and scale-down are operationally significant events. Teams used to elastic-compute models tend to underweight how disruptive a resize is.
Omni-versus-managed parity is not complete
Omni is the AlloyDB engine. It does not implement the managed-service features: automated PITR across a fleet, the managed observability console, cross-region replication via secondary clusters. Evaluate Omni in production as a self-hosted PostgreSQL fork with some Google-specific advantages (the columnar engine, Vertex AI integration), not as “managed AlloyDB without the GCP dependency.”
Positives
Columnar engine for HTAP. For workloads that genuinely benefit from column-oriented access (analytical queries mixed with OLTP on the same dataset), the columnar engine is a real advantage over both stock PostgreSQL and Aurora. A team whose HTAP ambitions would otherwise force a separate data warehouse may find AlloyDB keeps the architecture simpler.
Read pools as a primitive. Load-balanced, single-endpoint read scaling beats independent-read-replica models where each replica is its own endpoint the application has to track. For read-heavy applications, this is a day-to-day operational improvement.
Cross-region secondary clusters, with switchover. Straightforward regional DR with sub-second typical lag, up to five secondaries per primary, and a zero-data-loss switchover for planned role changes.
AlloyDB Omni for portability and sovereignty. Running the same engine off GCP is an unusual capability for a managed database, and it changes the commitment calculus for organizations worried about single-cloud dependency.
Automated vacuum offload. For workloads with a history of vacuum-related pain on stock PostgreSQL, the reduction in routine operational work is a real quality-of-life gain.
Vertex AI integration. For workloads that combine transactional data with ML inference (RAG, semantic search, real-time scoring), AlloyDB AI plus Vertex AI is more integrated than stitching Postgres to an external inference service.
ScaNN for vector search. Another tool in the vector-search box, with different performance characteristics than pgvector’s built-in index types. For the right workload (high recall, high throughput), it can outperform HNSW.
Close upstream tracking on pgvector. AlloyDB has made a specific effort to stay current with upstream pgvector.
Negatives
Less public operational track record. Newer product, smaller community corpus, more dependence on vendor support. Solvable, but only with time.
Fork lag versus upstream. Bounded by a stated target now, but it exists.
Extension allow-list. Managed AlloyDB constrains the extension pool. Omni does not, but that means taking on operational responsibility.
Columnar engine is opt-in per table and memory-bounded. The benefits require workload characterization and sizing. They are not free.
No write forwarding for cross-region. Writes route to the primary region. Active-active is not a supported pattern.
No true SUPERUSER on managed. Same as the other managed services.
Thinner public documentation of storage internals than Aurora. Teams used to deep operational reasoning from published architecture will find less to work with.
Omni-versus-managed feature gap. Omni is useful, but it is not a managed-service replacement.
Instance resize is disruptive. Scale-up and scale-down both involve failover events.
Best-fit workloads and organizations
HTAP workloads on GCP. Applications that legitimately need transactional and analytical work on the same data, where maintaining a separate warehouse is not worth the complexity. The columnar engine makes AlloyDB a defensible single-database choice for this where Cloud SQL would not be.
Read-heavy applications that value read pool ergonomics. The single-endpoint, elastic-pool model is a cleaner integration than independent read replicas.
ML-adjacent workloads integrating with Vertex AI. RAG, semantic search, and embedding generation next to transactional data.
Vector-search workloads where ScaNN’s characteristics justify the move off stock pgvector indexing. Verify by benchmarking.
Organizations with strong GCP commitments whose analytical requirements exceed Cloud SQL’s comfort zone.
Organizations that want PostgreSQL-compatible compute with portability insurance. Omni is a meaningful option that Aurora does not offer.
Poor fits
Small applications where Cloud SQL is sufficient. AlloyDB’s cost and complexity are overkill for workloads that fit comfortably in a Cloud SQL Enterprise instance. The marketing pull of “the new thing” over “the general-purpose option” pushes teams to AlloyDB for workloads Cloud SQL would serve perfectly well.
Workloads needing extensions outside the allow-list on the managed service. Omni is an option, but it is an operational commitment.
Teams with zero tolerance for vendor-specific behavior. AlloyDB is PostgreSQL-compatible, not PostgreSQL. Behaviors differ at the edges, and teams that rely on stock internals for operational reasoning will be frustrated.
Workloads requiring active-active cross-region writes. Not available.
Teams that need the operational depth of a mature, well-documented product. RDS, Aurora, and Cloud SQL all have longer track records.
Next in this series: Azure Database for PostgreSQL (Flexible Server), Microsoft’s current general-purpose managed PostgreSQL offering.