[ Web Proxy ]
URL:
Viewing: https://cloud.google.com/alloydb/omni/docs/overview [Back]  [Original]
AlloyDB Omni overview  |  Google Cloud Documentation Skip to main content
Google Cloud Documentation [Google Cloud Documentation]
Technology areas Cross-product tools
Search:
Console
[]
Start free
Overview Guides Resources
Google Cloud Documentation [Google Cloud Documentation]
Send feedback

AlloyDB Omni overview Stay organized with collections Save and categorize content based on your preferences.

AlloyDB Omni is a downloadable database software package that lets you deploy a streamlined version of AlloyDB for PostgreSQL in computing environments that you manage. AlloyDB Omni and the fully managed AlloyDB service on Google Cloud share the same core components. AlloyDB uses a cloud-native disaggregated storage layer, while AlloyDB Omni is deployed on the storage of your choice.

AlloyDB Omni's portability lets you run it in many environments, including the following:

AlloyDB Omni offers several enhancements—in addition to standard PostgreSQL—that support scalability, availability, reliability, performance, AI, and natural language. For more information, see AlloyDB Omni additions to standard PostgreSQL.

AlloyDB Omni use cases

AlloyDB Omni is well-suited to the following scenarios:

Note: AlloyDB Omni is a downloadable version of AlloyDB for PostgreSQL, and is self-managed. To upgrade to the fully managed database version, you can choose to migrate your AlloyDB Omni database to AlloyDB for PostgreSQL using any PostgreSQL-supported migration methods, including third-party tools such as Striim.

Key features

In performance tests, transactional workloads in AlloyDB Omni are more than 2X faster, and analytical queries are up to 100X faster, than standard PostgreSQL.

AlloyDB Omni deployment choices

You can install AlloyDB Omni using one of the following deployment options:

Deployment options for AlloyDB Omni [Deployment options for AlloyDB Omni]

Your applications connect to and communicate with your AlloyDB Omni database, as applications connect to and communicate with a standard PostgreSQL database server. User access control also relies on PostgreSQL standards.

You can configure the AlloyDB Omni database behavior using database flags, including logging, vacuuming, and the columnar engine. For more information, see Available AlloyDB Omni download and installation options.

AlloyDB Omni as a container

Google distributes AlloyDB Omni as a container that you can run with container runtimes such as Docker and Podman. You can also deploy AlloyDB Omni containers in a Kubernetes environment with many basic operations automated.

Operationally, containers offer the following advantages:

AlloyDB Omni in a RHEL environment

AlloyDB Omni provides two deployment options for a RHEL environment, which depend on your automation and scaling requirements.

AlloyDB Omni using RPM

The RPM deployment option is a standalone Red Hat Package Manager (RPM) installation designed for environments when you want a non-containerized AlloyDB Omni database. This option supports RHEL 9 and Rocky Linux 9.

The RPM orchestrator

The RPM orchestrator deployment option (Preview) uses the same RPM packages as AlloyDB Omni using RPM, but adds an orchestration platform to automate management in non-Kubernetes environments.

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 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 time the backup was created.

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.

AlloyDB Omni components

AlloyDB Omni consists of two sets of architecture components: PostgreSQL components with AlloyDB Omni enhancements and AlloyDB Omni-specific components.

The following diagram shows both sets of components, including the infrastructure layer that the components reside in, and features for each component.

Architecture of AlloyDB Omni, showing AlloyDB for PostgreSQL-specific and PostgreSQL components. [Architecture of AlloyDB Omni, showing AlloyDB for PostgreSQL-specific and PostgreSQL components.]

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 pages that hold the required data aren't found in the buffer pool, then AlloyDB Omni reads the required pages from the file system.

Accessing data from the buffer pool is significantly faster than reading from the file system. Maximizing the buffer pool size for the data an application accesses is an important factor. You can optionally add an ultra-fast cache layer to further enhance query performance.

Resource management

AlloyDB Omni uses automatic 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 you diagnose performance issues, first consider metrics like the buffer pool hit rate and the read rate to determine if your application is benefiting from the buffer pool. If not, that indicates that the application's dataset doesn't fit in the buffer pool, and you might 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 to manipulate. 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, measuring how many input or output operations per second the underlying storage device can deliver to the database. To avoid exceeding the IOPS limits of database storage, minimize reads and writes to storage. Maximize the amount of data that fits in the buffer pool or in the cache layer.

Columnar engine

The built-in columnar engine accelerates analytical query processing that typically involves full table scans, complex joins, and aggregates.

For more information, see About the AlloyDB for PostgreSQL columnar engine.

Automatic memory management

The automatic memory manager continuously monitors and optimizes memory consumption across an entire AlloyDB Omni instance. When you run your workloads, this module adjusts the shared buffer cache size based on memory pressure.

By default, the automatic memory manager sets the upper limit to 80% of system memory and allocates 10% of system memory for the shared buffer cache. To change the upper limit for the size of the shared buffer cache, set the shared_buffers parameter in the postgresql.conf used by your AlloyDB Omni instance.

Adaptive autovacuum

Adaptive autovacuum analyzes operations based on the database workload and automatically adjusts the frequency of vacuuming. This automatic adjustment helps the database maintain optimal performance, even as the workload changes, without interference from the vacuum process.

Adaptive autovacuum uses the following factors to determine the frequency and intensity of vacuuming operations:

AI/ML worker

In AlloyDB Omni, the AI/ML background worker provides the capabilities necessary for calling Vertex AI models directly from the database. The AI/ML worker runs as a process called omni ml worker.

Orchestrator control plane

The RPM orchestrator deployment option uses a centralized cluster manager to automate cluster-wide operations, including bootstrapping and failover.

Management interfaces

The RPM orchestrator deployment option provides both a command-line utility (alloydbctl) and Ansible roles for managing one or more clusters at scale.

Performance optimization

The RPM orchestrator deployment option includes integrated support for PgBouncer for connection pooling and HAProxy for load balancing across read-write and read-only endpoints.

What's next

Send feedback

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2026-08-11 UTC.

Need to tell us more? [[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2026-08-11 UTC."],[],[]]
Web Proxy Viewer  |  New URL  |  Original Page