16 posts tagged with "opensearch"

Getting good write throughput from OpenSearch requires understanding three things: the refresh cycle, translog durability, and shard sizing. This post benchmarks bulk indexing with default and tuned settings on a live OpenSearch 2.19.1 cluster managed by FoundryDB. The cluster is a single-node tier-2 (2 CPU, 4 GB RAM), which is the smallest configuration available. Numbers from larger nodes will be better, but the ratios between default and tuned settings hold.

All commands use YOUR_OPENSEARCH_HOST and YOUR_PASSWORD as placeholders.

FoundryDB manages the full lifecycle of OpenSearch: VM provisioning, TLS certificates, DNS, and credentials. You get a production-ready cluster endpoint in about 6 minutes. This post covers provisioning via the API, fetching credentials, verifying TLS, and confirming cluster health.

All examples use confirmed output from OpenSearch 2.19.1 running on FoundryDB staging.

Retrieval-Augmented Generation (RAG) augments a language model's response by first retrieving relevant context from a database, then passing that context into the prompt. OpenSearch is a natural fit for the retrieval step: it runs the embedding model internally, stores the vectors, and returns ranked results in a single query. This post shows the retrieval step with real scores from a live OpenSearch 2.19.1 cluster managed by FoundryDB, and explains how to wire the retrieved chunks into a prompt and call an LLM.

This post uses a dedicated knowledge base index with 6 database documentation chunks, embedded using all-MiniLM-L6-v2 (384 dimensions). The retrieval, prompt assembly, and a complete prompt were all tested on a live FoundryDB cluster.

Keyword search breaks when users phrase queries differently from the words in your documents. Vector search fixes this by comparing meaning rather than tokens. This post walks through registering a sentence embedding model, building a k-NN index with an ingest pipeline, and running semantic queries against a FoundryDB-managed OpenSearch 2.19.1 cluster. All scores and outputs are from a real test run.

All commands use YOUR_OPENSEARCH_HOST and YOUR_PASSWORD as placeholders. Replace them with your cluster domain and app_user password from the FoundryDB dashboard.

OpenSearch index mappings are immutable once data is indexed. Changing a field type (for example, from text to keyword for a product SKU) or adding an analyzer to an existing field requires creating a new index and moving data into it. The challenge is doing this without taking your search API offline. The answer is aliases combined with the _reindex API. This post demonstrates the full pattern on a live OpenSearch 2.19.1 cluster managed by FoundryDB.

All commands use YOUR_OPENSEARCH_HOST and YOUR_PASSWORD as placeholders.

Every application eventually outgrows LIKE '%query%'. Once your product catalog, help center, or log pipeline crosses a few million documents, you need an inverted index, not a sequential scan. OpenSearch provides exactly that: full-text search with relevance scoring, custom analyzers, aggregations, and a visualization layer built in.

The hard part is running it. JVM heap tuning, cluster formation, TLS certificate management, shard rebalancing, and snapshot configuration turn a "quick search feature" into a permanent ops project. FoundryDB removes all of that. You get a managed OpenSearch 2.19 cluster with TLS, authentication, automated snapshots, and monitoring out of the box.

This guide walks through deploying OpenSearch on FoundryDB and building production-quality search: from provisioning to index design, full-text queries, custom analyzers, and aggregations.