Google launches AlloyDB Omni RPM orchestrator for servers

Google has made the AlloyDB Omni Red Hat RPM orchestrator generally available with AlloyDB Omni version 18.3.0.

The software is designed to manage PostgreSQL workloads on virtual machines and bare-metal servers, expanding Google's database offering for customers that want to run systems outside a managed cloud service. It gives AlloyDB Omni a deployment option for organisations that use non-containerised infrastructure and want operational tooling for self-managed database estates.

AlloyDB Omni now supports four deployment modes: a standalone container, a container with a Kubernetes operator for highly available deployments, a standalone RPM package, and the RPM orchestrator for highly available deployments. That expands how customers can run the PostgreSQL-compatible database based on their infrastructure choices and operating model.

Google positions the RPM deployment for use cases including modernisation projects, regulated environments, edge and on-premises systems, and workloads tied to AI applications. Some organisations still choose to run databases themselves because of data residency requirements, local control, latency needs, or disconnected operations.

Architecture options

The orchestrator includes reference architectures that can be adjusted by changing instance settings, node layouts, and networking options. These designs are intended to support different requirements, including performance, read scaling, and high availability.

One reference setup uses a load-balancing tier to direct read-write traffic to an active primary node and read-only traffic to replica nodes. In that design, the load balancer uses a virtual IP and includes Keepalived for failover, PgBouncer for connection pooling, and HAProxy for traffic routing.

The database layer can replicate data synchronously across multiple zones for high availability, while separate read pool instances can receive asynchronous replication from the active node for read-heavy workloads. Those read pools can be scaled independently so analytical queries do not affect the main high-availability cluster.

An independent control plane manages cluster health and configuration. It includes redundant cluster managers and a three-node etcd-based distributed configuration store, while node managers run on individual database servers.

Operations focus

A central part of the release is automation for provisioning and lifecycle management. Administrators can define reference architecture specifications and use the orchestrator to deploy and manage clusters against those settings.

The software supports low-downtime maintenance for minor version upgrades and for adjustments to CPU and memory resources. It also includes rollback support if an automated maintenance task does not complete as intended.

Google has also added support for dynamic configuration changes, including the ability to modify database settings during or after bootstrap. Native tools to add or remove database nodes are intended to simplify cluster resizing as workload demand shifts.

Read scaling is another feature in the generally available release. The orchestrator now supports read pools, which can be created when a cluster is first built or added later to handle analytical or other read-intensive workloads.

The system also creates dedicated read endpoints for standby nodes and read pools. The architecture is designed to handle failures across both data and control path components, as well as network disruption between nodes.

Security and recovery

The release also adds backup and restore functions. Administrators can set backup schedules and send backups automatically to Google Cloud Storage, S3-compatible storage, or local destinations.

It includes point-in-time recovery and in-place point-in-time restore. For security-sensitive environments, the orchestrator supports SELinux enforcement at or after bootstrap, intended to help organisations meet compliance and access control requirements.

Logging is also built into the product's operational model. Both data-path and control-path logs can be directed to disk to support auditing and debugging.

AI and observability

Alongside database management features, Google has tied the orchestrator to AlloyDB Omni's AI-related functions. These include vector search, natural-language querying, AI-powered search functions, and other AI operators available within AlloyDB Omni.

Users can also provision clusters for AI integrations on-premises. That may appeal to organisations that want to keep AI-related data processing local while using PostgreSQL-compatible systems.

For observability, the orchestrator supports custom metrics so customers can track business or application events from the database layer and export them to an internal monitoring platform. Google gave examples including new user registrations, tenant session counts, and order volumes.

The launch reflects a continuing effort by major cloud providers to address customers who want cloud-style database tooling without moving every workload into a managed service. In this case, Google targets enterprises that still run significant database estates on virtual machines and dedicated hardware but want more automation for resilience, maintenance, backups, and scaling.

The RPM orchestrator also supports AlloyDB Omni extensions already available on the platform, along with local audit logging and operational controls for regulated or tightly managed environments.