AlloyDB Omni boosts performance with vector search, analytics, and faster transactions.
With its latest release AlloyDB Omni version 15.7.0, AlloyDB Omni is back and is significantly improving your PostgreSQL workflows. These improvements include:
- Quicker performance
- A brand-new, lightning-fast disk cache
- A better columnar engine
- The widespread use of ScANN vector indexing
- The AlloyDB Omni Kubernetes operator has been updated.
In your data center, on the edge, on your laptop, in any cloud, and with 100% PostgreSQL compatibility, this update offers on all fronts, from transactional and analytical workloads to state-of-the-art vector search.
AlloyDB Omni version 15.7.0 is now broadly accessible (GA). The following updates and features are included in version AlloyDB Omni version 15.7.0:
- AlloyDB Version 15.7 of PostgreSQL is supported by Omni.
- Previously known as postgres_scann, the alloydb_scann extension is now generally available (GA).
- There is generally available (GA) support for Red Hat Enterprise Linux (RHEL) 8.
- You can preview the AlloyDB Omni columnar engine on ARM.
- Because disk cache and columnar storage cache speed up data access for AlloyDB Omni in a container and on a Kubernetes cluster, they can enhance AlloyDB Omni performance.
- It has applied security updates for CVE-2023-50387 and CVE-2024-7348.
- The documentation for the AlloyDB Omni Reference is accessible. This comprises AlloyDB Omni 15.7.0 metrics, database flags, model endpoint management reference, and extension documentation.
- AlloyDB The pg_ivm extension, which offers incremental view maintenance for materialized views, is compatible with Omni.
- Numerous efficiency enhancements and bug fixes.
Let’s get started.
Improved performance
When compared to regular PostgreSQL, many workloads already experience an improvement. For transactional workloads, AlloyDB Omni outperforms regular PostgreSQL by more than two times in performance testing. The majority of the tuning is done automatically for you without the need for additional setups. The memory agent that maximizes shared buffers while preventing out-of-memory issues is one of the main benefits. AlloyDB Omni generally runs better with more memory configured because it can serve more queries from the shared buffers and eliminate the need for disk calls, which can be significantly slower than memory, especially when utilizing durable network storage.
An extremely fast disk cache
The introduction of an ultra-fast disk cache also made the trade-off between memory and disk storage more flexible. As an extension of Postgres’ buffer cache, it enables you to set up a quick, local, and perhaps brittle storage device. AlloyDB Omni can store a copy of not-quite-hot data in the disk cache, where it can be accessed more quickly than from the permanent disk, rather than aging out of memory to create room for new data.
Improved columnar engine
The analytics accelerator from AlloyDB Omni is revolutionizing mixed workloads. Because it eliminates the need to manage additional data pipelines or databases, developers are finding it helpful for extracting real-time analytical insights from their transactional data. To speed up queries, you can instead activate the columnar engine, allocate a piece of your memory to it, and let AlloyDB Omni to choose which tables or columns to load in the columnar engine. The columnar engine outperforms regular PostgreSQL by up to 100x in our benchmarks for analytical queries.
The amount of RAM you can allocate to the columnar engine dictates the analytics accelerator’s practical size limit. The ability to set up a quick local storage device for the columnar engine to spill to is a new feature. This expands the amount of data on which you may do analytical queries.
SCaNN becomes GA
Finally, AlloyDB Omni already provides excellent performance with pgvector utilizing either the ivf or hnsw indexes for vector database use cases. Vector indexes, however, can be slow to build and reload even though they are a terrific method to speed up queries. It added the ScaNN index as an additional index type at Google Cloud Next 2024. The ScaNN index from AlloyDB AI provides up to 4 times faster vector queries than the HNSW index used in ordinary PostgreSQL. ScaNN offers substantial benefits for practical applications beyond only speed:
- Rapid indexing: With noticeably quicker index build times, you may expedite development and remove bottlenecks in large-scale deployments.
- Optimized memory usage: Cut memory usage by three to four times as compared to PostgreSQL’s HNSW index. This improves performance for a variety of hybrid applications and enables larger workloads to operate on smaller hardware.
In general, AlloyDB AI ScANN indexing is accessible as of AlloyDB Omni version 15.7.0.
A fresh Kubernetes administrator
Google Cloud has published version 1.2.0 of the AlloyDB Omni Kubernetes operator in addition to the latest version of AlloyDB Omni. With this release, you can now configure high availability to be enabled when a disaster recovery secondary cluster is promoted to primary, add more configuration options for health checks when high availability is enabled, and use log rotation to help manage the storage space used by PostgreSQL log files.
Version 1.2.0 of the AlloyDB Omni Kubernetes operator is now broadly accessible (GA). The following new features are included in version 1.2.0:
- The interval between health checks can be set in seconds using the healthcheckPeriodSeconds option.
- You can keep an eye on your database container’s performance with the following metrics. These measurements are all type gauge.
- A database container’s memory limit is displayed by alloydb_omni_memory_limit_byte.
- All replicas connected to the AlloyDB Omni primary node are shown in alloydb_omni_instance_postgresql_replication_state.
- The database container’s memory usage is displayed in bytes via alloydb_omni_memory_used_byte.
- When the following is true, a problem that briefly disrupted all database clusters has been resolved:
- The AlloyDB Omni Kubernetes operator version 1.1.1 is being upgraded to a more recent version.
- Version 15.5.5 or higher of the AlloyDB Omni database is what you’re using.
- AI for AlloyDB is not activated.
- Once promoted, high availability is supported on a secondary database cluster.
- Model endpoint management can be enabled or disabled using Kubernetes manifests.
- By setting thresholds depending on the size of the log files, the amount of time since the log file last rotated, or both, you may control when logs rotate.
- To examine and troubleshoot the memory performance of the AlloyDB Omni Kubernetes operator, you can take a snapshot of its memory heap.
Note: Parameterized view features were accessible via the alloydb_ai_nl extension of AlloyDB Omni versions 15.5.5 and earlier. The parameterized_views extension, which you must develop before using parameterized views, contains the parameterized view features starting in AlloyDB Omni version 15.7.0. The associated function, google_exec_param_query, has also been renamed to execute_parameterized_query and is accessible through the parameterized_views extension as of AlloyDB Omni version 15.7.0.
