Supported environments
- Akamai
- Azure
- DigitalOcean
- Google Cloud
- OCI
- Private Kubernetes
- Scaleway
How the backends compare
Each row compares a capability of OpenSearch Domain with its adaptation on each backend. A dash means this profile does not state the capability for that backend.Cloud Adapter
On Akamai, Azure, DigitalOcean, Google Cloud, Private Kubernetes, and Scaleway
OpenSearch
How it works
Tensor9 provisions OpenSearch in your Kubernetes cluster, through anOpenSearchCluster resource or a Helm chart, and points your application at its endpoint. Your OpenSearch client sends document and search requests straight to the cluster’s OpenSearch API; nothing from Tensor9 sits in between. You operate the cluster and its storage.
Engine and plugins
The cluster runs the OpenSearch engine with its bundled plugins, so the listed document, index, search, aggregation, ingest and scripting operations keep their OpenSearch APIs. The distribution includes k-NN vector search, SQL, PPL, Index State Management, Alerting, Anomaly Detection and ML Commons, and their_plugins APIs run on the cluster.
Match the engine and plugin versions to the ones your application uses on AWS. Two deployments of the same engine are not identical if their versions differ.
Topology and access
You define node pools with CPU, memory and PersistentVolume capacity. A dedicatedcluster_manager pool keeps the cluster quorum: use at least three eligible nodes and spread replicas across failure domains. (OpenSearch renamed the master role to cluster_manager in version 2.0.) Configure shard allocation and plan rolling upgrades for your version.
The OpenSearch Security plugin controls roles, role mappings and internal users, including SAML, OIDC or LDAP sign-in where supported, and document- or field-level access. You translate your AWS IAM-based access rules into this configuration.
Storage and backups
PersistentVolumes and their StorageClasses set disk capacity, IOPS and encryption. Availability depends on node placement, quorum and index replicas. Register a snapshot repository, and schedule snapshots and their retention with OpenSearch Snapshot Management (not the same feature as Elasticsearch Snapshot Lifecycle Management). An S3-compatible repository needs therepository-s3 plugin and the object store’s endpoint settings. Keep backups outside the cluster’s failure domain, and test a restore.
Limitations
- A managed uptime SLA is not available. The cluster is self-managed. Tensor9 provisions it and its endpoint, but adds no managed durability guarantee; availability is what your placement, quorum and replicas provide.
- AWS IAM access control is not supported. You must express access rules in the OpenSearch Security plugin’s roles, role mappings and users.
- Encryption behaves differently: AWS KMS key settings are not kept. Encryption at rest comes from the StorageClass of the PersistentVolumes, not from a domain’s AWS KMS key.
- Elasticsearch licensing APIs are not supported.
_licenseand_xpackare Elasticsearch endpoints, not OpenSearch APIs.
Other considerations
Before going live. Replace the bootstrap certificates and default credentials before you expose the cluster. Moving from AWS. The cluster starts empty. Restore a compatible snapshot or reindex from the source, then check index mappings and queries before cutover. Size shards, replicas and storage for your workload; shard sizes in the tens of gigabytes are a starting point to evaluate, not a fixed limit. What you operate. You run Kubernetes capacity, storage expansion, cluster health, upgrades and snapshots.On Azure
Azure Native Elastic
How it works
Your application keeps its OpenSearch client. Its requests go to a Tensor9 adapter, which translates the supported APIs and authentication and sends them to a managed Elasticsearch 8.x endpoint on Azure Native Elastic. Tensor9 creates the Elastic resource in the customer’s Azure tenant through the Azure Native integration. Elastic operates Elasticsearch, and the resource is bought and billed through the customer’s Azure subscription.
Requests and authentication
The adapter forwards the supported document, search, aggregation, index, cluster, ingest and scripting operations. It translates differences in requests and responses, such as the point-in-time path:_search/point_in_time becomes _pit. The adapter checks the AWS SigV4 signature on each request, then calls Elasticsearch with Elastic credentials or API keys. You configure backend permissions in Elastic’s security model.
Elasticsearch 8.x accepts compatible-with=7 headers for its earlier REST API. The adapter uses them where they apply, alongside its own translations. This does not make every OpenSearch request or client version work. Test your application’s queries, response parsing and client behavior against the listed operations. See Elastic’s API compatibility documentation.
Plugin APIs
OpenSearch and Elasticsearch have different plugin APIs. The adapter maps k-NN vector fields fromknn_vector to dense_vector and converts the query to Elasticsearch’s knn form. SQL requests move from _plugins/_sql to _sql, with the response fields translated. Index State Management (ISM) policies map to Elasticsearch Index Lifecycle Management (ILM) where their actions fit ILM’s phases.
Alerting, anomaly detection and machine learning map to Elasticsearch’s _watcher and _ml features. Some of these need a commercial Elastic subscription. The operations table shows which APIs are translated and which are not supported.
Deployment, security and availability
The Azure resource does not expose the deployment’s topology. You 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. 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 its high-availability conditions. The subscription also decides which commercial features you get, so choose topology and subscription together. Security uses Elastic’s own configuration, API keys and single sign-on, not OpenSearch Security roles. Document- and field-level security and other commercial features depend on the subscription you buy. The hosted offering’s subscription terms apply whatever the source-code license. Elastic added an AGPLv3 option for the free source portions in 2024; see its licensing FAQ.Limitations
- PPL is not supported. Elasticsearch has no PPL, and the adapter does not translate PPL requests. Replace them with an application change. - The OpenSearch Security API is not supported. OpenSearch Security configuration is not translated. Configure users, roles and permissions in Elastic’s security model instead. - Notifications and observability objects are not supported. They have no Elasticsearch equivalent. They need backend-native configuration or an application change. - ISM behaves differently: custom states and transitions are not mapped. ILM has fixed phases, so only ISM actions that fit those phases are mapped. - Snapshots behave differently: an OpenSearch snapshot does not restore into Elasticsearch. Backup schedules and retention use Elastic Snapshot Lifecycle Management, which has a different API from OpenSearch snapshots. - Some features need a commercial Elastic subscription. Parts of alerting, anomaly detection and machine learning, and document- and field-level security, depend on the subscription you buy. - The
_licenseand_xpackendpoints are not supported. They are Elasticsearch licensing APIs, not OpenSearch APIs, and are outside the mapping.
Other considerations
Before going live. Review mappings, analyzers and index settings before loading data. Check representative queries, including translated operations, before switching traffic. Moving from AWS. The deployment starts empty. Move data with a compatible remote reindex or a bulk export and import. Replace AWS-managed snapshots with Elastic Snapshot Lifecycle Management schedules and retention that meet your recovery requirements. Sizing. Choose shard layout, replicas, data tiers and memory for your indexing and query load. Published engine benchmarks describe their own versions and datasets; they do not measure this mapping. Measure your deployed application, including translated operations, when choosing 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’s OpenSearch or Elasticsearch client sends_bulk, _search and other OpenSearch REST calls to an Amazon OpenSearch domain. On DigitalOcean, Tensor9 creates a DigitalOcean Managed OpenSearch cluster (a digitalocean_database_cluster with engine = "opensearch") when it builds the deployment, and points your domain’s endpoint at the cluster’s host.
Your app keeps the same clients and request formats. Nothing from Tensor9 handles the requests, so every index and query runs on DigitalOcean’s OpenSearch engine at the cluster’s own latency. DigitalOcean operates the cluster: it provisions the nodes and runs backups, failover and version upgrades. The cluster starts empty; your data moves separately.
Your OpenSearch domain becomes a DigitalOcean Managed OpenSearch cluster, and your clients connect to it directly.
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 as your AWS domain. Index and document operations (_doc, _bulk), search and aggregations (_search), mappings, ingest and Painless scripting behave as they do today.
The plugin APIs under _plugins/* are the 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.
One vector detail affects sizing: DigitalOcean offers no disk-resident approximate-nearest-neighbor index, so vector search is limited by node RAM. Size the cluster for large HNSW graphs accordingly.
The core index, search and aggregation API is the same, and the _plugins/* features are the plugins bundled in DigitalOcean’s 2.19 distribution.
What changes: operational ownership
DigitalOcean operates the cluster, as AWS operates your domain today. It provisions the nodes and runs 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 follow DigitalOcean’s control panel and API. You choose the plan class (Basic, General Purpose or Memory-Optimized), the node count and the storage size. There is no separate dedicated-master tier; add a standby node when you want failover. With nothing in between, the cluster’s performance is its own, and your own monitoring reports it.
DigitalOcean runs backups, failover and upgrades; you choose the plan, node count and storage size.
Network and access on DigitalOcean
The cluster can sit in a DigitalOcean VPC and be reached over a private network. Who may connect is set 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 cluster, and with trusted sources on, some DigitalOcean log-forwarding paths are unavailable. Inside the cluster, DigitalOcean provides a singledoadmin user. The OpenSearch Security plugin is present, but DigitalOcean does not offer creating more users or roles through its control panel or API. If your AWS setup uses fine-grained, per-index or per-user access control, you rebuild it around the one doadmin credential.
Connections are encrypted in transit with SSL, and data is encrypted at rest with LUKS, always on, with no customer-managed key option.
A trusted-sources allow-list inside a VPC decides who can connect, and the cluster has a single doadmin user.
Limitations
The OpenSearch API stays the same. Access control, backups, networking and sizing differ. Where DigitalOcean Managed OpenSearch and Amazon OpenSearch differ- Fine-grained access control is not supported. Per-index and per-user roles have no counterpart: DigitalOcean provides only the
doadminuser and does not offer managing more OpenSearch users or roles. - Backups behave differently. Automated backups run 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.
- Security groups and VPC endpoint policies are not supported. Access is an allow-list of IP addresses and resources (up to 2,000 entries) inside a DigitalOcean VPC. Cloud Firewalls do not apply, and some log-forwarding paths are unavailable while trusted sources are on.
- Vector search behaves differently: it is limited by memory: k-NN and Neural search are bundled, but there is no disk-resident ANN index, so large HNSW graphs must fit in node RAM.
- Customer-managed encryption keys are not supported. Data is encrypted at rest with LUKS, always on, using DigitalOcean-managed keys.
- Sizing behaves differently. Clusters are sized by plan (Basic: 1 or 3 nodes; General Purpose and Memory-Optimized: 1, 3, 6, 9 or 15) with managed storage. AWS instance types and EBS limits do not map one to one.
- The SLA behaves differently: it covers Managed Databases generally. DigitalOcean’s Managed Databases SLA is 99.95% monthly uptime with a standby node and 99.5% without. It does not name OpenSearch.
Other considerations
What Tensor9 maps at build time. Tensor9 mapsengine_version to a DigitalOcean major version, cluster_config.instance_type to a size, and instance_count to the node count (1 if unset). Settings with no DigitalOcean equivalent are dropped and reported as warnings: the dedicated-master tier, a separate EBS volume size (storage follows the node size), fine-grained access control, a customer-managed key, node-to-node encryption, zone awareness, vpc_options, endpoint options and log publishing. A domain declared with count or for_each stops the build with an error.
Credentials. DigitalOcean creates the cluster’s credentials; none are written into the generated Terraform.
Moving from AWS. The cluster starts empty and indices are not copied. Restore from a snapshot or reindex from the source, and check versions and capacity before switching traffic.
On DigitalOcean and Scaleway
Lucenia (self-hosted)
How it works
On AWS, your app’s OpenSearch or Elasticsearch client calls an Amazon OpenSearch domain over the OpenSearch REST API, with_bulk, _search and the rest. In the target cloud, Tensor9 deploys a self-hosted Lucenia cluster on Kubernetes with the Lucenia Helm chart, and points your client’s endpoint at it when the product is built.
Lucenia offers 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: every index and query call goes directly to the Lucenia cluster, at its own latency.
Your clients connect straight to a self-hosted Lucenia cluster on Kubernetes, with no proxy in between.
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. Its API tracks roughly OpenSearch 2.18. Your core client calls (_doc, _bulk, _search, mappings, aggregations) work as they do today. Vector search is confirmed: k-NN with Lucene-native HNSW, IVF and Faiss, plus hybrid BM25 and vector queries. Lucenia is at an early 0.x version (0.11.1 at the current release). It is a young engine to adopt deliberately, not a generally available managed service like the cloud providers’ offerings.
Lucenia is a separate engine; its compatible REST API is what keeps your clients working.
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, and hybrid BM25 and vector queries run on the Lucene 10.4 core. The other OpenSearch_plugins/* features are unverified. SQL and PPL, Index State Management, Alerting, Anomaly Detection and ML Commons have no published per-plugin compatibility list for Lucenia. Check the specific APIs your app calls against your Lucenia version before you depend on them. Lucenia’s own performance and cost claims publish no method, so this page does not cite them.
Core and vector search are confirmed; the other plugins are unverified, so check them first.
You operate the cluster
On the AWS domain, AWS ran high availability, version upgrades, daily snapshots and fine-grained access control under an 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. You own version upgrades on an early 0.x project, where releases can move quickly and upgrade paths are still maturing. Security is configured again, not inherited. The access control AWS applied to the domain becomes Lucenia’s own security configuration (its SSPL security component), which you set up separately. You set the initial admin password withLUCENIA_INITIAL_ADMIN_PASSWORD. No provider offers an availability SLA: the cluster’s uptime depends on how you run it.
What AWS ran for the domain becomes yours to run, and no provider offers an availability SLA.
Limitations
Your existing clients use Lucenia’s compatible REST API. Review these differences before you choose this backend. Where an AWS OpenSearch domain and self-hosted Lucenia differ- The engine behaves differently: Lucenia is not the OpenSearch codebase. It is a fork of OpenSearch 2.14 on Apache Lucene 10.4. Your clients rely on its compatible REST API, but it is a separate project with its own release schedule and its own bugs.
- Plugins other than k-NN are not verified. SQL, PPL, ISM, Alerting, Anomaly Detection and ML Commons have no published compatibility list for Lucenia. You must confirm each API your app calls before cutover; do not assume the domain’s plugin behavior.
- Maturity behaves differently: Lucenia is an early 0.x release. It is at
0.11.1. Tooling, client testing, long-term support and upgrade stability are less established than for a generally available managed service. Weigh that against the workload’s risk tolerance. - An availability SLA is not offered. The cluster runs on your Kubernetes, so no provider guarantees uptime. A separate managed Lucenia Cloud exists, but it is not this self-hosted backend.
- You must replace the domain’s managed features. Daily snapshots, fine-grained access control, and AWS instance families and EBS limits are not available. You size Lucenia with your own node pools and storage (
persistence.size,storageClass) and secure it through its own model. - You must review the SSPL license. Lucenia is dual-licensed Apache-2.0 and SSPL. The SSPL terms matter if you would ever offer Lucenia as a service to third parties, so check the license against your intended use.
Other considerations
Moving from AWS. The cluster starts empty; indices are not copied automatically. Restore from a snapshot or reindex from the source before you move traffic. Before going live. Test the plugin APIs your app calls, and the Lucenia version you will run, before switching traffic. Plan how you will apply upgrades, since 0.x releases can move quickly. What to monitor. Latency and throughput are the cluster’s own, and your monitoring reports them; no provider dashboard or SLA covers this cluster.On DigitalOcean and Google Cloud
Elastic Cloud (managed)
How it works
Your application keeps its OpenSearch client. Its requests go to a Tensor9 adapter, which translates the supported APIs and authentication and sends them to an Elastic Cloud Hosted deployment running Elasticsearch 8.x. Tensor9 provisions the deployment as anec_deployment resource in your Google Cloud environment. Elastic operates Elasticsearch and Kibana; you choose the deployment configuration.
Requests and authentication
The adapter forwards the supported document, search, aggregation, index, cluster, ingest and scripting operations, translating request and response differences. For example, the point-in-time path_search/point_in_time becomes _pit. The adapter checks AWS SigV4 signatures; its requests to Elasticsearch use Elastic credentials or API keys. You configure backend permissions in Elastic’s security model.
Elasticsearch 8.x accepts compatible-with=7 headers for its earlier REST API, and the adapter uses them where they apply. This does not make every OpenSearch request or client version compatible. Check your queries, response parsing and client behavior against the listed operations. See Elastic’s API compatibility documentation.
Plugin features
OpenSearch and Elasticsearch have different plugin APIs, so the adapter translates them: - k-NN.knn_vector mappings become dense_vector, and queries become Elasticsearch’s knn form. - SQL. Requests to _plugins/_sql go to _sql, with response fields translated. - Index State Management. Policies map to Elasticsearch Index Lifecycle Management (ILM) where their actions fit. - Alerting, anomaly detection and machine learning. These map to Elasticsearch _watcher and _ml. Some of them need a commercial Elastic subscription.
Deployment, availability and security
Theec_deployment resource exposes hot, warm, cold and frozen tiers, instance size, one to three availability zones, and autoscaling per tier. Storage comes bundled at the selected tier’s disk-to-memory ratio. 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 its high-availability conditions. Choose topology and subscription together.
Access control uses Elastic’s security configuration, API keys and single sign-on, not OpenSearch Security roles. Document- and field-level security and other commercial features depend on the subscription you buy. The hosted offering’s subscription terms apply regardless of the source-code license. Elastic added an AGPLv3 option for the free source portions in 2024; see its licensing FAQ.
Limitations
- Some OpenSearch APIs are not supported. PPL, the OpenSearch Security API, notifications and observability objects are outside the mapping. They need Elastic-native configuration or a change in your application.
- Index State Management behaves differently: custom states are not kept. ILM has fixed phases, so custom ISM states and transitions cannot be represented and do not round-trip.
- Restoring OpenSearch snapshots is not a supported migration path. Do not assume an OpenSearch snapshot restores into Elasticsearch across the engine fork. Move data with a reindex or bulk import instead.
- Elasticsearch licensing APIs are not supported.
_licenseand_xpackare not OpenSearch APIs and are not part of the mapping.
Other considerations
Moving from AWS. The deployment starts empty. Move data with a compatible remote reindex or a bulk export and import. Review mappings, analyzers and index settings before loading data, and test representative queries before you switch traffic. Backups. Elastic Snapshot Lifecycle Management sets backup schedules and retention. Make sure it meets the recovery requirements you had with AWS-managed snapshots. Sizing. Choose shard layout, replicas, data tiers and memory for your indexing and query load. Published engine benchmarks describe their own versions and datasets, not this mapping. Measure your deployed application, including translated operations, when choosing capacity.On OCI
OCI Search with OpenSearch
How it works
Your application keeps its OpenSearch client and requests. Tensor9 provisions OCI Search with OpenSearch in the customer’s Oracle Cloud tenancy and points the application at the cluster’sopensearch_fqdn endpoint. Document and search requests go straight to the managed cluster; Tensor9 is not in the request path. Oracle operates the OpenSearch service.
Engine and plugins
OCI runs OpenSearch itself, not a fork. The listed core REST operations and the supported plugins use the native OpenSearch APIs, including k-NN, SQL/PPL, Index State Management, Alerting, Anomaly Detection, ML Commons, Neural Search and Security Analytics. OCI documents versions 2.11, 2.15, 2.18, 2.19.1, 3.2 and 3.6. Match the engine and plugin versions to your application before migrating. The same engine on another provider still needs a version-compatibility review; it does not guarantee identical behaviour for every request.Topology and security
You size the data, leader and OpenSearch Dashboards nodes, with optional coordinator, machine-learning and search tiers. The cluster runs in the customer’s VCN and subnet. Oracle manages the software and spreads data nodes across availability domains. Access control uses the OpenSearch Security plugin, withsecurity_mode set to ENFORCING and a master user. It supports SAML, LDAP and OIDC sign-in, and document- and field-level security on supported versions.
Limitations
Where Amazon OpenSearch Service and OCI differ- AWS IAM access policies are not supported. Domain
access_policiesdo not apply directly. On OCI, access control goes through the Security plugin described above. - Customer-managed encryption keys are not supported. OCI manages storage encryption, and this mapping has no per-domain AWS KMS key setting.
- Elasticsearch
_licenseand_xpackendpoints are not supported. They are not part of OpenSearch. - Backups behave differently: OCI keeps daily backups for 14 days. You cannot change that schedule or retention. For other recovery points, use the Snapshot API with an Object Storage repository in the customer tenancy.
- Availability behaves differently: OCI states a 99.9% objective, not a contractual SLA. Node placement and replicas provide high availability. Check the current OCI service terms for the customer deployment.
- AWS sizing settings are not kept. The service uses Oracle compute and storage shapes, with the limits listed in the comparison. AWS instance families, EBS limits and UltraWarm settings are not interchangeable with them.
Other considerations
Before going live. Set up your recovery destinations and test a restore. Measure your workload on the chosen topology, and keep enough storage and replica capacity. Moving from AWS. The new cluster starts empty; OCI does not import the AWS domain’s indexes. Restore a compatible snapshot through a registered repository, or reindex from the source. Check mappings, analyzers, queries and the Security plugin configuration before you switch the endpoint.On Scaleway
Scaleway Cloud Essentials for OpenSearch
Install and run
The documentation and SLAs are public. Downloading and running the Cloud Adapter binary requires an entitled customer account. SetT9_API_KEY as described in Install and Authenticate, then list the adapters your account may use with this origin: