> ## Documentation Index > Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt > Use this file to discover all available pages before exploring further. # Trade-offs in AWS OpenSearch > Choose an OpenSearch adapter by engine behavior, plugins, relevance, recovery and operating responsibility. An OpenSearch service adapter is a directed choice: AWS OpenSearch to a particular target service. Compare both the search engine and who operates it. Managed versus customer-operated is only one axis. An OpenSearch engine and an Elasticsearch-family backend also differ in plugin APIs, lifecycle controls and request behavior. For native OpenSearch targets, the application normally connects to the target's OpenSearch REST endpoint. An IAM-signing client can require an authentication layer even when search requests need no translation. For Elastic Cloud or Azure Native Elastic, the directed adapter translates the supported OpenSearch operations to the Elasticsearch backend. Do not replace the application's search endpoint with an AWS management endpoint and expect queries to follow it. ## General trade-offs Choose the target environment first, then compare its documented services. The [service catalog](/cloud-adapter/service-catalog/aws/databases-storage/opensearch-domain) distinguishes native OpenSearch, translated Elasticsearch-family targets and a retained AWS domain. These choices do not all put the search data in the same location, even when they appear under the same application environment. ### Behavior before capacity | Dimension | Evidence to collect | | ------------------------------ | -------------------------------------------------------------------------------------------- | | Mappings and analyzers | Representative documents, tokenization and exact expected matches/exclusions | | Query and aggregation behavior | Fixed result IDs, bucket counts, pagination and business-required ordering | | Plugins | The exact PPL, SQL, vector, security, alerting or lifecycle operations your application uses | | Index visibility | What the application promises after an acknowledged write and how it waits for refresh | | Identity | Authorized and rejected requests using the real application authentication path | | Recovery | A restored index with the required contents, mappings, roles and usable endpoints | | Operations | Who owns disk pressure, upgrades, shard allocation, backups and incident response | An HTTP 200 response establishes little about search quality. A query can succeed yet use a different analyzer or return a different top result. Separate required ordering from acceptable relevance variation; ties should have a defined treatment in test fixtures. Select the adapter at the deployment or index-family architecture boundary. Changing its backend is a migration, not a per-query load-balancing setting. Independent index families can have different requirements, but each still needs a coherent write, read and recovery path. ### Operating and migration responsibilities | Responsibility | Managed target | Operated cluster | | ---------------------------------------------- | ----------------------------------------------- | --------------------------------------------- | | Engine maintenance | Provider within its product contract | Your platform/search team | | Mappings, relevance and ingest correctness | Your search/application team | Your search/application team | | Capacity and data retention | Your team configures and verifies | Your team, including node/storage operation | | Security and recovery acceptance | Shared provider controls and your access policy | Your team across cluster, storage and clients | | Adapter-owned translation/authentication state | Deployment operator where that path is used | Deployment operator where that path is used | Record the chosen directed adapter, engine version, required operations, authentication mode, representative fixture results, migration catch-up method and rollback boundary. Include expected cost during rebuild and recovery, not only steady-state node cost. ## Google Cloud ### Elastic Cloud or operated OpenSearch | Backend | Strengths and workload fit | Costs and constraints to accept | | ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | | Elastic Cloud | Provider-operated Elasticsearch with a directed translation contract for supported OpenSearch requests; consider it for document search whose APIs fit that contract | Plugin namespaces, lifecycle policies, security APIs and licensing differ; confirm where the actual deployment and snapshots reside | | OpenSearch on Kubernetes | Native OpenSearch APIs and control of the installed engine/plugins; consider it when those controls are required | Your team operates shards, volumes, security, backups and upgrades, including capacity during reindexing | A product index using bulk ingestion, filtered queries and aggregations can compare both with the same corpus. A PPL-dependent workflow cannot infer support from Elasticsearch's separate query languages. Check the [Elastic Cloud profile](/cloud-adapter/service-catalog/aws/databases-storage/opensearch-domain#elastic-cloud-managed) and [operated OpenSearch profile](/cloud-adapter/service-catalog/aws/databases-storage/opensearch-domain#opensearch) before testing load. Hold document contents, analyzers and query fixtures fixed. Measure ongoing ingestion together with search, then rebuild a replacement index while queries continue. A managed service reduces cluster-operation duties; it does not own the application's relevance criteria or the catch-up needed before moving readers. ## Microsoft Azure ### Azure Native Elastic or operated OpenSearch Azure Native Elastic supplies a provider-operated Elasticsearch backend through the documented translation mapping. Operated OpenSearch retains the installed OpenSearch engine and its plugin APIs with your team owning cluster operation. The decision depends on the required operations, not whether both products can return an HTTP success for a simple query. ### Workload example: plugin-heavy analytics An operations application depends on specific PPL queries, lifecycle transitions and vector-ranking behavior. Azure is required, with customer-operated Kubernetes allowed. Compare OpenSearch on that cluster against Azure Native Elastic through its directed translating adapter. The [Azure Native Elastic mapping](/cloud-adapter/service-catalog/aws/databases-storage/opensearch-domain#on-azure) defines which plugin and query operations the translating adapter covers. The installed engine and plugins define the operated OpenSearch behavior. Check the actual required operations against both contracts: shared ancestry between OpenSearch and Elasticsearch does not establish equivalence for plugin namespaces or responses. A required operation outside a candidate's contract excludes that candidate for this workflow. For a workload within the translated contract, Azure Native Elastic can reduce engine-operation work. The adapter handles the supported request/response differences; the application still needs to qualify query results and lifecycle behavior. For example, mapping a supported vector query is not evidence that every PPL or security-plugin workflow carries over. The operated alternative gives the platform team control over the engine image and plugins. It also assigns that team shard placement, disk capacity, certificate rotation, security configuration, backup storage and tested upgrades. A plugin release should be tested against stored data and query fixtures before it reaches a customer's cluster. **Comparison record:** Azure; exact plugin behavior and query results; operated OpenSearch versus the Azure Native Elastic adapter. Record covered operations and fixture results for each, including unsupported requirements. Native plugin execution exposes engine/plugin configuration and its maintenance obligations; translated execution uses the mapped contract and provider-operated engine. Select the cluster/image and directed mapping as a deployment decision, with explicit operation and recovery owners. Do not tune around a hard query-contract mismatch. For vector search, preserve the embedding model, dimensions, distance definition and test vectors across the comparison. Measure recall and business-required ordering, not merely whether the result contains some documents. For lifecycle policies, shorten time intervals only in a test fixture and observe actual rollover/retention outcomes. Migration requires a new target index with validated mappings and pipelines. Transfer authoritative documents, reproduce the relevant policy state and compare lifecycle and query outcomes. A snapshot accepted by one engine/version is not a general cross-family transfer guarantee. Retain a document-based rebuild path and account for its duration. ## DigitalOcean ### Managed, operated and retained-service choices | Backend | Strengths and workload fit | Costs and constraints to accept | | ------------------------------- | ---------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | DigitalOcean Managed OpenSearch | Native OpenSearch with provider-operated maintenance; useful when its versions and topology fit the workload | Provider-defined capacity, access and backup controls replace AWS domain settings | | Operated OpenSearch | Chosen engine/plugin versions and topology when those controls matter | Your team owns cluster security, shards, storage and recovery | | Lucenia | Customer-operated search engine for a workload matching its documented OpenSearch-compatible and vector behavior | Do not infer full plugin equivalence; qualify the required queries and own image, licensing and cluster maintenance | | Elastic Cloud | Provider-operated Elasticsearch for queries within its translating profile | Different plugin/security/lifecycle contracts; approve the actual hosting location and network path rather than assuming data is in DigitalOcean | | Retained AWS OpenSearch domain | Preserves the existing managed engine and domain state when an AWS dependency is allowed | Search data remains in AWS; connectivity, latency, egress and residency remain cross-cloud concerns | The [retained-domain profile](/cloud-adapter/service-catalog/aws/databases-storage/opensearch-domain#opensearch-domain) means that the application can run in DigitalOcean while search stays in AWS. It is not a DigitalOcean-managed replacement. Compare [Lucenia](/cloud-adapter/service-catalog/aws/databases-storage/opensearch-domain#lucenia-self-hosted) and [Elastic Cloud](/cloud-adapter/service-catalog/aws/databases-storage/opensearch-domain#elastic-cloud-managed) only after their placement and required API contracts fit. ### Workload example: product search A retailer indexes product titles, availability and categories. PostgreSQL remains authoritative. The workload uses document CRUD, bulk indexing, conventional text analysis and filtered aggregations. DigitalOcean is required and private Kubernetes is permitted. Compare DigitalOcean Managed OpenSearch with customer-operated OpenSearch on that cluster. Both use a native OpenSearch engine; compare their exact versions and enabled features. DigitalOcean owns the managed service's engine operation, while your platform team owns that work for the operated cluster. In both cases, your team owns mappings, analyzers, ingest correctness, result quality and the capacity needed during an index rebuild. The [DigitalOcean mapping](/cloud-adapter/service-catalog/aws/databases-storage/opensearch-domain#digitalocean-managed-opensearch) is the authority for available engine versions, topology, access and backups. Do not assume that AWS dedicated-master tiers, snapshot controls or node-size labels translate literally. Include indexing and queries together when measuring tail latency: an idle search benchmark misses contention from the nightly catalog refresh. **Comparison record:** DigitalOcean; correct product filters/facets and bounded query latency; managed versus operated OpenSearch. Record the provider's version/topology controls alongside the operated cluster's configurable versions and topology. The search team owns data and relevance on both; engine upgrades and recovery belong to the provider or named platform team respectively. Run the same fixed query probe and concurrent ingest/search test on each candidate. A mandatory engine/plugin version unavailable on a candidate excludes it for this workload. Selection is at deployment scope. Budget for replicas, snapshots, ingest work and two index generations during migration. A cheaper small cluster that cannot hold the old and replacement indexes together also requires a different release procedure. Reindex from the authoritative source, reconcile updates arriving during the copy and compare results before moving readers. Keep the source index for a defined cutback interval. After ingest moves, returning readers to the old index requires catching it up; an endpoint change alone cannot recover documents it never received. ### Run a query-correctness probe This small fixture tests document matching, filtering, aggregations and deterministic ordering. It intentionally does not claim to test relevance scoring, plugins, performance or recovery. Extend it with the application's analyzers and golden queries before accepting an adapter. Provision a test destination using the selected deployment. For native OpenSearch, connect directly to its REST endpoint; no local API-translation process is needed. For a translating adapter, use the installed origin-facing search endpoint and its documented identity. Keep TLS certificate and hostname verification enabled. The script below uses a username/password test identity with permission to create, query and delete only `tradeoff-products-check`. If your application uses IAM signing, repeat the same fixture with the actual signing client and configured authentication path as a separate acceptance requirement. Passing basic authentication does not establish IAM behavior. Run `python3 -m pip install requests`. Save the following as `search-choice-check.py`, replace the hostname with the disposable endpoint, and run `python3 search-choice-check.py`. The index name is literal and the script refuses to overwrite an existing index. Credentials are prompted rather than written into shell history. ```python theme={null} import getpass import requests session = requests.Session() session.auth = (input("Test username: "), getpass.getpass("Test password: ")) base = "https://search-test.example.com" index = "tradeoff-products-check" def call(method, path, body=None): response = session.request(method, base + path, json=body, timeout=30) response.raise_for_status() return response.json() existing = session.head(base + "/" + index, timeout=30) if existing.status_code != 404: raise RuntimeError("Index exists or existence check failed; do not overwrite") call("PUT", "/" + index, { "settings": {"number_of_shards": 1, "number_of_replicas": 0}, "mappings": {"properties": { "sku": {"type": "keyword"}, "title": {"type": "text", "analyzer": "standard"}, "category": {"type": "keyword"}, "available": {"type": "boolean"} }} }) try: documents = [ {"sku": "p-1", "title": "Red shoes", "category": "shoes", "available": True}, {"sku": "p-2", "title": "RED hat", "category": "hats", "available": True}, {"sku": "p-3", "title": "Red boots", "category": "shoes", "available": False}, {"sku": "p-4", "title": "Blue shoes", "category": "shoes", "available": True}, ] for document in documents: call("PUT", "/" + index + "/_doc/" + document["sku"], document) call("POST", "/" + index + "/_refresh") result = call("POST", "/" + index + "/_search", { "query": {"bool": { "must": [{"match": {"title": "red"}}], "filter": [{"term": {"available": True}}] }}, "sort": [{"sku": "asc"}], "aggs": {"categories": {"terms": {"field": "category"}}} }) if result.get("timed_out") or result["_shards"]["failed"]: raise RuntimeError("Incomplete search response") ids = [hit["_id"] for hit in result["hits"]["hits"]] counts = {b["key"]: b["doc_count"] for b in result["aggregations"]["categories"]["buckets"]} if ids != ["p-1", "p-2"] or counts != {"hats": 1, "shoes": 1}: raise RuntimeError({"unexpected_ids": ids, "unexpected_counts": counts}) print({"ids": ids, "category_counts": counts, "fixture": "passed"}) finally: call("DELETE", "/" + index) session.close() ``` Zero replicas is deliberate for this disposable correctness fixture, not a production availability recommendation. The explicit refresh establishes when the fixture becomes searchable; do not add it to every production write merely to make a benchmark easier. See the [OpenSearch refresh contract](https://docs.opensearch.org/latest/api-reference/index-apis/refresh/). Expected: exactly `p-1` and `p-2`, ordered by SKU, with one hat and one shoe. `p-3` is excluded by availability and `p-4` by its title. Run the same fixture on the origin's isolated test endpoint and then the destination. A mismatch stops acceptance of this path. Capture the query, mapping, nonsecret response and engine/profile identity. Check analyzer, filter, mapping and translation behavior before load testing. Where a request traverses a translating adapter, [Explain](/cloud-adapter/debugging/explain) can supplement this evidence; native query results remain the correctness test. Add the real application's relevance fixtures, pagination, bulk-item failure checks and plugin workflows. Exercise authorization and snapshot recovery separately. The script deletes only its new index; if it was interrupted, inspect `tradeoff-products-check` before removing it. Retire dedicated test infrastructure and unwanted retained snapshots through their owning deployment workflows. ## OCI ### OCI Search with OpenSearch The documented backend is OCI Search with OpenSearch. Oracle operates the runtime; your teams retain responsibility for index design, allowed principals, permitted transfer paths, retention and recovery acceptance. This can fit a workload requiring an Oracle-operated OpenSearch service when the supported engine, networking and topology controls meet the application requirements. For regulated records, inspect the [OCI mapping](/cloud-adapter/service-catalog/aws/databases-storage/opensearch-domain#on-oci), then prove private access and recovery in an approved region. A private endpoint does not establish where snapshots, exported data or administrative access reside. The mapping's topology and backup controls must fit the workload rather than being assumed equivalent to the AWS domain. Measure time to usable application queries after restoration, including roles and templates. Test a denied request and restore into an isolated approved endpoint. Record where snapshots live and which identity can read them; a backup that the permitted operator cannot restore does not meet the recovery requirement. During migration, keep the source, transfer staging and destination inside the allowed locations. Test cutback permissions before revoking source access and include retained snapshots and duplicate storage in the cleanup record. ## Scaleway ### Cloud Essentials, OpenSearch or Lucenia | Backend | Strengths and workload fit | Costs and constraints to accept | | ---------------------------------------- | ------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | Scaleway Cloud Essentials for OpenSearch | Provider-operated native search for workloads fitting the service's engine and resource options | Confirm engine/version fit, supported node and storage sizes, private networking and backup behavior; AWS topology settings do not transfer literally | | Operated OpenSearch | Control of native engine/plugins and deployment topology | Your team owns persistent storage, shard allocation, upgrades, access and snapshot recovery | | Lucenia | A customer-operated option for applications whose search and vector requirements fit its profile | Qualify exact plugin and relevance behavior rather than assuming complete OpenSearch equivalence; own the engine deployment | For a catalog with a source-of-truth database, compare reindex duration and search results on all eligible candidates. For an index containing irreplaceable data, require a tested restore procedure before measuring cost. A need for a specific plugin/version can narrow the candidates before resource sizing begins. The [Scaleway managed profile](/cloud-adapter/service-catalog/aws/databases-storage/opensearch-domain#scaleway-cloud-essentials-for-opensearch) calls out networking and engine constraints. Attach the approved private network before treating that deployment as private. On operated engines, verify equivalent access controls yourself. Compare peak storage during rebuild, not only the final index size. ## Akamai ### Operated OpenSearch The documented backend is OpenSearch on the target Kubernetes cluster. It gives the operating team control of engine/plugin versions and shard topology. That suits an application with required native plugin behavior when the team can maintain the cluster, but transfers volume, upgrade, certificate and snapshot duties to that team. Before cutover, replay the application's query fixtures, test a denied request and restore representative indexes. Specify who can replace a failed volume and rebuild missing shards. Engine control does not itself supply fault-domain placement or recovery capacity. Use the [operated OpenSearch mapping](/cloud-adapter/service-catalog/aws/databases-storage/opensearch-domain#opensearch) for the supported contract. ## Private Kubernetes ### Operated OpenSearch An OpenSearch cluster inside the customer's private Kubernetes environment can satisfy a local-execution requirement while retaining native search APIs. The customer must provide capacity and an operator for storage, shard allocation, access, backup scheduling and upgrades. Data residency includes snapshot repositories and transfer staging as well as live volumes. For shared clusters, qualify search latency during competing workloads and a node failure. Reserve space for both index generations during a rebuild and test restoration using the access available to the actual recovery operator. Use the query-correctness fixture above for basic matching, then add the application's required plugins and golden relevance queries. ## Next steps Record the chosen directed adapter, actual data location, engine version, required operations, query results and recovery owner. Configure the selected deployment with [Tuning AWS OpenSearch](/cloud-adapter/tuning/aws-opensearch).