AlloyDB Omni overview

AlloyDB Omni is a downloadable database software package that lets you deploy a streamlined version of AlloyDB for PostgreSQL in computing environments 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:

  • Your private data centers
  • Any public cloud
  • Your laptop
  • Cloud-based VM instances

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:

  • You need a scalable, high-performance version of PostgreSQL that you must run on-premises due to regulatory or data sovereignty requirements.
  • You need a database that continues to run even when it's disconnected from the internet.
  • You want to migrate away from a legacy database without committing to a fully managed cloud service like AlloyDB for PostgreSQL.

Key features

  • A 100% PostgreSQL-compatible database server.
  • Support for AlloyDB AI, which helps 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.

  • Support for autopilot features from AlloyDB for PostgreSQL in Google Cloud that lets AlloyDB Omni self-manage and self-tune.

    For example, AlloyDB Omni supports automatic memory management and adaptive autovacuum of stale data.

  • The AlloyDB Omni columnar engine, which keeps relevant data in an in-memory columnar format for faster analytical queries, reporting, and hybrid transactional and analytical processing (HTAP) workloads.

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

How AlloyDB Omni works

You can install AlloyDB Omni in one of the following ways:

  • AlloyDB Omni for containers: a standalone database container. Run AlloyDB Omni on a Linux system with SSD storage and at least 8GB of memory per CPU.

  • AlloyDB Omni for Kubernetes: part of a container in a Kubernetes environment. The AlloyDB Omni Kubernetes operator is an extension to the Kubernetes API that lets you run AlloyDB Omni in most CNCF-compliant Kubernetes environments.

    The AlloyDB Omni operator simplifies basic database operations, which lets you automate single or high availability (HA) deployments and day-2 operations like backup, restore, failover, and setting up cross-region disaster recovery (DR).

  • AlloyDB Omni for Linux (Preview): a Red Hat Package Manager (RPM) that runs directly in a VM or bare metal. AlloyDB Omni for Linux runs as a set of integrated software components directly on the host operating system. It uses the standard Linux file system for storage, letting you use your existing storage infrastructure and management practices.

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 relies on PostgreSQL standards, also.

From logging to vacuuming to the columnar engine, you can configure the AlloyDB Omni database behavior using database flags.

Advantages of running 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:

  • Transparent dependency management: all necessary dependencies are bundled in the container and tested by Google to ensure that they are fully compatible with AlloyDB Omni.
  • Portability: you can expect AlloyDB Omni to operate consistently across environments.
  • Security isolation: you choose what the AlloyDB Omni container has access to on the host machine.
  • Resource management: you can define the amount of compute resources that you want the AlloyDB Omni container to use.
  • Seamless patching and upgrades: to patch a container, replace the existing image with a new one.

Advantages of running AlloyDB Omni in a RHEL environment

AlloyDB Omni for Linux (Preview) is designed for environments where a non-containerized database deployment is preferred. This deployment model supports bare metal servers and virtual machines.

You can install AlloyDB Omni for Linux directly onto a Red Hat Enterprise Linux (RHEL) or Red Hat-compatible environment using standard operating system package managers.

AlloyDB Omni for Linux supports RHEL 9 and Rocky Linux 9.

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 enhancements and AlloyDB-specific components.

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

AlloyDB Omni component architecture showing AlloyDB for PostgreSQL-specific components and PostgreSQL components.

Figure 1. AlloyDB Omni architecture

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 and then 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 by maximizing 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.

  • In-memory column store: contains table and materialized-view data for selected columns in a column-oriented format. By default, the column store consumes 30% of available memory. To change the amount of memory usable by the column store, set the google_columnar_engine.memory_size_in_mb parameter in the postgresql.conf used by your AlloyDB Omni instance.

  • Columnar query planner and execution engine: supports the use of the column store in queries.

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 workload of the database, 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:

  • Size of the database
  • Number of dead tuples in the database
  • Age of the data in the database
  • Number of transactions per second versus estimated vacuum speed
  • Resource utilization

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.

What's next