AlloyDB for PostgreSQL is a fully managed, PostgreSQL-compatible database service that's designed for your most demanding workloads, including hybrid transactional and analytical processing. AlloyDB pairs a Google-built database engine with a cloud-based, multi-node architecture to deliver enterprise-grade performance, reliability, and availability.
How AlloyDB works
An application connects to AlloyDB instances using standard PostgreSQL protocols and techniques. The application then uses PostgreSQL query syntax to work with the database.
Under the surface, AlloyDB utilizes a cloud-based hierarchy of components and features that are designed to maximize the availability of your data and optimize query performance and throughput. Google Cloud administrative tools let you monitor the health of your AlloyDB deployment, adjusting its scale and size to best fit the changing demands of your workload.
Clusters
A single AlloyDB deployment within a given Google Cloud region organizes all of its resources into one cluster. This includes all of your databases, logs, and other metadata. AlloyDB deploys all the resources of one cluster within a single Virtual Private Cloud (VPC) and makes use of a cloud-based file system designed by Google and optimized for AlloyDB.
Nodes and instances
A cluster contains several nodes, which are virtual machine instances that are dedicated to running the PostgreSQL-compatible database engine that applications use to query your cluster's data. AlloyDB organizes nodes into instances, each of which has a private, static IP address in your VPC. In practice, your applications connect to instances at these IP addresses using PostgreSQL protocols. The instances then pass SQL queries to their nodes.
AlloyDB has two kinds of instances:
Primary instance: Every cluster has one primary instance, providing a read or write access point to your data. A primary instance can be either highly available (HA) or basic.
HA primary instance: An HA primary instance has two nodes: an active node and a standby node. AlloyDB monitors the availability of the active node, and it automatically promotes the standby node into the active node when necessary.
Basic instance: Non-production environments not requiring high availability can optionally use basic instances. A basic instance has only one node, with no standby node. For more information, see Reduce costs using basic instances.
Read pool instance: Your cluster can optionally have one or more read pool instances, each containing one or more read-only nodes, up to a cluster-wide maximum of 20. AlloyDB automatically load-balances all requests sent to a read pool instance, routing them to the instance's nodes.
For simpler use cases, a cluster can have only the primary instance, with no read pools, and applications use the primary instance for all queries. For more demanding work, you can add read pool instances to the cluster. Then you configure your reporting or analytical applications to send read requests to them. This technique reduces the load on your primary instance, and improves scalability by spreading the load across multiple nodes.
You can add, remove, or adjust the node count of a read pool instance at any time, as your application's needs change. You can also resize the memory and vCPU count of an instance's constituent nodes whenever needed, with minimal downtime. Scaling your instances poses no risk of data loss, because AlloyDB stores your data in the cluster's flexible storage layer, and not in the instances.
This diagram illustrates an example cluster scaled to handle demanding workloads, with the inclusion of multiple load-balancing read-only instances:
Key features
AlloyDB distinguishes itself from a stock PostgreSQL installation in a number of ways beyond the vertical and horizontal scaling advantages inherent in the multi-node architecture described earlier. The following sections take a deeper look at key features of AlloyDB.
Automatic and adaptive database features
The fully PostgreSQL-compatible database engine that powers every AlloyDB node has several features that continuously analyze the structure and frequency of the queries that your instances handle, using this information to suggest schema improvements or automatically apply optimizations:
An index advisor helps you find opportunities to optimize your database schema using new indexes based on your usage patterns.
A columnar engine can accelerate the performance of analytical queries by storing data in memory using a columnar format. This lets AlloyDB use advanced processing techniques to efficiently scan a large amount of table data when needed.
An adaptive variation of the PostgreSQL stale-data autovacuum feature automatically adjusts vacuum-related parameters to best suit the shape of your workload.
Automatic memory and storage management systems take advantage of the Google-built, cloud-based environment that AlloyDB runs on, continuously allocating and releasing memory and storage as needed to keep your cluster running with optimal performance and resource efficiency.
High availability
By default, an AlloyDB cluster offers availability (HA) through its primary instance's redundant nodes, located in two different zones, with automatic failover.
Clusters operating in non-production environments that do not require HA can optionally use basic, single-zone primary instances instead.
Adding read pool instances containing at least two nodes creates further load-balanced, multi-zonal, high-availability access points to your data. All read pool instances run independently of the primary instance.
Data backup and disaster recovery
AlloyDB features a continuous backup and recovery system that lets you create a new cluster based on any point in time within an adjustable retention period. This lets you recover quickly from data-loss accidents.
In addition, AlloyDB can create and store complete backups of your cluster's data, either on demand or on a regular schedule. At any time, you can restore from a backup to a new AlloyDB cluster that contains all the data from the original cluster at the moment of the backup's creation.
For more information, see About backups.
As a further method of disaster recovery, you can achieve cross-region replication by creating secondary clusters in separate Google Cloud regions. AlloyDB asynchronously streams data from a designated primary cluster to each of its secondary clusters. Whenever needed, you can promote a secondary cluster into a fully featured AlloyDB cluster with primary and read pool instances.
For more information, see About cross-region replication.
Security and access control
You can configure a cluster to require connection with the secure AlloyDB Auth Proxy, which uses Google Cloud Identity Access and Management (IAM) for access control. For more information, see Authorization.
AlloyDB uses the standard PostgreSQL user role system for authentication, introducing a handful of additional roles specific to AlloyDB. For more information, see Manage AlloyDB user roles.
Encryption
AlloyDB protects all data at rest using Google's encryption methods by default. If you instead need to encrypt your data using a key that you provide, then you can specify a customer-managed encryption key (CMEK) when creating a cluster. AlloyDB then uses the CMEK key to encrypt all data written to that cluster.
CMEK also applies to backups. You can specify a CMEK key when creating an on-demand backup, configuring a backup schedule, or restoring from a backup.
For more information, see About CMEK.
Non-disruptive maintenance
AlloyDB maintenance operations are designed to minimize disruptions to your database. Primary and secondary instances have a downtime of less than a second, while read pools remain continuously available with no downtime. This is accomplished by preparing replacement servers, and quickly swapping them with the active servers when ready. During this process, any active connections to the database are momentarily dropped. You can continue using your database normally throughout this process.
While this replacement process ensures minimal downtime, the overall operation may take several minutes, as indicated on the Google Cloud console and the Google Cloud CLI CLI.
These maintenance operations include periodic maintenance tasks run by Google
and tasks that you perform manually, such as flag configuration and instance
resizing. If you want to apply any update immediately even if it means a longer
downtime, then use the
FORCE_APPLY database flag.
Extension support
AlloyDB includes support for a number of popular PostgreSQL extensions. For the full list, see Supported database extensions.
A self-hosted alternative: AlloyDB Omni
As an alternative to running AlloyDB within Google Cloud, Google offers AlloyDB Omni. This streamlined, downloadable edition of AlloyDB lets you run its powerful database engine on your own Linux-based computing environment, wherever that might be.
For more information, see About AlloyDB Omni.