AlloyDB is a fully managed database from Google Cloud that speaks the PostgreSQL language.

The simple definition

A database is an organized place where an application keeps its information, such as customers, orders, payments, and messages. AlloyDB for PostgreSQL is a database service from Google Cloud that is compatible with PostgreSQL, one of the most popular open-source databases in the world. “Compatible” means that the tools, drivers, and SQL commands you already use with PostgreSQL work with AlloyDB too. “Fully managed” means Google runs the servers, applies updates, takes backups, and handles failures for you, so your team can focus on the application.

Why does it exist?

Many companies love PostgreSQL but find that as their business grows, a single database server becomes a bottleneck. Reads get slow, reports interfere with customer traffic, and maintenance windows cause downtime. Companies running older commercial databases also want to move to something open, but without losing performance or enterprise features. AlloyDB was created to give these teams a PostgreSQL-compatible database with strong performance, high availability, and built-in support for analytics and artificial intelligence, without making them rewrite their applications.

Where is it used?

Teams use AlloyDB for online shops, banking and payment systems, gaming back-ends, software-as-a-service products, and applications that mix day-to-day transactions with reports and smart search. It is especially attractive when a workload is large, busy, or needs both fast transactions and fast analytics from the same data.

A few basic ideas make the rest of this tutorial much easier.

Relational databases

A relational database stores information in tables, much like spreadsheets. Each table has columns, which describe the kind of data, and rows, which hold one record each. A customers table might have columns for name and email, and one row for each customer. Tables can be linked together, for example an orders table that points to the customer who placed each order. You ask questions using a language called SQL, short for Structured Query Language.

Transactions

A transaction is a group of changes that must succeed or fail together. If you transfer money between two bank accounts, the withdrawal from one and the deposit into the other must both happen, or neither should. Databases that guarantee this are called ACID databases, a word that stands for atomicity, consistency, isolation, and durability. PostgreSQL is a classic ACID database, and AlloyDB keeps those guarantees.

Why PostgreSQL is so popular

What “managed” really means

If you install PostgreSQL yourself on a server, you must buy or rent the machine, install the software, apply security fixes, set up backups, plan for failures, and watch the disks. A managed service takes over most of these chores. You still design your tables, write queries, and control who has access, but Google operates the machinery. It is like the difference between owning a car and using a taxi service: you still choose the destination, but you do not change the oil.

A handful of terms describe every AlloyDB setup.

Google organizes AlloyDB in a simple hierarchy. At the top is a cluster, inside it are instances, and each instance runs on one or more nodes. Learn these words now and every diagram will make sense.

flowchart TD
  C["Cluster in one region"] --> P["Primary instance: reads and writes"]
  C --> R["Read pool instance: reads only"]
  C --> S["Shared storage layer"]
  P --> N1["Node 1"]
  P --> N2["Node 2 standby"]
  R --> N3["Read node A"]
  R --> N4["Read node B"]
  P --> S
  R --> S
        

Notice that both the primary and the read pool connect to the same storage. This is the key difference from many traditional setups, where each database server keeps its own full copy of the data on its own disks.

Separating the thinkers from the storage is the central design idea of AlloyDB.

The traditional way

In a classic PostgreSQL setup, one server does everything. It runs the database software, and it also owns the disks where the data lives. If you add a replica to share the reading work, that replica needs its own complete copy of the data, which must be sent over from the original constantly. More replicas mean more copying, more disks, and more cost. Growing storage often means moving to a bigger server or planning downtime.

The AlloyDB way

AlloyDB splits the system into two layers. The compute layer is made of virtual machines, called nodes, that run the PostgreSQL engine and answer your queries. The storage layer is a distributed system that spans multiple zones and grows automatically with your data. The two layers talk over Google’s fast internal network. Each can be sized on its own: you can give the compute layer more processors without touching storage, and storage grows by itself as you add data.

flowchart LR
  APP["Your application"] --> CL["Compute layer: nodes running PostgreSQL"]
  CL  ST["Distributed storage layer across zones"]
  ST --> BK["Backups and continuous log archive"]
        

What you gain from this split

Following one request from your application shows how the pieces cooperate.

The idea of a write-ahead log

Every serious database keeps a running diary of changes, called a log. Before a change is considered final, the database writes a note in the log saying what changed. If the server crashes, the log lets it replay the notes and recover. In ordinary PostgreSQL the server must also spend a lot of effort writing full data pages to disk and tidying them up in the background.

In AlloyDB, the compute node mainly sends those log records to the storage layer, and the storage layer does much of the heavy lifting of turning them into data pages and keeping them organized. Because the node is relieved of some of this housekeeping, it has more energy left for answering your queries. Google describes this as an intelligent, log-based storage design.

The life of a write

sequenceDiagram
  participant App as Application
  participant P as Primary node
  participant S as Storage layer
  participant R as Read pool
  App->>P: Insert a new order
  P->>S: Send log record for the change
  S-->>P: Confirm change is safely stored
  P-->>App: Transaction committed
  S->>S: Build and organize data pages
  S-->>R: Updates become visible to readers
        

The life of a read

For a read, a node first checks its own fast memory cache. If the data is there, it answers at once. If not, it fetches the needed pages from the storage layer. AlloyDB also uses an additional cache layer to keep frequently used data close by. The result is that busy, repeated queries tend to be served quickly from memory rather than from slow storage.

Failures are normal in large systems, so AlloyDB is designed to expect them.

Highly available primary instances

A primary instance comes in two flavors. A highly available primary uses two nodes placed in different zones of the same region. One node is active and serves traffic while the other stands by. If the active node or its zone fails, AlloyDB switches over automatically to the standby, and your application reconnects to the same address. A basic primary has just one node, and Google positions it for non-production use such as development and testing.

flowchart TD
  subgraph Region
    subgraph ZA["Zone A"]
      A["Active primary node"]
    end
    subgraph ZB["Zone B"]
      B["Standby primary node"]
    end
    ST["Distributed storage across zones"]
  end
  A --> ST
  B --> ST
  A -. "automatic failover" .-> B
        

Read pools and availability

Read pool instances also add resilience. A read pool with at least two nodes spreads them across zones, so reading continues even if one node or zone has trouble. AlloyDB spreads incoming read requests across the nodes in the pool.

Maintenance with little interruption

Databases need updates for security and improvements. Google applies maintenance to AlloyDB in a way that keeps interruptions small. Google’s documentation says primary instances typically see less than one second of downtime during maintenance, and read pools remain available during the process. You can influence when maintenance happens by choosing a preferred maintenance window, so updates avoid your busiest hours.

There are two ways to handle growth, and AlloyDB supports both.

Scaling up

Scaling up means giving a node more processors and more memory. You change the machine size of an instance, and AlloyDB moves you to the larger size. Nodes can be very large; Google’s pricing page lists limits of up to 288 vCPUs and 2,232 GiB of memory per node, though available sizes can change. Scaling up helps when a single query or a single busy primary needs more power.

Scaling out

Scaling out means adding more nodes to share the work. Read pool instances do this for reads: a read pool can have up to 20 nodes, and AlloyDB load-balances read requests across them. Because all nodes share the same storage, adding a read node is much faster and cheaper than building a full new replica with its own copy of the data.

Sending reads to the right place

Applications must choose where to send queries. A common pattern is to send all writes, and any reads that must see the latest data, to the primary instance, and to send everything else, such as dashboards and search pages, to the read pool. Many database drivers and frameworks support separate connection settings for reads and writes to make this easy.

AlloyDB can answer big reporting questions without a separate analytics system.

Rows versus columns

Ordinary databases store data row by row, which is perfect for transactions, because an order’s details sit together. But a question such as “what was the total sales amount last year?” needs only one column, the amount, from millions of rows. Reading every full row just to use one field is wasteful. A columnar format stores each column together, so such questions read far less data and run much faster.

What the columnar engine does

AlloyDB includes a columnar engine that keeps selected data in memory in a columnar form, to speed up analytical queries. It works alongside the normal row-based storage. You do not move your data to a different product; the same database serves both your everyday transactions and your reports. This approach is often called hybrid transactional and analytical processing, or HTAP.

AlloyDB can store the “meaning” of text and images, and find things by similarity.

What is an embedding?

An embedding is a list of numbers that captures the meaning of a piece of content, such as a sentence, a product description, or an image. Items with similar meanings get lists of numbers that are close to each other. A special kind of database field, called a vector, stores these lists. If someone searches for “cozy winter jacket,” an embedding-based search can find “warm padded coat” even though the words differ, because the meanings are close.

The AI features in AlloyDB

Why keep vectors in the same database?

Many teams build smart search or assistants that retrieve helpful documents before an AI model answers, a pattern often called retrieval-augmented generation. Keeping the vectors next to the original rows means one system to secure, back up, and operate, and a single query can combine meaning-based search with ordinary filters such as price, date, or customer. There is also no need to keep two copies of the data in sync.

Good backups are the insurance policy every database needs.

Kinds of backups

AlloyDB supports on-demand backups, which you take whenever you like, and scheduled backups, which run automatically on a timetable. It also supports continuous backup and recovery, which keeps a stream of change records so you can restore the database to any chosen moment within your retention period. This is called point-in-time recovery, and it is very helpful when someone runs a harmful command by mistake, because you can return to the minute just before it happened.

Restoring

Restores from backups create a new cluster rather than overwriting the existing one. This is safer, because you can inspect the restored copy, compare it with the current data, and switch your application over only when you are satisfied.

Protecting against a whole region failing

A region is a geographic area containing several zones. A high-availability cluster survives the loss of a zone, but what if an entire region has a problem? AlloyDB lets you create a secondary cluster in another region that copies changes from the primary cluster asynchronously. If disaster strikes, you can promote the secondary cluster to become an independent, writable cluster. Google’s documentation notes that cross-region failover features have been in Preview, so check the current status before depending on them for critical plans.

flowchart LR
  subgraph R1["Region 1"]
    PC["Primary cluster"]
  end
  subgraph R2["Region 2"]
    SC["Secondary cluster, read-only copy"]
  end
  PC -->|"asynchronous replication"| SC
  SC -. "promote during disaster" .-> NW["Independent writable cluster"]
        

A database should be reachable by your application and by almost nobody else.

Private by design

AlloyDB instances are normally reached over private network addresses inside your Google Cloud network, rather than over the open internet. This keeps the database away from random scanners. Applications running on Compute Engine, Google Kubernetes Engine, Cloud Run, and other services connect through private paths, and your offices or other clouds can reach it over private links such as VPN or interconnect.

Ways to connect

Connection pooling

Opening a database connection takes work, and each connection uses memory. Applications that open thousands of short connections can overwhelm a database. A connection pooler keeps a smaller set of long-lived connections and hands them out as needed. Using one is a standard way to keep busy applications healthy, and it pairs well with retry logic around failovers.

Google secures the platform; you secure the people and the data.

The shared responsibility idea

Google protects the data centers, the hardware, and the managed service. You are responsible for who can access the database, what data you store, how applications connect, and how well you follow the rules that apply to your business. Many problems in the cloud come from the customer’s side of this line.

Layers of protection

Moving house is easier when the furniture is the same shape.

Why migration is relatively gentle

Because AlloyDB is PostgreSQL-compatible, an application already using PostgreSQL usually needs few code changes. Drivers, object-relational mappers, and SQL queries typically continue to work. Teams moving from other databases face more work, because SQL dialects and special features differ, but PostgreSQL is a popular target for such moves.

Where migrations come from

A safe migration plan

You cannot fix what you cannot see, so watch your database like a dashboard on a car.

Metrics

AlloyDB sends health numbers to Cloud Monitoring, such as processor use, memory use, number of connections, and storage consumption. Plotting these over time shows trends, like a slow rise in connections that eventually hits a limit, and lets you set alerts before users notice problems.

Logs

Database logs and audit logs flow into Cloud Logging, where you can search them in one place. Slow-query information and error messages help you find the cause when something goes wrong. Audit logs show who changed configuration, which is helpful for security reviews.

Query-level insight

Google provides tools such as Query Insights that show which queries use the most time and resources, so you can improve the worst offenders first. Fixing a few slow queries often helps more than buying larger machines.

Cloud databases reward careful sizing and punish forgotten resources.

What you pay for

AlloyDB uses pay-as-you-go pricing, and Google states there are no proprietary licensing fees and no separate charges for I/O. The main parts of the bill are compute, which is the vCPUs of your nodes, memory, which is billed per gigabyte-hour, database storage, which is billed on the data you actually use, backup storage, and network traffic. A high-availability primary uses two nodes, so it costs more than a basic single-node primary. Compute, memory, storage, and backup charges are billed by the hour. Prices vary by region, so always check the official pricing page and calculator for current numbers.

Details worth knowing

Ways to keep the bill sensible

The same engine can also run outside Google’s managed service.

AlloyDB Omni is a downloadable edition of AlloyDB that you run on your own Linux environment. That could be a laptop, a server in your office, a data center, or a virtual machine in another cloud. It uses the same underlying database engine and gives you many of the same performance and AI features, but you manage the infrastructure yourself, including updates, backups, and availability.

Good habits are copied from teams that already learned the hard way.

Patterns that work

Anti-patterns to avoid

Every technology choice gives something and costs something.

Best practices checklist

Several good database options exist on Google Cloud, and the best one depends on the job.

flowchart TD
  S["Need a database"] --> Q1{"Need PostgreSQL compatibility?"}
  Q1 -->|No| OTH["Consider Spanner, Firestore, or other fit"]
  Q1 -->|Yes| Q2{"Heavy load, read scaling, analytics, or vector search?"}
  Q2 -->|No| CS["Cloud SQL for PostgreSQL"]
  Q2 -->|Yes| Q3{"Need global write scaling across regions?"}
  Q3 -->|Yes| SP["Look at Spanner"]
  Q3 -->|No| AL["AlloyDB for PostgreSQL"]
        

If you know another cloud

People who have used other clouds can map ideas across. The names differ, but the concepts are close cousins.

Here is how different kinds of teams typically put AlloyDB to work.

Questions beginners ask most often, answered in plain words.

No. AlloyDB is a Google Cloud service that is compatible with PostgreSQL. It uses PostgreSQL’s language and tools, but its internal storage and scaling design were built by Google for higher performance and availability.

If you already use PostgreSQL, usually very little. You update the connection details and test for any unsupported extensions or settings. Applications coming from other database types need more conversion work.

The primary instance accepts both reads and writes, and every cluster has exactly one. A read pool serves read-only requests across several nodes, and it helps spread out reading work.

No. Storage is a managed, distributed layer that grows automatically with your data, and you are billed for what you use.

With a highly available primary, a standby node in another zone takes over automatically. Reads continue from other nodes in a read pool that has at least two nodes.

Google’s documentation lists up to 20 nodes in a single read pool instance, and AlloyDB spreads read requests across them. Limits can change, so check the current quotas page.

Yes. Continuous backup and point-in-time recovery let you restore to a chosen moment within your retention period. Restores create a new cluster, so you can check the data before switching over.

Yes. It supports a vector extension for storing embeddings, a Google-developed ScaNN index for fast similarity search, and integration with machine learning models.

For small or simple workloads it often is, because it targets demanding use cases. For large, busy, or analytics-heavy workloads, its design can offer better value. Compare using your real workload and Google’s pricing calculator.

The managed service runs on Google Cloud. AlloyDB Omni is a downloadable edition you can run on your own Linux environment, though you manage it yourself.

Use private network connectivity, such as private services access or Private Service Connect, connect through the Auth Proxy or language connectors, and allow only trusted networks and identities.

Google has offered a 30-day free trial cluster and general new-customer credits. Use basic instances for experiments, and delete test clusters when you finish so they do not keep billing.

AlloyDB for PostgreSQL gives teams the familiar PostgreSQL language on top of a Google-designed platform. Compute nodes and a shared, automatically growing storage layer are separated, so each can scale on its own. A cluster holds one primary instance, which can be highly available across two zones, and optional read pools of up to twenty nodes. Extra features cover fast analytics through the columnar engine, AI search through vectors and model integration, strong backups with point-in-time recovery, and cross-region copies for disaster protection. With private networking, IAM-based sign-in, encryption, and careful monitoring, a beginner can build a dependable, secure database. With right-sizing, read pools, and committed use discounts, it can also be an affordable one.