OpenSearch

Managed OpenSearch for full-text search and analytics, with single-node or multi-node high-availability clusters and automated backups.

Creating an OpenSearch instance

From the phase canvas, click + Service → Databases → OpenSearch, then Commit.

Attach OpenSearch from the add-on Connections list or the app Add-ons tab. Check the app Variables tab for the injected keys after you Commit. Your application can read the endpoint and credentials from the environment.

Adding OpenSearch from the Databases catalog and attaching it to the app injects OPENSEARCH_URL and OPENSEARCH_INDEX.

Connecting

OpenSearch exposes an HTTP REST API over TLS on port 9200. Use the internal hostname of the instance on the private network. Check Variables after attach — there is no guaranteed OPENSEARCH_URL injector today.

Internal endpoint (OPENSEARCH_URL)

https://user:password@[service-name]:9200

Because the endpoint is internal, it is reachable from services in the same project over private networking. Most OpenSearch and Elasticsearch client libraries accept this URL directly.

Browse and query with CloudBeaver

Every database add-on ships with CloudBeaver. Open with DB Beaver on the add-on's Overview starts a scoped session where you can browse tables, run SQL, and edit data in the browser.

Open with DB Beaver launches a scoped CloudBeaver session where the users table is browsed, a query runs, and the results appear.

Standard vs high availability

You choose the topology when creating the instance. Standard runs a single node and is a good fit for development and smaller workloads. High availability runs a multi-node cluster where each index has primary and replica shards spread across nodes, so the loss of a single node does not lose data or take the cluster offline.

	Standard	High availability
Nodes	Single node	Multiple nodes
Shard layout	Primary shards only	Primary and replica shards across nodes
Node loss	Cluster unavailable	Stays available, no data loss
Best for	Development and testing	Production workloads

Indexing and searching

OpenSearch speaks a JSON over HTTP API. The example below creates an index, indexes a single document, and runs a match query against OPENSEARCH_URL.

index-and-search.sh

# Create an index
curl -X PUT "$OPENSEARCH_URL/articles"

# Index a document
curl -X POST "$OPENSEARCH_URL/articles/_doc" \
  -H 'Content-Type: application/json' \
  -d '{ "title": "Hello OpenSearch", "body": "Full-text search made simple." }'

# Search the index
curl -X GET "$OPENSEARCH_URL/articles/_search" \
  -H 'Content-Type: application/json' \
  -d '{ "query": { "match": { "title": "OpenSearch" } } }'

Tip

Refreshing is near real time. If a freshly indexed document does not appear in search results immediately, allow a moment for the refresh interval, or use the refresh query parameter when indexing test data.

Backups

Every OpenSearch instance is protected by automated, encrypted backups that follow the platform backup policy. OpenSearch also supports snapshot repositories, so you can take and restore index snapshots through its native snapshot API when you need application-level control. See /docs/databases/backups for details on how backups are scheduled, encrypted, and restored.

Under the hood

OpenSearch is the open-source search and analytics engine forked from Elasticsearch. StackBlaze runs it through a Kubernetes operator with persistent volumes for index data, and high-availability clusters spread primary and replica shards across nodes so the cluster keeps serving reads and writes through a node failure.