Search is becoming a critical foundation for modern applications, observability platforms, enterprise knowledge systems, and AI-powered discovery experiences. Customers are using OpenSearch not only for traditional keyword search, but also for semantic search, vector search, hybrid retrieval, log analytics, and retrieval-augmented generation.
Today, we are excited to announce new capabilities for OCI Search with OpenSearch that help customers build more intelligent, scalable, and resilient search workloads on OCI:
- OpenSearch 3.6 support
- Dedicated ML nodes
- Dedicated coordinator nodes
- AD/FD-aware shard placement for high availability
OCI Search with OpenSearch is a managed service for building OpenSearch-based search solutions, enabling customers to search large datasets while Oracle manages the underlying service operations such as security updates, upgrades, resizing, and scheduled backups.
Build AI-ready search experiences with OpenSearch 3.6
With OpenSearch 3.6 support, customers can build on a newer OpenSearch version in OCI Search with OpenSearch. This helps teams modernize their search environments and take advantage of newer capabilities for AI-powered search, vector search, ingestion, observability, and query analysis.
This is especially important as customers expand from traditional search into more intelligent discovery experiences. Application teams are increasingly building search experiences that combine keyword relevance, semantic understanding, embeddings, vector retrieval, and generative AI workflows. OpenSearch 3.6 gives customers a stronger foundation for these use cases on OCI.
Customers can use OpenSearch 3.6 to support workloads such as:
- Semantic search
- Vector search
- Hybrid search
- AI-powered application search
- Enterprise knowledge discovery
- Retrieval-augmented generation
- Observability and query analysis use cases
For teams building AI-driven applications on OCI, this release helps make OCI Search with OpenSearch a more modern platform for intelligent discovery and search-backed AI experiences. Customers can also review the supported Search with OpenSearch versions when planning new deployments or upgrades.
Isolate AI and machine learning workloads with dedicated ML nodes
OCI Search with OpenSearch now supports dedicated ML nodes, giving customers an isolated compute layer for machine learning and AI workloads inside their OpenSearch clusters.
This matters because AI and ML workloads can be compute intensive. Model deployment, inference, text embedding generation, anomaly detection, and AI-driven analytics can compete with indexing and search operations if they run on the same resources. Dedicated ML nodes help separate these workloads from data and cluster-manager nodes, improving workload isolation and helping customers maintain more predictable search and indexing performance.
Dedicated ML nodes are especially useful for customers building:
- Semantic search pipelines
- Vector search applications
- Embedding generation workflows
- Anomaly detection solutions
- AI-driven analytics
- Search-backed generative AI applications
With dedicated ML nodes, customers can scale AI and ML processing more independently from the rest of the cluster. This gives teams a cleaner production architecture for AI-powered search workloads and helps reduce resource contention between ML processing and core OpenSearch operations.
Customers can configure ML nodes when creating or managing an OpenSearch cluster. For implementation details, see the OCI documentation for creating a Search with OpenSearch cluster and managing Search with OpenSearch clusters.
Improve search performance with dedicated coordinator nodes
As search workloads grow, customers often need to support higher query concurrency, larger aggregations, dashboard-heavy traffic, and latency-sensitive APIs. These patterns can increase pressure on data nodes, which are also responsible for data storage, indexing, and shard-level search execution.
With dedicated coordinator nodes, customers can separate search request coordination from data-node responsibilities. Coordinator nodes offload coordination tasks from data nodes, including managing search requests and hosting OpenSearch Dashboards. This allows data nodes to focus more on data storage, indexing, and search operations.
This is valuable for customers running:
- Customer-facing search applications
- High-concurrency read workloads
- OpenSearch Dashboards-heavy environments
- Large aggregation workloads
- Log analytics and observability platforms
- Enterprise search portals
- Latency-sensitive search APIs
For production workloads, dedicated coordinator nodes give customers a more scalable architecture. Data nodes can focus more on storage, indexing, and shard-level query execution, while coordinator nodes handle request routing, result collection, aggregation, and response assembly.
Customers can learn more about configuring coordinator nodes in the OCI documentation for creating Search with OpenSearch clusters.
Improve data availability with AD/FD-aware shard placement
High availability is not only about creating replicas. It also depends on where those replicas are placed.
With AD/FD-aware shard placement, OCI Search with OpenSearch can place primary and replica shards with awareness of OCI availability domains and fault domains. OCI availability domains and fault domains provide infrastructure-level isolation boundaries that help customers design highly available applications on OCI.
This capability is handled automatically by the OCI Search with OpenSearch service and does not require customer intervention. By placing shard copies with awareness of OCI failure boundaries, the service helps reduce the risk that a localized infrastructure event affects both a primary shard and its replica.
For customers, the benefit is stronger data availability and reduced business disruption for production OpenSearch workloads. This is especially important for mission-critical application search, observability, log analytics, enterprise discovery, and AI-powered search applications where search availability directly impacts user experience or operations.
For more information about the managed service, see the OCI Search with OpenSearch overview.
Getting started
Customers can get started by creating a new OCI Search with OpenSearch cluster using OpenSearch 3.6 or by upgrading eligible existing clusters. OCI Search with OpenSearch supports multiple concurrent OpenSearch versions, including 3.6.0. Customers can review the latest supported versions before planning a deployment or upgrade.
For AI and ML workloads, customers should evaluate dedicated ML nodes to isolate model deployment, inference, embedding generation, anomaly detection, and related AI processing.
For query-heavy workloads, customers should consider dedicated coordinator nodes to reduce pressure on data nodes and improve workload isolation.
For production workloads with high-availability requirements, customers should review replica settings, cluster topology, and availability objectives.
With these new capabilities, OCI Search with OpenSearch continues to help customers build fast, intelligent, scalable, and resilient search experiences on OCI while reducing the operational burden of managing OpenSearch infrastructure themselves.