--- title: The curious case of Google's AlloyDB | daily.dev description: A year-long independent evaluation of Google's AlloyDB dissects its 'fully compatible with PostgreSQL' claim, finding it holds only at the wire protocol level... canonical: https://daily.dev/posts/the-curious-case-of-google-s-alloydb-m5gvqq6dx twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: The curious case of Google's AlloyDB | daily.dev og:description: A year-long independent evaluation of Google's AlloyDB dissects its 'fully compatible with PostgreSQL' claim, finding it holds only at the wire protocol level... og:url: https://daily.dev/posts/the-curious-case-of-google-s-alloydb-m5gvqq6dx og:image: https://api.daily.dev/og/posts/m5GVQQ6dx.png og:image:alt: The curious case of Google's AlloyDB og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # The curious case of Google's AlloyDB **[Planet PostgreSQL](https://daily.dev/sources/planet-postgresql)** · 44 min read · 0 upvotes · 0 comments ## Summary A year-long independent evaluation of Google's AlloyDB dissects its 'fully compatible with PostgreSQL' claim, finding it holds only at the wire protocol level while storage, VACUUM scheduling, and the write path diverge entirely. Benchmarks cover the log-as-database architecture, adaptive autovacuum (which reschedules but doesn't eliminate vacuum work), the in-memory columnar store's TPC-H performance (up to 311x on selective scans, near-zero on point lookups), ScaNN vector index size/build advantages with unresolved recall questions, read pool economics versus Cloud SQL replicas, AlloyDB Omni's divergence from the managed product, and governance implications of vendor-controlled PostgreSQL forks. Concludes AlloyDB fits GCP-native HTAP workloads with bursty read patterns, but extension allowlists, storage opacity, and compute costs make it a poor fit for small apps or teams needing deep PostgreSQL tooling access. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Does AlloyDB's storage engine actually offload VACUUM work from the compute node? No. Testing shows the compute node still runs standard autovacuum against its heap pages, with n_dead_tup showing the same saw-tooth pattern as stock PostgreSQL and autovacuum_count increasing with each pass (seven passes in seven minutes on both AlloyDB and Cloud SQL in one test). What Google changed is the scheduler, not the workload location: adaptive autovacuum boosts worker count when idle and throttles when busy, but dead tuple pruning, freezing, and visibility map maintenance remain compute-node responsibilities. _Teams tuning autovacuum across managed Postgres variants can track these architectural nuances on daily.dev._ ### How much faster is AlloyDB's columnar store than a row-store scan for analytical queries at large scale? At TPC-H scale factor 100 (about 600 million rows), a selective scan query (Q6) dropped from 182,546 ms with the row store to 595 ms with the columnar engine enabled, a roughly 307-311x speedup, because the columnar scan avoided reading 11.5 million heap pages entirely. Gains are far smaller for joins (9.8x), full-table aggregates (2x), and nonexistent for single-row point lookups, which the planner still routes through the b-tree index. _Engineers benchmarking HTAP workloads can follow real-world columnar performance breakdowns on daily.dev._ ### At what data size does AlloyDB's read pool become cheaper than Cloud SQL read replicas? For a flat, round-the-clock read workload, a three-node pool breaks even against Cloud SQL at about 3.9 TB of storage, since AlloyDB shares one storage copy across nodes while Cloud SQL duplicates storage per replica, despite AlloyDB's compute costing roughly twice as much per vCPU. With a bursty business-hours read pattern averaging 1.4 nodes instead of 3, the break-even point drops to around 765 GB, and below about a third of peak usage AlloyDB is cheaper at any dataset size. _Teams weighing managed Postgres read-scaling costs can compare these tradeoffs on daily.dev._ ## Similar posts on daily.dev - [AlloyDB Omni: Secure, hybrid database modernization for finance](https://daily.dev/posts/alloydb-omni-secure-hybrid-database-modernization-for-finance-dh2x0vi0q) · Google Cloud · 0 upvotes · 0 comments - [Announcing PostgreSQL for agents in AlloyDB](https://daily.dev/posts/announcing-postgresql-for-agents-in-alloydb-dyzuabrfv) · Google Cloud · 2 upvotes · 0 comments --- Tags: [#postgresql](https://daily.dev/tags/postgresql), [#vector-search](https://daily.dev/tags/vector-search), [#alloydb](https://daily.dev/tags/alloydb) [View this post on daily.dev](https://daily.dev/posts/the-curious-case-of-google-s-alloydb-m5gvqq6dx) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"The curious case of Google's AlloyDB","url":"https://daily.dev/posts/the-curious-case-of-google-s-alloydb-m5gvqq6dx","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/the-curious-case-of-google-s-alloydb-m5gvqq6dx"},"datePublished":"2026-08-15T15:48:00.637Z","dateModified":"2026-08-15T16:13:55.481Z","description":"A year-long independent evaluation of Google's AlloyDB dissects its 'fully compatible with PostgreSQL' claim, finding it holds only at the wire protocol level...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/c6c30eae0b010d15b3798aa6e9e35691?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/c6c30eae0b010d15b3798aa6e9e35691?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Planet PostgreSQL","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Planet PostgreSQL","logo":"https://media.daily.dev/image/upload/logos/placeholder.jpg","url":"https://daily.dev/sources/planet-postgresql"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/the-curious-case-of-google-s-alloydb-m5gvqq6dx","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"postgresql,vector-search,alloydb","timeRequired":"PT44M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Planet PostgreSQL","item":"https://daily.dev/sources/planet-postgresql"},{"@type":"ListItem","position":3,"name":"The curious case of Google's AlloyDB"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/the-curious-case-of-google-s-alloydb-m5gvqq6dx#faq","mainEntity":[{"@type":"Question","name":"Does AlloyDB's storage engine actually offload VACUUM work from the compute node?","acceptedAnswer":{"@type":"Answer","text":"No. Testing shows the compute node still runs standard autovacuum against its heap pages, with n_dead_tup showing the same saw-tooth pattern as stock PostgreSQL and autovacuum_count increasing with each pass (seven passes in seven minutes on both AlloyDB and Cloud SQL in one test). What Google changed is the scheduler, not the workload location: adaptive autovacuum boosts worker count when idle and throttles when busy, but dead tuple pruning, freezing, and visibility map maintenance remain compute-node responsibilities. Teams tuning autovacuum across managed Postgres variants can track these architectural nuances on daily.dev."}},{"@type":"Question","name":"How much faster is AlloyDB's columnar store than a row-store scan for analytical queries at large scale?","acceptedAnswer":{"@type":"Answer","text":"At TPC-H scale factor 100 (about 600 million rows), a selective scan query (Q6) dropped from 182,546 ms with the row store to 595 ms with the columnar engine enabled, a roughly 307-311x speedup, because the columnar scan avoided reading 11.5 million heap pages entirely. Gains are far smaller for joins (9.8x), full-table aggregates (2x), and nonexistent for single-row point lookups, which the planner still routes through the b-tree index. Engineers benchmarking HTAP workloads can follow real-world columnar performance breakdowns on daily.dev."}},{"@type":"Question","name":"At what data size does AlloyDB's read pool become cheaper than Cloud SQL read replicas?","acceptedAnswer":{"@type":"Answer","text":"For a flat, round-the-clock read workload, a three-node pool breaks even against Cloud SQL at about 3.9 TB of storage, since AlloyDB shares one storage copy across nodes while Cloud SQL duplicates storage per replica, despite AlloyDB's compute costing roughly twice as much per vCPU. With a bursty business-hours read pattern averaging 1.4 nodes instead of 3, the break-even point drops to around 765 GB, and below about a third of peak usage AlloyDB is cheaper at any dataset size. Teams weighing managed Postgres read-scaling costs can compare these tradeoffs on daily.dev."}}]} ```