AlloyDB Omni is back with a new release, version 15.7.0, and it’s bringing serious enhancements to your PostgreSQL workflows, including:
-
Faster performance
-
A new ultra-fast disk cache
-
An enhanced columnar engine
-
The general availability of ScANN vector indexing
-
A new release of the AlloyDB Omni Kubernetes operator
From transactional and analytical workloads to cutting-edge vector search, this update delivers across the board – in your data center, at the edge, on your laptop, and in any cloud and with 100% PostgreSQL compatibility.
Let’s jump in.
Better performance
Many workloads already get a boost compared to standard PostgreSQL. In our performance tests, AlloyDB Omni is more than 2x faster than standard PostgreSQL for transactional workloads, with most of the tuning being done for you automatically, without special configurations. One of the key advantages is the memory agent that optimizes shared buffers while at the same time avoiding out-of-memory errors. In general, the more memory you configure for AlloyDB Omni, the better it performs, serving more queries from the shared buffers and reducing the need to make calls to disk, which can be magnitudes slower than memory, particularly when using durable network storage
- aside_block
- <ListValue: [StructValue([('title', '$300 in free credit to try Google Cloud databases'), ('body', <wagtail.rich_text.RichText object at 0x3e5cbb5e4a90>), ('btn_text', 'Start building for free'), ('href', 'http://console.cloud.google.com/freetrial?redirectPath=/products?#databases'), ('image', None)])]>
An ultra-fast disk cache
This trade-off between memory and disk storage also just got more flexible, with the introduction of an ultra-fast disk cache. It allows you to configure a fast, local, and not necessarily durable storage device as an extension of Postgres’ buffer cache. Instead of aging data out of memory to make space for new data, AlloyDB Omni can keep a copy of not-quite-hot data in the disk cache, where it can be accessed faster than from persistent disk.
Enhanced columnar engine
AlloyDB Omni’s analytics accelerator is changing the game for mixed workloads. Developers are finding it invaluable for gaining real-time analytical insights from their transactional data, all without the overhead of managing extra data pipelines or separate databases. You can instead enable the columnar engine, assign a portion of your memory to it, and let AlloyDB Omni decide which columns or tables to populate in the columnar engine to speed up queries. In our benchmarks, the columnar engine speeds up analytical queries up to 100x compared to standard PostgreSQL.
The practical size limit to the analytics accelerator was determined by the amount of memory you are able to assign to the columnar engine. What’s new is a feature that allows you to configure a fast local storage device for the columnar engine to spill to. This increases the volume of data that you can run analytical queries on.
SCaNN goes GA
Lastly, for vector database use-cases, AlloyDB Omni already offers great performance with pgvector using either the ivf or hnsw indexes. But while vector indexes are a great way to accelerate queries, they can be slow to build and rebuild. At Google Cloud Next 2024 we introduced ScaNN index as another available index type. AlloyDB AI’s ScaNN index surpasses standard PostgreSQL’s HNSW index by offering up to 4x faster vector queries. Beyond pure speed, ScaNN delivers significant advantages for real-world applications:
-
Rapid indexing: Accelerate development and eliminate bottlenecks in large-scale deployments with significantly faster index build times.
-
Optimized memory utilization: Reduce memory consumption by 3-4x compared to PostgreSQL’s HNSW index. This allows larger workloads to run on smaller hardware and boosts performance for diverse, hybrid workloads.
As of AlloyDB Omni version 15.7.0, AlloyDB AI ScANN indexing is generally available.
A new Kubernetes operator
In addition to the new version of AlloyDB Omni, we have also released version 1.2.0 of the AlloyDB Omni Kubernetes operator. This release adds support for more configuration options for health checks when high availability is enabled, support for configuring high availability to be enabled when a disaster recovery secondary cluster is promoted to primary, and support for log rotation to help manage storage space used by PostgreSQL log files.
Ready to explore? Dive into the full release notes and experience the new features. Try them now in our marketplace image or grab the latest container image from Docker Hub! Also, learn why AlloyDB is the new way to PostgreSQL in this ebook.