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.

DigitalOcean Managed Databases is a popular starting point for teams that want hosted PostgreSQL, MySQL, MongoDB, or Valkey without managing infrastructure. It does the basics well: provisioning, automated backups, and TLS. But as your data platform matures, the limitations become clear. Four engines, minimal monitoring, no AI-oriented features, no pipeline templates, and no way to export metrics to your own observability stack. FoundryDB offers seven engines, built-in AI presets, predictive autoscaling, database forking, and seven metrics export destinations, all on European infrastructure.

Heroku wound down its free tier in November 2022, and since then the managed Postgres add-on has remained a solid but limited option. If you have been hitting walls with single-engine lock-in, basic monitoring dashboards, no point-in-time recovery on lower plans, and the lack of multi-node high availability, it may be time to move. FoundryDB gives you a full-featured PostgreSQL service (plus six other engines) with automated HA, PITR, predictive autoscaling, and EU-hosted infrastructure, all manageable from a single CLI.

PlanetScale removed its free tier in April 2024 and raised prices across the board, pushing many teams to re-evaluate their MySQL hosting. Beyond pricing, PlanetScale runs on Vitess, a sharding proxy that sits between your application and MySQL. While Vitess handles horizontal scaling well, it introduces compatibility quirks that can surprise you: no foreign key enforcement, limited support for certain joins, and behavior differences from native MySQL. If you want a standard MySQL experience with native replication, foreign keys, and no proxy layer, FoundryDB is a direct path forward.

Something fundamental shifted in how databases get created. In 2024, most database provisioning was triggered by a human clicking a button in a dashboard or running a CLI command. By early 2026, Neon reported that 80% of new databases on their platform were created by AI agents, not humans. The database is becoming infrastructure that agents provision, configure, and tear down as part of their workflows.

This changes what a managed database platform needs to provide. Agents do not use dashboards. They do not read documentation the way engineers do. They need fast, programmatic interfaces with predictable behavior. They need databases that spin up in seconds, clean themselves up when no longer needed, and integrate natively with agent frameworks.

We built FoundryDB's agent infrastructure to meet these requirements.

Most database dashboards give you a SQL editor and wish you luck. That works fine when you remember the exact name of the pg_stat_user_tables view or the difference between information_schema.TABLES in MySQL versus PostgreSQL. For everyone else, there is the AI Query Console.

FoundryDB's AI Query Console lets you type a question in plain English, translates it to a database-native SQL query using Claude, and executes it against your running service. The entire flow is read-only by design. You cannot accidentally drop a table by asking a question.