Has it already been a year since OpenSearch joined the Linux Foundation? And now you’re here, reading about OpenSearch 3.2—momentum has really picked up! Today I’ll dive into the changes this minor release will bring, namely, gRPC and AI use-case improvements.

gRPC

gRPC, which according to research isn’t its own acronym, is a Remote Procedure Call or RPC, framework made by Google. It allows for easier and faster communication between programs on different hosts: you can configure remote functions to be run just like local ones. gRPC calls use protocol buffers, also called protobufs, extensively. These are serialized chunks of structured data, coupled with features like HTTP/2 support, that can be moved quickly across services.

The overall benefit gRPC brings to the table is in the use case where you have multiple code bases in different languages, and you want to run a function from A in B’s codebase. If you want service B, written in Java, to call a function in service A, written in C++, you need to use an RPC; but there are multiple ways to go about it. This is where gRPC steps in. It uses a universal language (expressed in protobufs) to tell servers what services (programs that receive RPC calls) to call when local functions are invoked.

You can also use protobuf as the underlying structure for your communicated data: it’s similar to JSON in that it’s a serialized data format. gRPC even uses protobufs as the language to define gRPC services that can be automatically generated. Support for gRPC is extensive, spanning most popular languages like C++, JavaScript, and Python.

In OpenSearch 3.2, the Search API will have gRPC services; you will be able to conduct multi-node searches and other tasks with gRPC and protobufs. This was implemented in Search API because when it was implemented in the Nodes API, contributors measured “a 15-30% improvement depending on the size of the cluster” in the speed of calls done with gRPC. That’s a marked improvement, and the contributors decided to try it with the Search API. Now, it’s implemented and shipping in 3.2.

This required a lot of work; the meta ticket for this has been a year in the making. This is because gRPC support required changes, tickets, and work to nearly every part of the OpenSearch project. It was a monumental effort by the OpenSearch contributors, but the performance gains on the Search API make it worth it. That being said, there were other benefits, not all performance related. For instance, gRPC comes with a lot of measurable data about how long the RPC takes to run, how long communications take, etc. This information is easily accessible, so the performance of gRPC calls can be measured, analysed, and visualized in OpenSearch Dashboards.

OpenSearch 3.2 brings important improvements for AI workloads, particularly in areas like k-Nearest Neighbor (k-NN) search, dense vector fields, semantic field configuration, and anomaly detection. These enhancements help developers and data teams build more intelligent, scalable search and analytics applications that rely on machine learning models and high-dimensional data.

One of the most significant updates in this release is the improved performance and scalability of k-NN search. This feature is essential for use cases like similarity search, recommendation systems, and natural language processing tasks where fast and accurate nearest-neighbor lookups are required. OpenSearch 3.2 optimizes the way k-NN search is handled, enabling more efficient queries even on large datasets.

Dense vector fields, another key enhancement in 3.2, provide critical support for storing and querying model embeddings. These fields are foundational for semantic search and other AI-driven applications that depend on high-dimensional data representations. With better support for dense vector fields, OpenSearch can now power more sophisticated and accurate search experiences.

Anomaly detection also saw improvements in this release, reinforcing its role in monitoring and alerting for AI workloads. Whether you’re watching for data drift, unusual patterns, or system health issues, the improved anomaly detection capabilities in OpenSearch 3.2 make it easier to catch issues early. Of course, there are many more features packed into this release with version 3.2 being a major step forward for anyone building AI-powered search systems. Those interested can explore the full details on the OpenSearch GitHub issue tracker.

Looking forward: The future of OpenSearch

This OpenSearch version represents just the beginning of exciting developments in the platform’s roadmap. The foundation laid by gRPC support and AI enhancements opens doors for even more innovative features in future releases.

Stay connected with the OpenSearch community to learn more about upcoming development priorities and get early access to upcoming features.