AlloyDB Omni is a downloadable database software package that lets you deploy a streamlined edition of AlloyDB for PostgreSQL in your own computing environment. The portability of AlloyDB Omni lets it run in a wide variety of environments, including the following:
- Data centers
- Laptops
- Cloud-based VM instances
AlloyDB Omni is well-suited to the following scenarios:
- You need a scalable and performant version of PostgreSQL, but you can't run a database in the cloud due to regulatory or data-sovereignty requirements.
- You need a database that keeps running even when it is disconnected from the internet.
- You want to physically locate your database as close as possible your users, in order to minimize latency.
- You would like a way to migrate away from a legacy database, but without committing to a full cloud migration.
AlloyDB Omni does not include AlloyDB features that rely on operation within Google Cloud. If you want to upgrade your project to the fully managed scaling, security, and availability features of AlloyDB, you can migrate your AlloyDB Omni data into an AlloyDB cluster just as you can with any other initial data import.
Key features
- A PostgreSQL-compatible database server.
- Support for AlloyDB AI, an integrated set of capabilities built into AlloyDB, to help you build enterprise-grade generative AI applications using your operational data.
- Integrations with the Google Cloud AI ecosystem including the Vertex AI Model Garden and open source generative AI tools.
- An index advisor that analyzes frequently run queries and recommends new indexes for better query performance.
- The AlloyDB columnar engine, which keeps frequently queried data in an in-memory columnar format for faster performance on business intelligence, reporting, and hybrid transactional and analytical processing (HTAP) workloads.
- Other optimizations and enhancements over a stock PostgreSQL server, like automatic memory management and adaptive autovacuum of stale data.
How AlloyDB Omni works
AlloyDB Omni can be installed either as a standalone server or as part of a Kubernetes environment.
AlloyDB Omni runs in a Docker container that you install onto your own environment. We recommend running AlloyDB Omni on a Linux system with SSD storage and at least 8GB of memory per CPU.
The AlloyDB Omni Kubernetes operator is an extension to the Kubernetes API that lets you run AlloyDB Omni in most CNCF-compliant Kubernetes environments. For more information, see Install AlloyDB Omni on Kubernetes.
Your applications connect to and communicate with your AlloyDB Omni installation exactly as they would with an ordinary PostgreSQL database server. User access control relies on PostgreSQL standards, as well.
You can configure the behavior of AlloyDB Omni using the same database flags that are available to AlloyDB.
Database engine architecture of AlloyDB Omni on a VM
This document describes the database architecture in AlloyDB Omni in a container. This document assumes that you're familiar with PostgreSQL.
A database engine performs the following tasks:
- Translates a query from a client into an executable plan
- Finds the data necessary to satisfy the query
- Performs any necessary filtering, ordering, and aggregation
- Returns the results to the client
When the client application sends a query to AlloyDB Omni, the following actions occurs:
- The query processing layer turns the query into an execution plan that goes to the query execution layer.
- The query execution layer performs the operations needed to compute the response to the query.
- During execution, data could be loaded from the buffer cache or loaded directly from storage. If the data is loaded from storage, the data from storage is stored in the cache for future uses.
Resources used when processing the client's query include CPU, memory, I/O, network, and synchronization primitives like database locks. Performance tuning aims to optimize resource utilization during each of the steps in query execution.
The goal of a performant database engine is to respond to a query using the fewest resources required. This goal starts with a good data model and query design.
- How can queries be answered while looking at the least amount of data?
- What indexes are needed to reduce the search space and I/O?
- Sorting data requires CPU and, often, disk access for large data sets, so how can sorting data be avoided?
Data storage
AlloyDB Omni stores data in fixed size pages that are stored in the underlying file system. When a query needs to access data, AlloyDB Omni first checks the buffer pool. If the page(s) that hold the required data are not found in the buffer pool, then AlloyDB Omni reads the required page(s) from the file system. Accessing data from the buffer pool is significantly faster than reading from the file system, and therefore maximizing the size of the buffer pool for the amount of data that will be accessed by an application is an important factor.
Resource management
AlloyDB Omni uses dynamic memory management to let the buffer pool grow and shrink dynamically within configured bounds depending on the memory demands of the system. Therefore, there is no need to tune the buffer pool size. When diagnosing performance issues, the first metrics to consider are the buffer pool hit rate and the read rate to see if your application is getting the benefit of the buffer pool. If not, that indicates that the application's dataset does not fit in the buffer pool, and you could consider resizing to a larger machine with more memory.
The process of retrieving, filtering, aggregating, sorting, and projecting data all require CPU resources on the database server. To reduce the amount of CPU resources required for this process, minimize the amount of data that needs to be manipulated. Monitor the CPU utilization on the database server to ensure the steady state utilization is around 70%. This amount leaves sufficient headroom on the server for spikes in utilization or changes in access patterns over time. Running at closer to 100% utilization introduces overhead due to process scheduling and context switching and might create bottlenecks in other parts of the system. High CPU utilization is another key metric to use when making decisions about machine specifications.
Input/Output Operations Per Second (IOPS) is an important factor in database application performance -- how many input or output operations per second can the underlying storage device deliver to the database. To avoid hitting the IOPS limits of database storage, minimize reads and writes to storage by maximizing the amount of data that can fit in the buffer pool.
Data backup and disaster recovery
AlloyDB Omni features a continuous backup and recovery system that lets you create a new database cluster based on any point in time within an adjustable retention period. This lets you recover quickly from data-loss accidents.
In addition, AlloyDB Omni can create and store complete backups of your database cluster's data, either on demand or on a regular schedule. At any time, you can restore from a backup to an AlloyDB Omni database cluster that contains all the data from the original database cluster at the moment of the backup's creation.
For more information, see Back up and restore AlloyDB Omni.
As a further method of disaster recovery, you can achieve cross data center replication by creating secondary database clusters in separate data centers. AlloyDB Omni asynchronously streams data from a designated primary database cluster to each of its secondary clusters. Whenever needed, you can promote a secondary database cluster into a primary AlloyDB Omni database cluster.
For more information, see About cross-data-center replication
Documentation for AlloyDB Omni version 15.5.2 and earlier
For information about the previous version of AlloyDB Omni, refer to the Multi-container AlloyDB Omni documentation set.