# OpenSearch® version 3.2: Game-changing gRPC support and AI enhancements [Blog](/blog/)>[Technology](/blog/category/technical/)>OpenSearch® version 3.2: Game-changing gRPC support and AI enhancements OpenSearch® version 3.2: Game-changing gRPC support and AI enhancements ======================================================================= September 02, 2025 | By [ Kassian Wren](https://www.instaclustr.com/blog/author/kassian-wren/) [ ](https://x.com/intent/tweet?text=OpenSearch%C2%AE%20version%203.2:%20Game-changing%20gRPC%20support%20and%20AI%20enhancements&url=https://www.instaclustr.com/blog/opensearch-version-3-2-game-changing-grpc-support-and-ai-enhancements/) [ ](https://www.linkedin.com/shareArticle?mini=true&url=https://www.instaclustr.com/blog/opensearch-version-3-2-game-changing-grpc-support-and-ai-enhancements/&title=&summary=OpenSearch%C2%AE%20version%203.2:%20Game-changing%20gRPC%20support%20and%20AI%20enhancements&source=) 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](https://github.com/opensearch-project/OpenSearch/issues/10684)” 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](https://github.com/orgs/opensearch-project/projects/206/views/21?pane=issue&itemId=95873068&issue=opensearch-project%7COpenSearch%7C16786) 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](https://github.com/orgs/opensearch-project/projects/206/views/21?pane=issue&itemId=95873068&issue=opensearch-project%7COpenSearch%7C16786). 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. ### About the author **[Kassian Wren](https://www.instaclustr.com/blog/author/kassian-wren/)** | Open Source Technology Advocate Kassian specializes in open source technologies like OpenSearch and Cassandra. With over a decade of experience, they excel in creating impactful educational content across various formats and actively engage with the developer community through events, online platforms, and live presentations. Passionate about fostering knowledge-sharing, Kassian combines technical expertise with community-focused outreach to support and inspire developers worldwide. [ Add Instaclustr as a preferred source on Google ](https://google.com/preferences/source?q=instaclustr.com) ![mail icon]()#### Get the latest articles for open sourceIn your inbox Sign up now ### Related content [ 5 Essential considerations for an Elasticsearch to OpenSearch migration Streamline your Elasticsearch to OpenSearch migration with these five essential tips. Learn how to handle plugins, limitations, ... ](https://www.instaclustr.com/blog/5-essential-considerations-for-an-elasticsearch-to-opensearch-migration/) [ Announcing NetApp and Pegasystems Open Source Support Package Instaclustr is excited to announce our collaboration with Pegasystems to provide tailored support packages for Pega customers... ](https://www.instaclustr.com/blog/netapp-and-pegasystems-open-source-support-package/) [ Announcement: OpenSearch® and the Linux Foundation The OpenSearch Project is moving to the Linux Foundation – and Instaclustr is now a General Member! Read all the details here... ](https://www.instaclustr.com/blog/announcement-opensearch-and-the-linux-foundation/) ×Sign upto ourNewsletter -----------------------