Supported environments
API means the profile adapts origin API behavior. Infrastructure means the profile changes provisioned resources or documents a target-native alternative without promising an origin API endpoint. Check the operation and capability tables for the behavior your application depends on.
How the targets compare
Each row compares a capability of OpenSearch Domain with its adaptation on each target. A dash means this profile does not state the capability for that target.Cloud Adapter
On Akamai, Azure, DigitalOcean, Google Cloud, Private Kubernetes, and Scaleway
OpenSearch
OpenSearch in the customer cluster
Tensor9 provisions OpenSearch on Kubernetes through an OpenSearchCluster resource or Helm chart and configures the application endpoint. Document and search requests go directly to the cluster’s OpenSearch API. The customer operates the cluster and its storage.
Engine and plugin compatibility
The target runs the OpenSearch engine and its bundled plugins. The listed document, index, search, aggregation, ingest and scripting operations retain their OpenSearch APIs. Match the engine and plugin versions to the application; sharing an engine name does not make different versions byte-identical. The distribution includes k-NN vector search, SQL, PPL, Index State Management, Alerting, Anomaly Detection and ML Commons. Their native _plugins APIs run on the cluster. Elasticsearch licensing endpoints _license and _xpack are not OpenSearch APIs.Topology and access
Define node pools with CPU, memory and PersistentVolume capacity. A dedicated cluster_manager pool maintains the cluster quorum; use at least three eligible nodes and distribute replicas across failure domains. OpenSearch renamed the master role to cluster_manager in version 2.0. Configure shard allocation and plan rolling upgrades for the selected version. The OpenSearch Security plugin controls roles, role mappings and internal users, including supported SAML, OIDC or LDAP sign-in and document- or field-level access. Translate AWS IAM-based access into this configuration. Replace bootstrap certificates and default credentials before exposing the cluster.Storage and recovery
PersistentVolumes and their StorageClasses determine disk capacity, IOPS and encryption. They do not inherit a domain-specific AWS KMS key setting. Availability depends on node placement, quorum and index replicas; the self-managed cluster has no managed uptime SLA. Register a snapshot repository and schedule creation and retention with OpenSearch Snapshot Management. An S3-compatible repository requires the repository-s3 plugin and object-store endpoint configuration. Keep backups outside the cluster’s failure domain and verify a restore. OpenSearch Snapshot Management is distinct from Elasticsearch Snapshot Lifecycle Management.Migration and operation
The cluster starts empty. Restore a compatible snapshot or reindex from the source, then verify index mappings and queries before cutover. Size shards, replicas and storage for the workload; shard sizes in the tens of gigabytes are a starting point to evaluate, not a fixed limit. The customer operates Kubernetes capacity, storage expansion, cluster health, upgrades and snapshots. Tensor9 provisions the deployment and endpoint; it does not add a query proxy or a managed durability guarantee.On Azure
Azure Native Elastic
OpenSearch requests on Elasticsearch
Azure Native Elastic runs Elasticsearch 8.x. The Tensor9 adapter accepts the application’s OpenSearch requests, translates supported APIs and authentication, and sends them to the managed Elasticsearch endpoint. Tensor9 provisions the Elastic resource in the customer’s Azure tenant through the Azure Native integration. Elastic operates Elasticsearch; the resource is purchased and billed through the customer’s Azure subscription.
Core requests and authentication
The adapter forwards the supported document, search, aggregation, index, cluster, ingest and scripting operations. It translates request and response differences, including the point-in-time path from _search/point_in_time to _pit. AWS SigV4 authentication is checked by the adapter; target requests use Elastic credentials or API keys. Configure target permissions in Elastic’s security model. Elasticsearch 8.x provides compatible-with=7 headers for its earlier REST API contract. The adapter uses that facility where applicable, alongside the required translations. It does not make every OpenSearch request or client version compatible. Validate the application’s queries, response parsing and client behavior against the listed operations. See Elastic’s API compatibility documentation.Plugin translations
OpenSearch and Elasticsearch use different plugin APIs. The mapping translates k-NN vector mappings from knn_vector to dense_vector and converts the query to Elasticsearch’s knn form. SQL requests move from _plugins/_sql to _sql with translated response fields. Index State Management policies map to Elasticsearch Index Lifecycle Management where their actions can be represented. Custom ISM states and transitions do not round-trip through ILM’s fixed phases. The described alerting, anomaly-detection and machine-learning mappings use Elasticsearch _watcher and _ml capabilities. Some need a paid Elastic subscription. The operation table separates those translations from excluded APIs: PPL, the OpenSearch Security API, notifications and observability objects remain outside the mapping. Elasticsearch _license and _xpack are not OpenSearch APIs.Deployment and availability
The Azure resource does not expose the full deployment topology. Set size and topology in the Elastic Cloud console. The documented default is 16 GB RAM, 560 GB storage and two availability zones, with instances up to 256 GB RAM. The subscription determines commercial features and the applicable availability commitment. Elastic Cloud publishes monthly availability commitments of 99.5%, 99.9% and 99.95% for one-, two- and three-zone deployments, subject to the subscription and high-availability conditions. Choose topology and subscription together. The target uses Elastic security configuration, API keys and single sign-on rather than OpenSearch Security roles. Document- and field-level security and other commercial features depend on the purchased subscription. The hosted offering’s subscription conditions apply regardless of the source-code license. Elastic added an AGPLv3 option for the free source portions in 2024; see its licensing FAQ.Snapshots and migration
The deployment starts empty. Move data with a compatible remote reindex or bulk export/import workflow; do not assume an OpenSearch snapshot restores across the engine fork. Review mappings, analyzers and index settings before loading data, and verify representative queries before switching traffic. Elastic Snapshot Lifecycle Management controls target backup schedules and retention. Preserve the application’s recovery requirements when replacing AWS-managed snapshots. The adapter does not translate OpenSearch Security configuration, PPL or notification/observability objects; these need target-native configuration or an application change.Sizing and performance
Choose shard layout, replicas, data tiers and memory for the application’s indexing and query workload. Published engine benchmarks describe their particular versions and datasets; they do not measure this adaptation. Measure the deployed application, including translated operations, when selecting capacity.On DigitalOcean
OpenSearch Domain
Keep the managed domain
The application can continue using its existing AWS OpenSearch domain while other services run in the target environment. AWS continues to operate the domain. Its engine, plugin APIs, security configuration, and managed snapshots stay in place.Connectivity and ownership
The customer deployment must be able to reach and authenticate to the AWS domain endpoint. This choice keeps an AWS service dependency and its existing operational ownership.DigitalOcean Managed OpenSearch
How it works
On AWS your app talks to an Amazon OpenSearch domain over the OpenSearch REST API. Its OpenSearch or Elasticsearch client opens a connection to the domain endpoint and issues_bulk, _search, and the rest. To run that same app on DigitalOcean, the compiler provisions a DigitalOcean Managed OpenSearch cluster and points your client’s endpoint at it.
Tensor9 configures the client endpoint to connect directly to the target cluster at build time. Your app keeps the same clients and the same request formats; they speak the same OpenSearch wire straight to the DigitalOcean cluster. No Tensor9 component handles these requests (there is no translating adapter here), so every index and query runs against DigitalOcean’s OpenSearch engine directly, at the cluster’s own latency.
DigitalOcean runs the cluster as a managed database: it provisions the nodes and operates the backups, failover, and version upgrades. The cluster it hands you starts empty, so your data moves over separately.
Your OpenSearch domain is compiled to a DigitalOcean Managed OpenSearch cluster; the endpoint is rewired to it and your existing clients connect straight through, with no proxy in the data path.
The same engine
DigitalOcean Managed OpenSearch runs the OpenSearch engine at version 2.19 (Apache-2.0, derived from Elasticsearch 7.10.2), the same engine your AWS domain runs. So the core REST API is byte-identical: index and document operations (_doc, _bulk), search and aggregations (_search), mappings, ingest, and Painless scripting behave as they do today.
The plugin APIs live under OpenSearch’s own _plugins/* namespace, and on DigitalOcean they are the real bundled OpenSearch plugins: k-NN and Neural search for vectors (_plugins/_knn), SQL and PPL (_plugins/_sql, _plugins/_ppl), Index State Management, Alerting, Anomaly Detection, and ML Commons. Because the distribution is the genuine one, these run as themselves rather than standing in for a different search product.
One vector detail affects sizing: k-NN and Neural search are present, but DigitalOcean does not offer a disk-resident approximate-nearest-neighbor index, so vector work is bounded by the node’s RAM. That shapes how you size a cluster whose queries lean on large HNSW graphs.
The core index, search, and aggregation API is byte-identical, and the _plugins/* features are the OpenSearch plugins bundled in DigitalOcean’s 2.19 distribution.
What changes: operational ownership
On AWS the domain is AWS’s to operate; on DigitalOcean the cluster is DigitalOcean’s to operate . DigitalOcean provisions the nodes and runs the managed lifecycle: automated backups (hourly for the first 24 hours, then daily for up to 3 more days), failover to a standby node, and in-place version upgrades. Node health and patching are DigitalOcean’s job, shaped by its control panel and API rather than by AWS’s. Choose the plan class (Basic, General Purpose, or Memory-Optimized), the node count, and the managed storage size. There is no separate dedicated-master tier to configure the way an AWS domain has one; you add a standby node when you want failover. This is a shift in operational ownership: with no proxy in the data path, the cluster’s performance is its own, reported by your own monitoring.
What changes is operational ownership: DigitalOcean runs the managed lifecycle (backups, failover, upgrades), and you choose the plan, node count, and storage size.
Network and access on DigitalOcean
Reaching the cluster and authorizing to it work differently from AWS. The cluster can sit in a DigitalOcean VPC and be reached over a private network; who may connect is governed by a trusted-sources allow-list of IP addresses and DigitalOcean resources (up to 2,000 entries per cluster), in place of AWS security groups and VPC endpoint policies. DigitalOcean Cloud Firewalls do not apply to the managed cluster, and with trusted sources enabled some DigitalOcean log-forwarding paths are unavailable. Inside the cluster, DigitalOcean exposes a singledoadmin superuser. The OpenSearch Security plugin is present, but DigitalOcean does not currently offer creating extra users or roles through its control panel or API. If your AWS setup leaned on fine-grained, per-index or per-user access control, that model is re-expressed around the one doadmin credential rather than inherited from AWS.
Connections are encrypted in transit with SSL, and data is encrypted at rest with LUKS, always on, with no customer-managed key option.
Access is gated by a DigitalOcean trusted-sources allow-list inside a VPC, and the cluster exposes a single doadmin superuser rather than DigitalOcean-managed users and roles.
Limitations
The OpenSearch API remains unchanged. DigitalOcean uses different access controls, backup schedules, and sizing options; review these differences before switching traffic. △ Plan these before moving an AWS OpenSearch domain to DigitalOcean Managed OpenSearch- Users and roles: only the
doadminsuperuser. AWS fine-grained access control (per-index and per-user roles) has no counterpart; DigitalOcean does not currently offer managing extra OpenSearch users or roles, so access control is re-expressed around the singledoadmincredential. - Backups follow DigitalOcean’s model, not AWS’s: automated backups are hourly for the first 24 hours, then daily for up to 3 more days, with point-in-time recovery limited to the last 7 days; a restore creates a new cluster rather than restoring in place. Confirm this window meets your retention needs.
- Networking is trusted sources, not security groups: access is an IP and resource allow-list (up to 2,000 entries) inside a DigitalOcean VPC; AWS security groups, VPC endpoint policies, and Cloud Firewalls do not apply, and some DigitalOcean log-forwarding paths are unavailable when trusted sources are on.
- Vector search is memory-bound: k-NN and Neural search are bundled, but DigitalOcean offers no disk-resident ANN index, so large HNSW graphs must fit in node RAM; size the plan for the vector working set.
- DigitalOcean sizing and key limits: clusters are sized by plan (Basic is 1 or 3 nodes; General Purpose and Memory-Optimized allow 1, 3, 6, 9, or 15) with managed storage and no BYOK; AWS instance types and EBS ceilings do not map verbatim.
- The SLA covers Managed Databases generically. DigitalOcean’s Managed Databases SLA is 99.95% monthly uptime with a standby node and 99.5% without; it applies to Managed Databases as a class and does not name OpenSearch specifically.
Other considerations
Plan versions, capacity, and data migration before switching traffic.On DigitalOcean and Scaleway
Lucenia (self-hosted)
How it works
On AWS your app talks to an Amazon OpenSearch domain over the OpenSearch REST API. Its OpenSearch or Elasticsearch client opens a connection to the domain endpoint and issues_bulk, _search, and the rest. To run that same app in the target cloud, the compiler provisions a self-hosted Lucenia cluster on Kubernetes (the Lucenia Helm chart) and points your client’s endpoint at it.
Tensor9 configures the client endpoint to connect directly to the target cluster at build time. Lucenia presents an OpenSearch-compatible REST API, so your existing clients connect straight to it and keep the same request formats. No Tensor9 component handles these requests, so every index and query runs against the Lucenia cluster directly, at its own latency.
Your OpenSearch domain is compiled to a self-hosted Lucenia cluster on Kubernetes; the endpoint is rewired to it and your existing clients connect straight through, with no proxy in the data path.
A compatible fork
Lucenia is a separate project derived from OpenSearch 2.14, built by the creator of OpenSearch. It uses Apache Lucene 10.4 and documents API and mixed-cluster compatibility with OpenSearch and Elasticsearch. Lucenia is dual-licensed under Apache-2.0 and SSPL. Because that API tracks roughly OpenSearch 2.18, your core client calls (_doc, _bulk, _search, mappings, aggregations) land as they do today, and vector search is confirmed (k-NN with Lucene-native HNSW, IVF, and Faiss, plus hybrid BM25 and vector). The caveat is maturity: Lucenia is at an early 0.x version (0.11.1 at the current release), so it is a young, compatible engine you adopt deliberately, not a generally-available managed peer of the cloud services.
Lucenia is not the OpenSearch engine itself: it is a separate, API-compatible fork on Apache Lucene 10.4, so the REST compatibility is what keeps your clients working, not a shared codebase.
What is confirmed, and what is unverified
Lucenia confirms support for documents, search, aggregations, and vector search. Its k-NN support uses Lucene-native HNSW, IVF, and Faiss; hybrid BM25 and vector queries run on the Lucene 10.4 core. Existing OpenSearch REST clients connect directly. The rest of OpenSearch’s_plugins/* features sit at the lower confidence level. SQL and PPL, Index State Management, Alerting, Anomaly Detection, and ML Commons have no published per-plugin parity matrix on Lucenia, so their compatibility remains unverified. Check the specific APIs your app calls against your Lucenia version before you depend on them, and treat Lucenia’s own performance and cost marketing (which publishes no methodology) as uncited.
Core and vector search are confirmed on Lucenia; the other _plugins/* features have no published parity matrix, so this page marks them unverified.
What changes: you operate it
You operate the cluster. On the AWS domain, AWS ran high availability, version upgrades, daily snapshots, and fine-grained access control under a managed SLA. A self-hosted Lucenia cluster is yours to run: you define the node pools (data and master), replica counts, and cross-zone placement; you schedule snapshots; and you own version upgrades on an early 0.x project, where releases can move quickly and upgrade paths are still maturing. Security is re-expressed too. The access control AWS wired into the domain becomes Lucenia’s own security configuration (its SSPL security component, with the initial admin credential set throughLUCENIA_INITIAL_ADMIN_PASSWORD), configured out of band rather than inherited from AWS. There is no provider availability SLA here: the cluster’s uptime is whatever you run, and its latency and throughput are its own, reported by your monitoring.
The AWS-managed features and the managed SLA become your responsibility: you operate the Lucenia cluster on Kubernetes, and there is no provider availability SLA.
Limitations
Existing clients use Lucenia’s compatible REST API. Review the unverified plugins, early release status, and absence of a provider availability guarantee before choosing this target. △ Where an AWS OpenSearch domain and self-hosted Lucenia diverge- A different engine, not the OpenSearch codebase. Lucenia is an OpenSearch-2.14-derived fork on Apache Lucene 10.4, not the OpenSearch engine the domain runs. The REST compatibility is what your clients rely on, but this is a distinct project with its own release cadence and its own defects.
_plugins/*beyond k-NN is unverified. SQL, PPL, ISM, Alerting, Anomaly Detection, and ML Commons have no published parity matrix on Lucenia. Confirm each API your app calls before cutover; do not assume domain-level plugin behavior.- Early-stage 0.x maturity. Lucenia is at
0.11.1, a young project. Ecosystem tooling, client testing against it, long-term support commitments, and upgrade stability are all less established than a generally-available managed service; weigh that against the workload’s risk tolerance. - No availability SLA: this deployment target is self-operated on Kubernetes, so no provider guarantees uptime. (A separate managed Lucenia Cloud exists, but it is not this self-hosted target.)
- Managed domain features become yours: daily snapshots, fine-grained access control, and specific instance families and EBS ceilings are not inherited from AWS; Lucenia is sized in your own node pools and storage (
persistence.size,storageClass) and secured through its own model. - The cluster starts empty: indices are not auto-migrated; restore from a snapshot or reindex from the source before traffic cuts over.
- SSPL is part of the license. Lucenia is dual-licensed Apache-2.0 and SSPL; the SSPL terms matter if you would ever offer it as a service to third parties, so review the license against your intended use.
Other considerations
Plan data migration, operations, and version testing before switching traffic to Lucenia.On DigitalOcean and Google Cloud
Elastic Cloud (managed)
OpenSearch requests on Elasticsearch
Elastic Cloud Hosted runs Elasticsearch 8.x. The Tensor9 adapter accepts the application’s OpenSearch requests, translates supported APIs and authentication, and sends them to the managed Elasticsearch endpoint. Tensor9 provisions an ec_deployment in the customer’s Google Cloud environment. Elastic operates Elasticsearch and Kibana; the customer selects the deployment configuration.
Core requests and authentication
The adapter forwards the supported document, search, aggregation, index, cluster, ingest and scripting operations. It translates request and response differences, including the point-in-time path from _search/point_in_time to _pit. AWS SigV4 authentication is checked by the adapter; target requests use Elastic credentials or API keys. Configure target permissions in Elastic’s security model. Elasticsearch 8.x provides compatible-with=7 headers for its earlier REST API contract. The adapter uses that facility where applicable, alongside the required translations. It does not make every OpenSearch request or client version compatible. Validate the application’s queries, response parsing and client behavior against the listed operations. See Elastic’s API compatibility documentation.Plugin translations
OpenSearch and Elasticsearch use different plugin APIs. The mapping translates k-NN vector mappings from knn_vector to dense_vector and converts the query to Elasticsearch’s knn form. SQL requests move from _plugins/_sql to _sql with translated response fields. Index State Management policies map to Elasticsearch Index Lifecycle Management where their actions can be represented. Custom ISM states and transitions do not round-trip through ILM’s fixed phases. The described alerting, anomaly-detection and machine-learning mappings use Elasticsearch _watcher and _ml capabilities. Some need a paid Elastic subscription. The operation table separates those translations from excluded APIs: PPL, the OpenSearch Security API, notifications and observability objects remain outside the mapping. Elasticsearch _license and _xpack are not OpenSearch APIs.Deployment and availability
The ec_deployment resource exposes hot, warm, cold and frozen tiers, instance size, one to three availability zones, and per-tier autoscaling. Storage is bundled at the selected tier’s disk-to-memory ratio. The subscription determines commercial features and the applicable availability commitment. Elastic Cloud publishes monthly availability commitments of 99.5%, 99.9% and 99.95% for one-, two- and three-zone deployments, subject to the subscription and high-availability conditions. Choose topology and subscription together. The target uses Elastic security configuration, API keys and single sign-on rather than OpenSearch Security roles. Document- and field-level security and other commercial features depend on the purchased subscription. The hosted offering’s subscription conditions apply regardless of the source-code license. Elastic added an AGPLv3 option for the free source portions in 2024; see its licensing FAQ.Snapshots and migration
The deployment starts empty. Move data with a compatible remote reindex or bulk export/import workflow; do not assume an OpenSearch snapshot restores across the engine fork. Review mappings, analyzers and index settings before loading data, and verify representative queries before switching traffic. Elastic Snapshot Lifecycle Management controls target backup schedules and retention. Preserve the application’s recovery requirements when replacing AWS-managed snapshots. The adapter does not translate OpenSearch Security configuration, PPL or notification/observability objects; these need target-native configuration or an application change.Sizing and performance
Choose shard layout, replicas, data tiers and memory for the application’s indexing and query workload. Published engine benchmarks describe their particular versions and datasets; they do not measure this adaptation. Measure the deployed application, including translated operations, when selecting capacity.On OCI
OCI Search with OpenSearch
OpenSearch managed by Oracle
Tensor9 provisions OCI Search with OpenSearch in the customer’s Oracle Cloud tenancy and configures the application to use its opensearch_fqdn endpoint. Document and search requests reach the managed cluster directly. Oracle operates the OpenSearch service.
