AlloyDB is a fully managed database service on Google Cloud that is compatible with PostgreSQL but has a redesigned engine underneath.

Start with the problem

A database is organized storage for information that programs need to find and change quickly and safely. A relational database keeps information in tables made of rows and columns, much like spreadsheets that are linked together, and it is queried using a language called SQL. Banks, shops, schools and hospitals rely on this model because it keeps data consistent: if you transfer money, either both the withdrawal and the deposit happen, or neither does.

What is PostgreSQL?

PostgreSQL, often called Postgres, is a popular open-source relational database with a reputation for correctness and rich features. It handles complex queries, supports many data types including JSON and geographic data, and can be extended with add-ons called extensions. Thousands of tools, libraries and developers know it.

What is AlloyDB?

AlloyDB takes the PostgreSQL engine and runs it on a specially designed cloud foundation. Compute (the part that runs queries) is separated from storage (the part that keeps data), and the storage layer is smart enough to do database work itself. Google also adds features such as an in-memory columnar engine for fast reports, built-in tools for finding slow queries, and support for AI features such as vector search. You keep PostgreSQL compatibility, but you gain speed, availability and automation.

The name hints at the idea: an alloy is a mixture of metals that is stronger than any single metal. AlloyDB blends the openness of PostgreSQL with Google’s cloud infrastructure.

What does “managed” mean?

You do not install software, patch servers, configure backups by hand, or build failover scripts. Google runs the machinery: it provisions instances, applies updates, takes backups, replaces failed hardware and monitors health. You focus on your tables, queries and application.

Three ideas help everything else make sense: transactions, the two kinds of database workload, and how managed databases evolved.

Transactions and ACID

A transaction is a group of changes that must succeed or fail as one unit. Relational databases promise four properties for transactions, remembered by the word ACID:

• Atomicity: all or nothing. A half-finished transfer never remains.
• Consistency: rules such as “balances cannot be negative” are always respected.
• Isolation: two transactions running at the same time do not see each other’s half-done work.
• Durability: once the database says “committed”, the change survives crashes and power cuts.

OLTP and OLAP

OLTP (online transaction processing) means many small, quick operations: place an order, update an address, look up a customer. OLAP (online analytical processing) means fewer but much larger questions that scan millions of rows: total sales by region over three years. Traditionally these two jobs lived in separate databases, because they stress a system in opposite ways. Data was copied from the first to the second every night, so reports were always a bit stale. A system that serves both on the same data is called HTAP, for hybrid transactional and analytical processing. AlloyDB aims to be good at both.

How managed databases evolved

AlloyDB has its own vocabulary on top of PostgreSQL’s. Learn these words and the rest will feel familiar.

Cluster

When you create AlloyDB, you first create a cluster in one region. The cluster owns the data. It is the unit you back up, restore and replicate. Inside it you create instances that do the computing.

Instances

An instance is a compute node: it has CPUs and memory and runs the PostgreSQL engine. Each cluster has exactly one primary instance, which handles reads and writes. Optional read pool instances handle reads only. All of them look at the same underlying storage, which is a major difference from older replication designs where every replica kept its own full copy.

The PostgreSQL layers on top

Inside an instance you work with ordinary PostgreSQL ideas: databases, schemas, tables, indexes (lookup helpers that make searches fast), views, roles (users and groups), and extensions. Anything you know about these carries across.

Regions and zones

A region is a geographic area, and a zone is an isolated data center group inside it. AlloyDB spreads storage across zones in a region, and can place the primary and its standby in different zones, so the loss of one zone does not take your database down.

The central design idea of AlloyDB is to split the database into a compute layer and a smart storage layer.

The old way

In a classic PostgreSQL server, one machine does everything: it runs queries, keeps data on its own disks, writes logs, writes full data pages, and sends logs to replicas that each repeat all that work. If you want more storage you must resize the machine. If a replica falls behind, it must replay a long log. If the machine fails, recovery means replaying logs against the disk.

The AlloyDB way

AlloyDB separates the work into two layers:

• Compute layer: database instances that run the PostgreSQL engine and hold memory caches. They accept connections, plan and run queries, and decide what to change.
• Intelligent storage layer: a distributed, regional storage service that receives a compact log of changes, keeps all data replicated across zones, and builds the data pages itself in the background.

Because the layers are independent, you can resize compute without moving data, add read instances that attach to existing storage in minutes, and let storage grow automatically without planning disk sizes.

flowchart TB
  APP["Applications and tools"] --> PROXY["Connection endpoint: private IP, Private Service Connect or Auth Proxy"]
  PROXY --> PRI
  PROXY --> RP
  subgraph COMP["Compute layer"]
    PRI["Primary instance: reads and writes"]
    STB["Standby instance in another zone"]
    subgraph RP["Read pool"]
      R1["Read node 1"]
      R2["Read node 2"]
    end
    CE["In-memory columnar engine"]
    PRI --- CE
  end
  subgraph STO["Intelligent storage layer across zones"]
    LOG["Log processing service"]
    BLK["Block storage: data pages replicated in three zones"]
    LOG --> BLK
  end
  PRI -- "Write-ahead log records" --> LOG
  BLK --> PRI
  BLK --> R1
  BLK --> R2
  BLK -.-> STB
  BLK --> BAK["Continuous backup storage"]
    

Read the diagram from the top. Applications connect through an endpoint. Writes go to the primary, which sends compact log records to the storage layer. The storage layer processes them into data pages and keeps them safe in several zones. Read nodes and the standby fetch pages from the same storage rather than keeping their own copies. Backups are produced continuously from the same layer without burdening the primary.

Why this matters

• Faster writes: the primary sends only small log records, not whole data pages.
• Faster replicas: new readers do not copy the whole database, they just attach.
• Faster recovery: after a failure, a new instance picks up from shared storage instead of rebuilding its own disk.
• Simpler growth: storage expands automatically as data grows.
• Less interference: backups and maintenance of pages happen in the storage layer, not on your query machine.

Let us follow a write and a read all the way through the machinery.

What is the write-ahead log?

Databases protect your data with a rule: before changing the real data, write a short note describing the change into a special file called the write-ahead log, or WAL. If the machine crashes, the database replays the notes to rebuild any lost work. In many systems, the primary must also write full data pages to disk and send every log record to each replica.

What the AlloyDB primary does on a write

sequenceDiagram
  participant A as Application
  participant P as Primary instance
  participant L as Log processing service
  participant S as Block storage
  participant R as Read pool node
  A->>P: Update an order
  P->>P: Change page in memory cache
  P->>L: Send write-ahead log record
  L->>L: Store log in multiple zones
  L->>P: Acknowledge durable log
  P->>A: Commit successful
  L->>S: Build updated data page in background
  R->>S: Fetch page when needed
  S->>R: Return current page
    

What the primary does not do

In standard PostgreSQL, the primary periodically performs heavy housekeeping called checkpoints, writing many modified pages to disk in bursts, which can cause pauses in performance. In AlloyDB, page writing is the storage layer’s job, so those bursts do not land on your query machine. Likewise, full-page writes used to guard against partial page damage are not needed in the same way, which cuts the volume of log traffic.

Reading data

A read first looks in the instance’s own memory caches. If the page is not there, the instance asks the storage layer for the page. The storage layer produces the right version of that page by combining the last stored image with any newer log records, so a reader always sees consistent, up-to-date data. Google also adds a faster secondary cache layer on top of the usual memory buffers, which keeps more of your frequently used data close to the CPU.

Why replicas are fresh

Because all instances read from the same storage, read pool nodes do not replay a long stream of changes on their own disk. Typically they stay very close behind the primary, often within a few milliseconds, though a brief delay is still possible under heavy load. This is why read pools are cheap to add and quick to start.

Choosing the size of an instance is the first decision you make, and one of the easiest to adjust later.

Machine shapes

An AlloyDB instance is defined by how many vCPUs (virtual processor cores) it has, and how much memory comes with them. AlloyDB uses a fixed, memory-rich ratio: each vCPU comes paired with a generous amount of memory, since databases love memory. Available sizes range from small instances of a couple of vCPUs, suitable for testing and light work, up to very large ones with around a hundred or more vCPUs for heavy production loads. Google may add or change the exact list, so check the current documentation when planning.

How memory is used

• Shared buffers: PostgreSQL’s main memory cache for data pages. Frequently used pages stay here and are served instantly.
• Ultra-fast cache: an additional Google-added cache layer on fast local storage, that extends the memory cache and keeps hot data close to compute, so fewer reads need to travel to the storage layer.
• Work memory: temporary memory for sorting and joining within a single query.
• Columnar engine memory: a slice of memory that can hold column-oriented copies of selected data for fast analytics, covered later.
• Connection memory: each open connection uses some memory, so thousands of idle connections quietly eat capacity.

The more of your active data that fits in these caches, the less the instance needs to wait for storage, and the faster it feels. This is why a larger instance is often faster even if CPU use is low: it simply caches more of your data.

Storage that grows by itself

You do not choose a disk size for AlloyDB. The storage layer expands automatically as your data grows, up to a very large limit, and you are billed for the amount you actually use rather than for a size you guessed in advance. The data is replicated across zones as part of the service. This removes one of the most common outages in self-managed databases: running out of disk.

Changing size

You can scale an instance up or down by changing its vCPU count. The change replaces the compute node, so there is a short interruption for that instance, much like a quick restart. Because data lives in shared storage, nothing needs to be copied, which makes resizing quick compared with traditional databases. For high availability setups, the standby and the primary are updated in a careful order to minimize impact.

Many applications read far more than they write. AlloyDB lets you add readers without copying data.

What is a read pool?

A read pool is a group of read-only instances behind a single connection address. When applications connect to the pool’s address, AlloyDB spreads their connections across the nodes. You can add or remove nodes to match demand, and each node attaches to the cluster’s shared storage. Reading from a pool keeps heavy reporting queries and busy read paths away from the primary, which then has more capacity for writes.

flowchart LR
  W["Write traffic"] --> PRI["Primary instance"]
  RD["Read traffic from app"] --> RPE["Read pool endpoint"]
  RPE --> N1["Read node 1"]
  RPE --> N2["Read node 2"]
  RPE --> N3["Read node 3"]
  REP["Reporting tools"] --> RPE
  PRI --> STO["Shared regional storage"]
  N1 --> STO
  N2 --> STO
  N3 --> STO
    

Why read pools are different from classic replicas

• Shared storage: no copy of the database per replica, so adding a node is quick and does not multiply storage cost.
• Low lag: replicas track the primary closely, typically within milliseconds, but are not guaranteed to be instantly identical.
• Single endpoint: applications do not manage a list of replicas.
• Independent sizing: read nodes can have a different size from the primary, though a pool uses nodes of one size.

Using reads wisely

Not all reads are safe to send to a replica. Consider a shopper who just added an item to a cart and immediately reloads the page. If the page reads from a replica that is a few milliseconds behind, the item might briefly look missing. This is called read-your-own-writes trouble. Common solutions:

• Send reads that must see the very latest data right after a write to the primary.
• Send everything else, such as search pages, dashboards and reports, to the pool.
• Keep the application aware of two connection settings: one for writes, one for reads.

Reporting without hurting users

A single heavy report can consume the CPU that serves customers. Pointing reports at a read pool, or better, at a separate pool dedicated to analytics, protects the primary. The columnar engine can be enabled on such readers for even faster results.

High availability means staying up when parts fail. In databases, that means a failed machine must not mean a lost or frozen database.

Failures to expect

• A virtual machine or its host hardware fails.
• A whole zone has a power or network problem.
• A software bug crashes the database engine.
• A maintenance update restarts the instance.

How AlloyDB handles it

In a high availability configuration, the primary instance has a standby in a different zone of the same region. Because both use the same shared storage, the standby does not need to copy data. It is ready to take over, with a fresh compute node able to attach and continue. If the primary fails, AlloyDB detects the problem, promotes the standby to be the new primary, and redirects the endpoint so applications reconnect to the same address. The failover typically completes in about a minute or less, though conditions vary. Google provides a strong availability commitment, with a service level agreement that includes planned maintenance for properly configured high availability clusters. Check the current agreement for the exact terms.

What the application must do

During failover, open connections are dropped. A well-built application therefore expects occasional connection loss and recovers automatically:

• Retry failed requests with short, growing delays, being careful to retry only operations that are safe to repeat.
• Use connection pooling that discards dead connections and opens new ones.
• Set sensible timeouts so a call does not hang for minutes.
• Reuse the same endpoint so no address change is needed.
• Test failover regularly in a non-production environment; AlloyDB lets you trigger a failover on purpose for drills.

Read pool availability

Read pools have multiple nodes spread across zones. If one node fails, the endpoint stops sending connections to it and replaces it. For critical read paths, keep at least two nodes so one failure does not interrupt reads.

Zones protect you from a building failing. Regions protect you from a whole city or area failing, which is rare but possible.

Secondary clusters

A secondary cluster is a read-only copy of your primary cluster, located in a different region. AlloyDB continuously sends changes from the primary region to the secondary. The secondary has its own storage and instances. It can serve reads for users closer to that region and stands ready to be promoted to become a normal read-write cluster if the original region is lost. Since replication across long distances takes time, the secondary can lag a little behind. The amount of lag is monitored, and it is your recovery point: data written during the lag window could be lost in a sudden regional disaster.

flowchart LR
  subgraph R1["Region 1: primary cluster"]
    P["Primary instance"]
    PS["Regional storage"]
    P --> PS
  end
  subgraph R2["Region 2: secondary cluster"]
    S["Read-only instances"]
    SS["Regional storage copy"]
    S --> SS
  end
  PS -- "Continuous asynchronous replication" --> SS
  USERS1["Users near Region 1"] --> P
  USERS2["Users near Region 2"] --> S
  PROMO["Promote on disaster"] -.-> S
    

Two targets to define

• Recovery point objective (RPO): how much recent data you can afford to lose, measured in time. With asynchronous replication, it is the replication lag at the moment of disaster.
• Recovery time objective (RTO): how long the business can be down. It depends on how quickly you detect the problem, promote the secondary, and redirect applications.

Planning a regional failover

Other uses for secondary clusters

• Local reads: serve users on another continent with lower delay.
• Planned region migration: move production to a different region with a controlled switch.
• Drills: regularly practice failover so the real event is not the first time.

Replication protects against hardware failure. Backups protect against people and programs making mistakes.

Why backups still matter

If an engineer accidentally deletes a table, or a software bug corrupts values, every replica and every standby faithfully copies the damage. You need a way to go back in time.

Automated backups

AlloyDB takes automated backups on a schedule you can adjust, and keeps them for a retention period you choose. Because the storage layer handles backup work, taking a backup does not slow your queries noticeably. You can also take on-demand backups before a risky change, such as a big migration, and keep them as long as you like.

Continuous backup and point-in-time recovery

Beyond periodic snapshots, AlloyDB can continuously save the stream of changes. This enables point-in-time recovery (PITR): restoring the database to the state it had at a chosen moment, such as the minute before a bad deployment. The recovery window is limited to a number of days, which can be configured up to a maximum set by the service, so check the current limit.

Restoring is creating something new

Restoring a backup or recovering to a point in time creates a new cluster with the recovered data. It does not overwrite the running one. This is safer, because you can inspect the restored copy, extract the missing rows, and copy them back into production, or switch applications to the restored cluster if everything was damaged.

Good backup habits

• Test restores on a schedule and time them. An untested backup is a hope.
• Choose retention by business need, not default, remembering that backups are billed by the storage they use.
• Encrypt backups with the same keys policy as the database, including customer-managed keys when required.
• Protect backup access. People who can delete backups can erase your safety net.
• Document the procedure so a stressed engineer at midnight can follow it.

One database, two shapes of data. AlloyDB can keep a column-oriented copy in memory to answer large analytical questions fast.

Rows versus columns

A normal PostgreSQL table is stored row by row: all the details of one customer sit together. That is perfect for “show me everything about customer 77”. But for “what is the average order value across ten million orders?”, the database must read every full row just to look at one column. A columnar layout stores each column together: all the order values in one block, all the dates in another. Reading just one column becomes dramatically faster and the data compresses well too.

What the columnar engine does

The columnar engine in AlloyDB keeps selected tables and columns in an in-memory, column-oriented cache alongside the usual row-based storage. When a query would benefit, the planner automatically chooses to scan the columnar copy instead of the row data, using fast vectorized processing that handles many values per CPU step. The row-based data stays the source of truth, so transactions are unaffected and results are the same. Google reports large speedups for analytical queries, up to many times faster than standard PostgreSQL in its own benchmarks, though real gains depend on your queries and data.

Which data goes into it?

• Manually: you can tell AlloyDB which tables or columns to load into the columnar engine.
• Automatically: an automatic mode can observe your workload, recommend or choose columns that would benefit, and keep them loaded. It also keeps the columnar copy in step with recent changes.
• Size budget: the engine uses a configurable portion of the instance’s memory, so it competes with other caches. More memory means more columns can live there.

Hybrid transactional and analytical work

Without such a feature, teams often copy their data nightly into a separate analytics warehouse. With the columnar engine, many reports can run directly against live operational data, with no copy and no delay. This does not replace a full data warehouse for enormous, multi-source analytics, but it removes a lot of plumbing for moderate-size reporting needs, such as operational dashboards.

Protecting your transactions

Analytical queries are greedy. To keep them from harming customer-facing work, put them on a read pool, ideally a separate one, with the columnar engine enabled there. The primary remains focused on transactions.

Even the fastest engine can be slowed by a poorly written query. Good tuning is mostly about helping the database do less work.

How a query is executed

When a query arrives, PostgreSQL’s planner chooses a strategy: use an index or scan the whole table, join tables in one order or another. It estimates costs using statistics about your data. The executor then carries out the plan. A bad plan can be thousands of times slower than a good one, and most tuning is about steering the planner toward good plans.

The big levers

Tools AlloyDB provides

• Query Insights: shows which queries use the most time, how often they run, and where time is spent, with graphs over time. It helps you find the “top ten offenders”.
• Index advisor: studies your workload and suggests indexes that would speed up queries, and estimates the benefit, so you can choose which to create.
• pg_stat_statements: the standard PostgreSQL extension that tracks query statistics, used by many tools.
• Explain plans: PostgreSQL can show the plan it would use for a query, which reveals missing indexes or full scans.
• Adaptive autovacuum: adjusts cleaning to avoid both bloat and wasted effort.
• Managed connection pooling: an option to let the service handle many client connections efficiently.

A simple tuning routine

Let us follow one query from the application to the answer, to see where each AlloyDB feature fits.

flowchart TD
  A["Application sends SQL"] --> B["Connection pool or Auth Proxy"]
  B --> C["Instance accepts connection and authenticates"]
  C --> D["Parser and planner choose a plan"]
  D --> E{"Read or write?"}
  E -- "Write" --> F["Executor changes pages in memory"]
  F --> G["Log record sent to storage layer"]
  G --> H["Commit acknowledged"]
  E -- "Read" --> I{"Analytical and columnar copy exists?"}
  I -- "Yes" --> J["Scan columnar engine"]
  I -- "No" --> K{"Pages in memory caches?"}
  K -- "Yes" --> L["Serve from cache"]
  K -- "No" --> M["Fetch pages from storage layer"]
  J --> N["Return results"]
  L --> N
  M --> N
  H --> N
    

Step by step

• Connection: the application opens a connection, usually through a pool, and proves its identity using a database password or IAM-based login.
• Planning: the engine parses the SQL, checks permissions, and picks a plan.
• Execution of a read: the instance checks the columnar engine if the query is analytical and the data is loaded, otherwise its memory caches, and only as a last resort the storage layer.
• Execution of a write: changes are made in memory, a log record is shipped to storage, and the transaction is committed once that log is durable.
• Results: rows travel back to the application. Large results take network time, so asking only for what you need pays off.

Concurrency and isolation

Many users act at once. PostgreSQL uses multi-version concurrency control, often shortened to MVCC. Instead of locking a row so that readers must wait for writers, the database keeps several versions of a row, and each transaction sees the version that was current when it began. Readers do not block writers, and writers do not block readers. The price is that old versions pile up until vacuum cleans them, which is why vacuum health matters.

A database should be easy for your applications to reach, and unreachable for everyone else.

Private by default

AlloyDB instances are designed to be reached through private network addresses inside your Google Cloud network, not through the open internet. There are a few ways to connect:

Connecting from different places

• From Compute Engine or GKE: use private addresses in the same VPC.
• From Cloud Run or Cloud Functions: use a VPC connector or direct VPC egress, or the language connectors.
• From your laptop: use the Auth Proxy through a secure path, or a bastion host in your network.
• From another cloud or data center: use a VPN or dedicated interconnect into your VPC, then connect privately.

Connection management

Each PostgreSQL connection is a separate process consuming memory, so very high connection counts are expensive. Use connection pooling, either inside your application framework, with a pooler such as PgBouncer, or with the managed pooling option, so many application threads share a small number of database connections. Close idle connections, set sensible limits, and use timeouts so that an application bug does not exhaust the pool.

Address planning

When using private services access, you reserve a range of private addresses for Google-managed services. Reserve a range large enough for growth, and avoid overlap with your other networks, because changing it later is painful.

Databases hold the most valuable data a company owns, so security is built in layers.

Layer 1: who can manage the service (IAM)

Google Cloud Identity and Access Management decides who may create clusters, change instances, take backups or delete them. Give these powers only to a few trusted administrators, using narrow roles, and give applications no management permissions at all.

Layer 2: who can log in to the database

• Built-in database users: traditional usernames and passwords, stored in PostgreSQL. Use long random passwords, kept in Secret Manager, and rotate them.
• IAM database authentication: a person or service account logs in using a short-lived Google token instead of a password. There is no password to leak, and access can be revoked centrally.

Layer 3: what each user can do inside

PostgreSQL has roles and privileges. Grant each application only the rights it needs on the specific schemas and tables it uses. Features such as row-level security restrict which rows a user sees, for example “a salesperson sees only their own region’s customers”, enforced by the database itself.

Layer 4: encryption

• At rest: data, logs and backups are encrypted automatically with Google-managed keys. For stricter control, use customer-managed encryption keys in Cloud KMS, and rotate or revoke them under your own policy.
• In transit: connections use encrypted channels. Require encrypted connections in your settings, and let clients verify the server’s identity.

Layer 5: network isolation

Use private connectivity, restrict network paths with firewall rules, and consider VPC Service Controls to draw a perimeter that stops data from being copied out to unapproved projects, even by someone holding valid credentials.

Layer 6: watching and proving

• Cloud Audit Logs record administrative actions on the service.
• Database audit logging with the pgAudit extension can record statements and data access inside the database, which supports compliance needs.
• Alerts for unusual events, such as many failed logins or a new privileged role.

Modern applications increasingly want to search by meaning, not just by exact words. AlloyDB includes features for that.

What is an embedding?

An embedding is a list of numbers that represents the meaning of a piece of content, such as a sentence, a product description or an image. A machine learning model creates it. Things with similar meaning get similar lists of numbers. Two product descriptions, “comfortable running shoes” and “cushioned sneakers for jogging”, end up with number lists that are close together, even though they share almost no words.

What is vector search?

A list of numbers is called a vector. Vector search finds the stored vectors nearest to a query vector, which means finding the content closest in meaning. PostgreSQL gained this ability through the popular pgvector extension, and AlloyDB supports it, with additions of its own. For very large collections, checking every vector is too slow, so special vector indexes are used to find approximate nearest neighbors quickly. AlloyDB offers an index based on Google’s own ScaNN technology, which Google says can speed up vector search and reduce memory use compared with common alternatives. Check current documentation for details and limits.

Why do this inside the database?

• One system: your product records and their embeddings live together, so one query can combine meaning-based search with ordinary filters such as price, stock and region.
• Consistency: embeddings stay in step with the data and obey the same security rules and transactions.
• Less plumbing: no separate vector database to run, sync and secure.

Connecting to AI models

AlloyDB can call machine learning models, such as those hosted on Google’s Vertex AI platform, directly from SQL through an integration extension. This lets you generate embeddings for text stored in a table, or ask a model to classify or summarize content, without moving data through application code. Some newer capabilities allow natural-language questions to be translated into database queries. Because AI features evolve quickly, verify which are generally available before depending on them.

flowchart LR
  U["User question"] --> APP["Application"]
  APP --> EMB["Embedding model: turn question into a vector"]
  EMB --> Q["Vector query with filters"]
  Q --> DB["AlloyDB with vector index"]
  DB --> TOP["Top matching records"]
  TOP --> PR["Build prompt with the matching facts"]
  PR --> LLM["Large language model"]
  LLM --> ANS["Grounded answer to user"]
  DOCS["Documents and product data"] --> LOAD["Create embeddings and store"]
  LOAD --> DB
    

The retrieval-augmented generation pattern

Large language models are fluent but can invent facts, and they know nothing about your private data. In the pattern called retrieval-augmented generation (RAG), the application first retrieves the most relevant records from your database using vector search, then hands them to the model along with the user’s question. The model answers based on those real facts. AlloyDB serves as the trustworthy memory of such a system.

Other practical uses

The promise of AlloyDB is that most things you know about PostgreSQL keep working. Here is where that promise is strong, and where to check carefully.

What stays the same

• The language: standard SQL and PostgreSQL’s dialect, including stored functions, triggers, views, common table expressions and window functions.
• The protocol: existing drivers and object-relational mapping libraries connect as they would to PostgreSQL.
• Data types: text, numbers, dates, JSON, arrays, and many more.
• Tools: common clients, schema migration tools and monitoring agents.
• Major versions: AlloyDB supports several recent PostgreSQL major versions, and you pick one when creating the cluster. Newer versions arrive over time, and old ones are eventually retired.

Extensions

An extension adds features to PostgreSQL. AlloyDB supports a curated list of popular ones. Examples include extensions for geographic data (PostGIS), vector search (pgvector), query statistics (pg_stat_statements), cryptography, text search helpers, scheduling of jobs, and auditing. Because the service is managed, not every extension in the world is available, and extensions that require direct access to the server’s files or operating system are generally not allowed. Always check the current supported list before a migration.

Limits of a managed service

Checking before you move

• List every extension in use today, and confirm each is supported.
• Check settings you have customized, to see whether they exist as flags.
• Look for features that depend on local files, such as reading files from the server’s disk.
• Run your application’s test suite against a trial cluster.
• Compare query plans and timings for your most important queries, since a different engine may choose different plans.

Most teams arrive with an existing database. A careful migration is a project with planning, rehearsal and a safe way back.

Common migration paths

flowchart TD
  A["Assess source: size, versions, extensions, workload"] --> B["Design target: region, size, networking, security"]
  B --> C["Create AlloyDB cluster and connectivity"]
  C --> D["Initial full copy of data"]
  D --> E["Continuous change replication"]
  E --> F["Test application against target"]
  F --> G{"Tests and performance acceptable?"}
  G -- "No" --> H["Fix issues and retest"]
  H --> F
  G -- "Yes" --> I["Plan cutover window"]
  I --> J["Stop writes on source and let replication catch up"]
  J --> K["Promote target and switch applications"]
  K --> L["Monitor, keep source as fallback"]
  L --> M["Decommission source after stable period"]
    

Steps in plain words

Typical pitfalls

• Sequences and identity counters that are not synchronized, causing duplicate key errors after cutover.
• Large objects and unusual data types that need special handling.
• Missing extensions discovered late.
• Different query plans causing a few queries to be slower until statistics and indexes are tuned.
• Hardcoded addresses and credentials in applications and scripts.
• No rollback plan, which turns a small problem into an emergency.

You cannot fix what you cannot see. Observability means making the database explain what it is doing.

Metrics to watch

The tools

• Cloud Monitoring: gives built-in AlloyDB metrics, dashboards and alerting.
• Cloud Logging: collects PostgreSQL logs, error messages and slow-query logs, and audit logs.
• Query Insights: shows the heaviest queries, wait events and sampled plans.
• System insights: shows resource use over time, such as CPU, memory and storage.
• Database Center: a fleet-level view that highlights risks and recommendations across many databases.
• Active sessions views: built into PostgreSQL, showing what each connection is doing now, and who is blocking whom.

Alerts people can act on

Alert on symptoms that matter, such as high latency, error rates, failover events, replica lag beyond a threshold, or storage growing unusually fast. Avoid dozens of noisy alerts that train people to ignore them. Attach a short runbook to each alert that states what it means and what to check first.

Creating a database is day one. Keeping it healthy for years is day two, and most of the effort.

Maintenance updates

Google regularly updates the database engine and underlying infrastructure with security patches and improvements. You control when by setting a maintenance window, a day and hour range when updates may happen, and can request a deny period to avoid maintenance during critical business times. For high availability clusters, updates are performed in a rolling way so the interruption is brief. Google positions these updates as near-zero-downtime, but applications should still tolerate a quick reconnect.

Major version upgrades

Moving from one PostgreSQL major version to a newer one is a bigger step than a patch, because behavior, defaults and extension versions can change. Plan these upgrades like small migrations: read the release notes, test the application on a copy, check extensions, rehearse timing, take a backup, then upgrade in a quiet window. Do not let versions fall so far behind that support ends.

Routine chores

• Review slow queries monthly and fix the worst ones.
• Check indexes: remove unused ones, add missing ones.
• Watch table and index bloat and long-running transactions.
• Test backups and failover on a schedule.
• Review access: remove accounts of people and applications that no longer need access.
• Rotate secrets and keys according to policy.
• Review cost against usage and resize if needed.

Infrastructure as code

Create clusters, instances, users and settings through automation tools such as Terraform, rather than by clicking in the console. Written definitions are reviewed, repeatable and easy to copy for test environments. They also provide a clear history of what changed and why.

Schema changes without outages

• Add new columns as optional first, deploy code that handles both, then backfill and enforce.
• Create indexes using the concurrent option, so writes are not blocked during the build.
• Avoid long locks by making small, quick changes in steps.
• Use migration tools that record each change and can be rehearsed.

Runbooks and ownership

For each database, record who owns it, how to reach on-call staff, what its normal numbers look like, how to fail over, how to restore, and how to scale. Update the document after every incident.

A powerful database is rarely the cheapest option, so it pays to understand exactly where the money goes.

What you pay for

Prices vary by region and change over time, so use Google’s current pricing page and calculator for real numbers. Also note that Google may offer a free trial for new clusters, which is a good way to test without spending money.

The biggest cost drivers

• Instance size and count. Compute is usually the largest line. A standby and several read nodes multiply it.
• Always-on replicas. Idle read nodes cost money whether or not they are used.
• Over-retention of backups or very long recovery windows.
• Data growth from unneeded history, logs and duplicated tables.
• Cross-region traffic from secondary clusters and chatty applications in different regions from the database.

Ways to spend less

• Tune queries first. A single index can replace an instance upgrade.
• Right-size using real metrics, not guesses. Scale down when load drops.
• Use non-production wisely: smaller instances, no high availability for test environments, and stop or delete them when idle where the service allows.
• Use read pools only when needed, and size them to demand.
• Commit to discounts for the steady baseline you are sure to use.
• Archive old data to cheaper storage such as Cloud Storage or an analytics warehouse, and keep the live database lean.
• Keep the application in the same region as the database to avoid transfer fees and delay.
• Label resources by team and product to see who spends what.

When it pays off

AlloyDB’s higher performance can reduce the number of instances you need, and its built-in features can remove separate systems for replicas, analytics copies or vector stores. For small, lightly used databases, a standard managed PostgreSQL service is often cheaper. The best value usually appears where workloads are demanding, mixed, or growing.

An honest view of strengths and limits helps you decide whether AlloyDB is the right choice.

Choosing among Google Cloud databases

Compared with similar services elsewhere

Other cloud providers offer PostgreSQL-compatible services built on similar ideas of separating compute from storage, such as Amazon Aurora PostgreSQL. They share concepts like shared storage and fast replicas, but details differ: pricing models, replication features, extension lists, analytics acceleration and AI integrations. Google makes its own performance and price-performance claims, and independent testing on your workload is the only trustworthy comparison.

Patterns are proven solutions. Anti-patterns are tempting shortcuts that cause pain later.

Patterns worth knowing

Anti-patterns to avoid

If you remember only one chapter for real work, make it this one.

A practical order of work for a new production database

Common mistakes beginners make

• No indexes on frequently filtered columns, or too many indexes on write-heavy tables.
• Oversized instances to cover up slow queries.
• Unlimited connections from many application replicas.
• Long-running transactions that block cleanup and schema changes.
• Assuming replicas are perfectly current and reading just-written data from them.
• Skipping restore tests. The first restore should never be during an emergency.
• Public IP left on after testing.
• Using the highest-privilege user in application code.
• Heavy schema changes during business hours without testing on realistic data volume.
• Ignoring vacuum and bloat until performance drops.
• No cost controls, leading to forgotten clusters and idle replicas.
• Trusting benchmarks you did not run. Vendor numbers are a hint, not a promise for your workload.

Here are the common ways organizations use PostgreSQL-compatible, cloud-native databases like AlloyDB, based on typical industry practice. Google publishes customer stories on its website for named examples, and you should consult them for current details.

Most database problems fall into a few families. Start with the symptom and check the most likely causes in order.

A calm first-response routine

Not every workload can live in one cloud. AlloyDB Omni is a downloadable edition that brings much of AlloyDB’s engine to other places.

What is Omni?

AlloyDB Omni is a version of the AlloyDB database engine packaged to run on your own machines: a developer laptop, a server in your data center, a virtual machine in another cloud, or a Kubernetes cluster. It keeps PostgreSQL compatibility and includes Google’s engine improvements such as the columnar engine and AI-related capabilities, subject to what is included in the current release. Because it is self-run, you are responsible for operations that the managed service would otherwise perform: installing, backups, high availability design, patching and monitoring. Google offers an operator for running it on Kubernetes that automates many of these tasks.

Why would you use it?

Managed service versus Omni

AlloyDB takes the PostgreSQL you already know and runs it on a redesigned cloud foundation. Compute is separated from a smart, shared storage layer that receives only log records, builds data pages itself, replicates across zones and produces backups without disturbing your queries. That design gives quick commits, fast read replicas, quick recovery and storage that grows on its own. On top sit an in-memory columnar engine for analytics, tools to find and fix slow queries, and vector features for AI applications. Used with private networking, least-privilege access, tested backups, rehearsed failover and watchful monitoring, it becomes a calm, dependable foundation for demanding applications, provided the workload justifies its cost.