This guide covers migrating all three of the most common DigitalOcean database engines (PostgreSQL, MySQL, and MongoDB) to FoundryDB. Each section is self-contained, so you can follow just the one relevant to your stack or migrate multiple databases in parallel.

Why Migrate from DigitalOcean?​

DigitalOcean's managed database service has served many teams as a reliable first step, but production workloads often demand more:

• Four engines only. DigitalOcean offers PostgreSQL, MySQL, MongoDB, and Valkey. If you need Kafka for event streaming, OpenSearch for full-text search, or Babelfish for SQL Server wire compatibility, you need a separate provider.
• Basic monitoring. The DigitalOcean dashboard shows CPU, memory, disk, and connection metrics. There are no query-level analytics, no slow query breakdowns, no custom alerting thresholds, and no way to export metrics to Grafana, Datadog, or Prometheus.
• No AI features. There are no pgvector presets, no embedding pipeline templates, no AI-assisted query optimization, and no built-in support for RAG architectures.
• No database forking. Creating a copy of a production database for testing or analytics requires manual dump-and-restore. FoundryDB supports instant forking from any backup or point-in-time snapshot.
• No predictive autoscaling. DigitalOcean requires manual scaling decisions. You monitor metrics, decide when to resize, and trigger the operation yourself.
• Limited connection pooling. DigitalOcean offers basic built-in connection pooling for PostgreSQL but lacks the advanced query routing and read/write splitting that ProxySQL (MySQL) or PgBouncer (PostgreSQL) provide.

Prerequisites​

For all migrations below, you need:

• A FoundryDB account at foundrydb.com
• The fdb CLI installed (brew install foundrydb/tap/fdb or download from the dashboard)
• Access to your DigitalOcean database credentials (available in the DO dashboard under Databases > Connection Details)

Engine-specific tools:

• PostgreSQL: pg_dump and pg_restore (included with any PostgreSQL client)
• MySQL: mysqldump and mysql client
• MongoDB: mongodump and mongorestore (included with MongoDB Database Tools)

PostgreSQL Migration​

Export from DigitalOcean​

Get your DigitalOcean PostgreSQL connection details from the dashboard, then run pg_dump:

pg_dump \
  "postgresql://doadmin:YOUR_DO_PASSWORD@db-postgresql-sto1-12345-do-user.b.db.ondigitalocean.com:25060/defaultdb?sslmode=require" \
  --format=custom \
  --no-owner \
  --no-privileges \
  --verbose \
  -f digitalocean-pg.dump

The custom format produces a compressed binary dump that supports parallel restore and selective table import.

Create on FoundryDB​

fdb create \
  --database-type postgresql \
  --version 17 \
  --plan-name tier-2 \
  --storage-size-gb 50 \
  --name my-pg-db \
  --zone se-sto1

Wait for the service to reach Running status:

fdb status my-pg-db

Import​

Retrieve your FoundryDB credentials and restore:

fdb connect my-pg-db --info

pg_restore \
  --host my-pg-db-abc123.db.foundrydb.com \
  --port 5432 \
  --username app_user \
  --dbname defaultdb \
  --no-owner \
  --no-privileges \
  --jobs 4 \
  --verbose \
  digitalocean-pg.dump

Verify​

fdb connect my-pg-db

-- Compare table counts
SELECT count(*) FROM information_schema.tables WHERE table_schema = 'public';

-- Check row counts
SELECT schemaname, relname, n_live_tup
FROM pg_stat_user_tables
ORDER BY n_live_tup DESC LIMIT 20;

-- Verify extensions
SELECT extname, extversion FROM pg_extension;

MySQL Migration​

Export from DigitalOcean​

Get your DigitalOcean MySQL connection details, then dump:

mysqldump \
  -h db-mysql-sto1-12345-do-user.b.db.ondigitalocean.com \
  -P 25060 \
  -u doadmin \
  -pYOUR_DO_PASSWORD \
  --ssl-mode=REQUIRED \
  --set-gtid-purged=OFF \
  --single-transaction \
  --routines \
  --triggers \
  --no-tablespaces \
  defaultdb > digitalocean-mysql.sql

The --single-transaction flag ensures a consistent snapshot without locking tables. The --set-gtid-purged=OFF flag avoids GTID conflicts when importing into a fresh instance.

Create on FoundryDB​

fdb create \
  --database-type mysql \
  --version 8.4 \
  --plan-name tier-2 \
  --storage-size-gb 50 \
  --name my-mysql-db \
  --zone se-sto1

Wait for Running status:

fdb status my-mysql-db

Import​

fdb connect my-mysql-db --info

mysql \
  -h my-mysql-db-abc123.db.foundrydb.com \
  -u app_user \
  -pYOUR_PASSWORD \
  --ssl-mode=REQUIRED \
  defaultdb < digitalocean-mysql.sql

Verify​

fdb connect my-mysql-db

-- Check tables
SHOW TABLES;

-- Verify row counts
SELECT table_name, table_rows
FROM information_schema.tables
WHERE table_schema = 'defaultdb'
ORDER BY table_rows DESC;

-- Check stored routines migrated
SHOW PROCEDURE STATUS WHERE Db = 'defaultdb';
SHOW FUNCTION STATUS WHERE Db = 'defaultdb';

MongoDB Migration​

Export from DigitalOcean​

Get your DigitalOcean MongoDB connection string, then dump:

mongodump \
  --uri="mongodb+srv://doadmin:YOUR_DO_PASSWORD@db-mongodb-sto1-12345.mongo.ondigitalocean.com/admin?authSource=admin&tls=true" \
  --db=my_database \
  --out=./digitalocean-mongo-dump

This creates a directory with BSON files for each collection. For large databases, add --gzip to compress the output:

mongodump \
  --uri="mongodb+srv://doadmin:YOUR_DO_PASSWORD@db-mongodb-sto1-12345.mongo.ondigitalocean.com/admin?authSource=admin&tls=true" \
  --db=my_database \
  --gzip \
  --out=./digitalocean-mongo-dump

Create on FoundryDB​

fdb create \
  --database-type mongodb \
  --version 7.0 \
  --plan-name tier-2 \
  --storage-size-gb 50 \
  --name my-mongo-db \
  --zone se-sto1

Wait for Running status:

fdb status my-mongo-db

Import​

fdb connect my-mongo-db --info

mongorestore \
  --uri="mongodb://app_user:YOUR_PASSWORD@my-mongo-db-abc123.db.foundrydb.com:27017/defaultdb?tls=true&authSource=admin" \
  --nsFrom="my_database.*" \
  --nsTo="defaultdb.*" \
  ./digitalocean-mongo-dump/my_database

If you used --gzip during the dump, add --gzip to the restore command as well. The --nsFrom and --nsTo flags remap the database name from your DigitalOcean source to defaultdb on FoundryDB.

Verify​

fdb connect my-mongo-db

// List collections
show collections

// Check document counts
db.getCollectionNames().forEach(function(c) {
    print(c + ": " + db[c].countDocuments({}));
});

// Verify indexes
db.getCollectionNames().forEach(function(c) {
    print("--- " + c + " ---");
    printjson(db[c].getIndexes());
});

// Test a query
db.users.find().limit(5).pretty();

Updating Your Application​

After importing data into FoundryDB, update your application's connection strings. The new format depends on the engine:

PostgreSQL:

postgresql://app_user:PASSWORD@my-pg-db-abc123.db.foundrydb.com:5432/defaultdb?sslmode=require

MySQL:

mysql://app_user:PASSWORD@my-mysql-db-abc123.db.foundrydb.com:3306/defaultdb?ssl-mode=REQUIRED

MongoDB:

mongodb://app_user:PASSWORD@my-mongo-db-abc123.db.foundrydb.com:27017/defaultdb?tls=true&authSource=admin

For zero-downtime migrations on high-traffic applications, consider running both databases in parallel briefly: point your application at FoundryDB, monitor for errors, and decommission the DigitalOcean instance once you have confirmed stability.

What You Gain After Migrating​

Moving from DigitalOcean Managed Databases to FoundryDB gives you access to a significantly richer platform:

• 7 engines instead of 4. PostgreSQL, MySQL, MongoDB, Valkey, Kafka, OpenSearch, and Babelfish. Manage all of them from one CLI, one dashboard, one bill.
• AI-ready presets. Provision a PostgreSQL instance with pgvector pre-configured for embedding storage, or create a Kafka + PostgreSQL pipeline for RAG architectures, all from predefined presets.
• Pipeline templates. Set up common data flows (CDC from PostgreSQL to Kafka, search indexing from MongoDB to OpenSearch) with pre-built templates rather than wiring everything together manually.
• Predictive autoscaling. FoundryDB tracks CPU, memory, storage, and connection trends over time, then scales proactively before your application is affected.
• Database forking. Create an instant copy of any database from a backup or point-in-time snapshot. Use it for testing schema changes, running analytics, or debugging production issues without touching the live database.
• 7 metrics export destinations. Send database metrics to Grafana Cloud, Datadog, New Relic, Prometheus remote write, InfluxDB, CloudWatch, or a custom webhook. DigitalOcean locks you into their built-in dashboard.
• Query-level analytics. See the slowest queries, most frequent queries, and lock contention patterns directly in the dashboard. No need to enable pg_stat_statements manually or parse slow query logs.
• EU infrastructure. All FoundryDB services run in European data centers by default. No special configuration or pricing tier required for GDPR compliance.

Whether you are migrating one database or consolidating PostgreSQL, MySQL, and MongoDB onto a single platform, the process follows the same pattern: export, create, import, verify. Each engine's standard tooling works exactly as expected because FoundryDB runs the native database engines with no proxy layers or compatibility shims.

This guide walks you through a complete migration from Heroku Postgres to FoundryDB. The entire process takes about 10 minutes for a typical application database.

Why Migrate from Heroku Postgres?​

Heroku Postgres serves many teams well for getting started, but production workloads often outgrow it:

• Single engine only. Heroku offers PostgreSQL and nothing else. If your architecture needs Redis-compatible caching, Kafka for event streaming, or MongoDB for document storage, you need separate providers.
• No multi-node HA on standard plans. Automatic failover requires Premium or Enterprise tiers. On Standard plans, a hardware failure means downtime.
• Basic monitoring. Heroku provides pg:info and a simple dashboard. There is no query-level performance analysis, no predictive autoscaling, and no custom alerting rules.
• No point-in-time recovery on lower tiers. PITR is only available on Premium plans and above. Standard plans get periodic snapshots with potential data loss windows.
• US-centric infrastructure. Heroku runs on AWS, primarily in the US. EU data residency requires careful plan selection and comes at a premium.

FoundryDB addresses all of these: seven database engines on one platform, multi-node HA from day one, PITR on every plan, predictive autoscaling, and EU-hosted infrastructure by default.

Prerequisites​

Before starting, make sure you have:

• Heroku CLI installed and authenticated (heroku login)
• A FoundryDB account at foundrydb.com
• The fdb CLI installed (brew install foundrydb/tap/fdb or download from the dashboard)
• pg_restore available locally (comes with any PostgreSQL client installation)

Step 1: Export Your Database from Heroku​

First, capture a fresh backup of your Heroku Postgres database:

# Capture a new backup
heroku pg:backups:capture --app my-heroku-app

# Download the backup to your local machine
heroku pg:backups:download --app my-heroku-app

This creates a file called latest.dump in your current directory. The file is in PostgreSQL's custom dump format, which supports parallel restore and selective table restoration.

For larger databases, you can check the backup size before downloading:

heroku pg:backups --app my-heroku-app

Step 2: Create a PostgreSQL Service on FoundryDB​

Create a new PostgreSQL instance using the FoundryDB CLI:

fdb create \
  --database-type postgresql \
  --version 17 \
  --plan-name tier-2 \
  --storage-size-gb 50 \
  --name my-app-db \
  --zone se-sto1

This provisions a PostgreSQL 17 instance with 2 vCPUs, 4 GB RAM, and 50 GB of NVMe storage. The service is ready in about 3 to 5 minutes. You can monitor the provisioning status:

fdb status my-app-db

Wait until the status shows Running before proceeding.

Step 3: Get Your Connection Details​

Retrieve the connection string for your new database:

fdb connect my-app-db --info

This outputs the host, port, username, password, and a full connection URI. Note the host (it will look like my-app-db-abc123.db.foundrydb.com), username, and password for the next step.

You can also reveal credentials for a specific user:

fdb users my-app-db --reveal-password

Step 4: Import Your Data​

Use pg_restore to load the Heroku dump into your FoundryDB instance:

pg_restore \
  --host my-app-db-abc123.db.foundrydb.com \
  --port 5432 \
  --username app_user \
  --dbname defaultdb \
  --no-owner \
  --no-privileges \
  --verbose \
  latest.dump

Enter the password when prompted. The --no-owner and --no-privileges flags skip Heroku-specific role assignments that do not exist on your new instance.

For larger databases, use parallel restore to speed things up:

pg_restore \
  --host my-app-db-abc123.db.foundrydb.com \
  --port 5432 \
  --username app_user \
  --dbname defaultdb \
  --no-owner \
  --no-privileges \
  --jobs 4 \
  latest.dump

Step 5: Update Your Application's DATABASE_URL​

Replace your Heroku database connection string with the FoundryDB one. The new URL follows standard PostgreSQL format:

postgresql://app_user:YOUR_PASSWORD@my-app-db-abc123.db.foundrydb.com:5432/defaultdb?sslmode=require

If your app reads DATABASE_URL from environment variables, update it in your deployment configuration. For example, in a Docker Compose setup:

environment:
  DATABASE_URL: postgresql://app_user:YOUR_PASSWORD@my-app-db-abc123.db.foundrydb.com:5432/defaultdb?sslmode=require

FoundryDB uses auto-renewed TLS certificates, so sslmode=require (or verify-full) works out of the box with no certificate management on your part.

Step 6: Verify the Migration​

Connect to your new database and run verification queries:

# Connect interactively
fdb connect my-app-db

# Or use psql directly
PGPASSWORD=YOUR_PASSWORD psql \
  "host=my-app-db-abc123.db.foundrydb.com user=app_user dbname=defaultdb sslmode=require"

Run these checks to confirm everything migrated correctly:

-- Check table count
SELECT count(*) FROM information_schema.tables WHERE table_schema = 'public';

-- Check row counts for key tables
SELECT schemaname, relname, n_live_tup
FROM pg_stat_user_tables
ORDER BY n_live_tup DESC
LIMIT 20;

-- Verify indexes exist
SELECT indexname, tablename FROM pg_indexes WHERE schemaname = 'public';

-- Test a representative query from your application
SELECT * FROM users LIMIT 5;

Compare the table count and row counts against your Heroku instance to confirm data integrity.

What You Gain After Migrating​

Moving from Heroku Postgres to FoundryDB gives you immediate access to:

• 7 database engines. PostgreSQL, MySQL, MongoDB, Valkey, Kafka, OpenSearch, and Babelfish (SQL Server wire protocol). Manage everything from one dashboard and one CLI.
• Multi-node HA. Add read replicas and automatic failover with a single command. No plan upgrade required.
• Point-in-time recovery. Every plan includes continuous WAL archiving and PITR. Restore to any second within your retention window.
• Predictive autoscaling. FoundryDB monitors resource trends and scales compute and storage before you hit limits, not after.
• EU hosting by default. All infrastructure runs in European data centers (Stockholm), simplifying GDPR compliance.
• TLS auto-renewal. Certificates are provisioned and renewed automatically. No manual certificate management.
• Extensions ecosystem. Enable pgvector, PostGIS, TimescaleDB, and dozens of other extensions directly from the dashboard or CLI.
• Real-time query analytics. Monitor slow queries, connection counts, replication lag, and custom metrics with built-in dashboards and alerting.

The migration is a one-time effort. Once your data is on FoundryDB, you have a modern database platform that scales with your application.

This guide walks through exporting your database from PlanetScale and importing it into FoundryDB's native MySQL service. The process works for databases of any size, from small hobby projects to production workloads.

Why Migrate from PlanetScale?​

PlanetScale built an impressive product on Vitess, but the tradeoffs are real:

• No foreign key enforcement. PlanetScale does not enforce foreign key constraints. Your application must handle referential integrity in code. This means bugs in your application logic can silently corrupt data relationships.
• Vitess compatibility gaps. Certain SQL features behave differently or are unavailable: some subquery patterns, specific JOIN operations, and DDL statements have restrictions. You are running "MySQL-like" rather than MySQL itself.
• Pricing increases. After removing the free tier, PlanetScale's Scaler plan starts at $39/month for 5 GB of storage. FoundryDB's tier-2 plan with 50 GB of NVMe storage offers more resources at a competitive price.
• Single engine. PlanetScale is MySQL-only. If your stack needs Redis-compatible caching, PostgreSQL for analytics, or Kafka for event streaming, you need additional providers.
• No GTID replication. PlanetScale uses Vitess-level replication rather than native MySQL GTID replication. This limits your ability to set up standard MySQL replicas or integrate with tools that expect GTID-based binlog positions.

FoundryDB runs native MySQL 8.4 with full foreign key support, GTID-based replication, ProxySQL connection pooling, and six additional database engines on the same platform.

Prerequisites​

Before starting, make sure you have:

• PlanetScale CLI (pscale) installed and authenticated
• A FoundryDB account at foundrydb.com
• The fdb CLI installed (brew install foundrydb/tap/fdb or download from the dashboard)
• MySQL client tools available locally (mysqldump and mysql commands)

Step 1: Export Your Database from PlanetScale​

PlanetScale provides a built-in dump command through its CLI:

pscale database dump my-planetscale-db main --output ./dump

This exports all tables from the main branch into individual SQL files in the ./dump directory. Each table gets its own file containing the schema and data.

Alternatively, if you prefer a single dump file, you can connect directly and use mysqldump:

# Get your PlanetScale connection string
pscale connect my-planetscale-db main --port 3309

# In another terminal, dump using mysqldump
mysqldump \
  --host 127.0.0.1 \
  --port 3309 \
  --user YOUR_PSCALE_USER \
  --set-gtid-purged=OFF \
  --no-tablespaces \
  --single-transaction \
  my_database > planetscale-dump.sql

The --set-gtid-purged=OFF flag is important because PlanetScale (Vitess) does not use standard MySQL GTID, so the dump should not include GTID metadata.

Step 2: Create a MySQL Service on FoundryDB​

Provision a new MySQL instance:

fdb create \
  --database-type mysql \
  --version 8.4 \
  --plan-name tier-2 \
  --storage-size-gb 50 \
  --name my-mysql-db \
  --zone se-sto1

This creates a MySQL 8.4 instance with 2 vCPUs, 4 GB RAM, and 50 GB NVMe storage. Monitor provisioning:

fdb status my-mysql-db

Wait until the status shows Running. Provisioning typically takes 3 to 5 minutes.

Step 3: Get Your Connection Details​

Retrieve your FoundryDB MySQL connection information:

fdb connect my-mysql-db --info

This shows the host, port, username, password, and connection URI. Note these values for the import step.

Step 4: Import Your Data​

If you used the PlanetScale CLI dump (multiple files in a directory), import each file:

for f in ./dump/*.sql; do
  mysql \
    -h my-mysql-db-abc123.db.foundrydb.com \
    -u app_user \
    -pYOUR_PASSWORD \
    --ssl-mode=REQUIRED \
    defaultdb < "$f"
done

If you used a single mysqldump file:

mysql \
  -h my-mysql-db-abc123.db.foundrydb.com \
  -u app_user \
  -pYOUR_PASSWORD \
  --ssl-mode=REQUIRED \
  defaultdb < planetscale-dump.sql

For large databases, you may want to disable key checks during import for better performance:

mysql \
  -h my-mysql-db-abc123.db.foundrydb.com \
  -u app_user \
  -pYOUR_PASSWORD \
  --ssl-mode=REQUIRED \
  -e "SET GLOBAL foreign_key_checks=0; SOURCE planetscale-dump.sql; SET GLOBAL foreign_key_checks=1;" \
  defaultdb

Step 5: Update Your Application Connection Strings​

Replace your PlanetScale connection string with the FoundryDB one:

mysql://app_user:YOUR_PASSWORD@my-mysql-db-abc123.db.foundrydb.com:3306/defaultdb?ssl-mode=REQUIRED

Most MySQL client libraries accept this URI format. For frameworks that use individual parameters:

# Example: Rails database.yml
production:
  adapter: mysql2
  host: my-mysql-db-abc123.db.foundrydb.com
  port: 3306
  username: app_user
  password: YOUR_PASSWORD
  database: defaultdb
  ssl_mode: required

Step 6: Verify the Migration​

Connect and run verification queries:

fdb connect my-mysql-db

Or directly with the MySQL client:

mysql \
  -h my-mysql-db-abc123.db.foundrydb.com \
  -u app_user \
  -pYOUR_PASSWORD \
  --ssl-mode=REQUIRED \
  defaultdb

Run these checks:

-- Check all tables imported
SHOW TABLES;

-- Verify row counts on key tables
SELECT table_name, table_rows
FROM information_schema.tables
WHERE table_schema = 'defaultdb'
ORDER BY table_rows DESC;

-- Verify foreign keys are enforced (this was impossible on PlanetScale)
SHOW CREATE TABLE orders;

-- Test a foreign key constraint
INSERT INTO orders (user_id, total) VALUES (999999, 10.00);
-- Should fail if user_id 999999 doesn't exist in users table

-- Check indexes
SHOW INDEX FROM your_main_table;

The foreign key test is the most important verification. On PlanetScale, the INSERT with a non-existent user_id would succeed silently. On FoundryDB's native MySQL, it correctly rejects the statement with a foreign key violation error.

What You Gain After Migrating​

Switching from PlanetScale to FoundryDB gives you:

• Native MySQL, not a proxy. Your queries hit MySQL directly. No Vitess translation layer, no compatibility surprises. Standard MySQL documentation applies exactly as written.
• Foreign key enforcement. Referential integrity is handled by the database engine where it belongs. Remove the workarounds from your application code.
• GTID-based replication. FoundryDB uses standard MySQL GTID replication for read replicas and HA. This is compatible with the entire MySQL ecosystem of tools and monitoring.
• ProxySQL connection pooling. Enable the ProxySQL addon for intelligent query routing, connection multiplexing, and read/write splitting across replicas.
• 7 engines on one platform. Need Valkey for caching, Kafka for events, or PostgreSQL for a different service? Create them from the same dashboard and CLI. One bill, one set of credentials.
• Predictive autoscaling. FoundryDB monitors CPU, memory, storage, and connection trends, then scales resources proactively before your application feels the pressure.
• Point-in-time recovery. Continuous binary log archiving lets you restore to any second within your retention window. No more scheduled-snapshot-only recovery.
• EU infrastructure. All data stays in European data centers by default, simplifying compliance requirements.

The migration from PlanetScale is straightforward because you are moving from a MySQL-compatible system to actual MySQL. Your existing queries, ORMs, and tools will work without modification, and features that were restricted under Vitess (foreign keys, certain joins, subqueries) start working immediately.

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.

What Agents Need from a Database Platform​

AI agents have different requirements than human operators. Understanding these differences shaped our design decisions.

Fast provisioning. An agent building a RAG pipeline needs a PostgreSQL instance with pgvector now, not in 10 minutes. When database creation is part of an agent's planning and execution loop, provisioning latency directly impacts the agent's task completion time. FoundryDB provisions from pre-built templates, with most services ready to accept connections within 2-3 minutes.

Ephemeral databases. Many agent workflows create databases for a specific task: index a document corpus, run an analysis, generate a report. When the task is done, the database should be cleaned up automatically. FoundryDB supports TTL (time-to-live) on services, so agents can create a database that auto-deletes after a specified duration.

Programmatic management. Agents interact through APIs and tool calls, not dashboards. Every FoundryDB operation is available through our REST API, CLI, TypeScript SDK, Python SDK, and MCP (Model Context Protocol) server. Agents can create, configure, query, scale, and delete databases without human intervention.

Presets for common patterns. Agents should not need to figure out which PostgreSQL extensions to enable for vector search or what Kafka topic configuration works best for event sourcing. FoundryDB provides 16 presets that pre-configure services for specific use cases. An agent says "I need a database for vector search" and gets a PostgreSQL instance with pgvector enabled, HNSW indexes configured, and appropriate resource allocation.

Metadata and labeling. When agents create dozens of databases, operators need to understand what each one is for. FoundryDB supports service labels and metadata that agents can set at creation time: agent_framework: langchain, agent_purpose: rag-pipeline, agent_run_id: abc-123.

The MCP Server​

The Model Context Protocol (MCP) is becoming the standard way for LLMs and agents to interact with external tools. FoundryDB ships an MCP server that exposes database management as tool calls that any MCP-compatible agent can use.

Here is what it looks like when an agent uses the MCP server to create a database:

Agent: "Create a PostgreSQL database with pgvector for storing
        document embeddings. Use the Helsinki zone and tier-3 plan."

MCP Tool Call: foundrydb.create_service({
  name: "doc-embeddings-a3f2",
  engine: "postgresql",
  version: "17",
  plan: "tier-3",
  zone: "eu-helsinki",
  storage_gb: 50,
  preset: "pgvector",
  labels: {
    agent_framework: "claude",
    agent_purpose: "document-embeddings",
    created_by: "agent"
  },
  ttl: "24h"
})

Response: {
  id: "svc_x7k2m9p4",
  status: "provisioning",
  connection_uri: "postgresql://app_user:***@doc-embeddings-a3f2.foundrydb.com/defaultdb?sslmode=verify-full",
  estimated_ready: "2m"
}

The MCP server handles authentication, input validation, and returns structured responses that the agent can parse and act on. The agent does not need to know about REST endpoints or HTTP headers.

To configure the MCP server with Claude Desktop or any MCP-compatible client:

{
  "mcpServers": {
    "foundrydb": {
      "command": "npx",
      "args": ["@foundrydb/mcp-server"],
      "env": {
        "FOUNDRYDB_API_KEY": "your-api-key"
      }
    }
  }
}

SDK Integration​

For agents built with Python or TypeScript, the FoundryDB SDKs provide typed, idiomatic interfaces for database management.

Python SDK​

from foundrydb import FoundryDB

fdb = FoundryDB(api_key="your-api-key")

# Create a service with a preset
service = fdb.services.create(
    name="agent-rag-store",
    engine="postgresql",
    version="17",
    plan="tier-3",
    zone="eu-helsinki",
    storage_gb=50,
    preset="pgvector",
    labels={"agent_framework": "langchain", "agent_purpose": "rag"},
    ttl="12h",  # Auto-delete after 12 hours
)

# Wait for the service to be ready
service.wait_until_ready(timeout=300)

# Get connection details
conn_info = service.connection_info()
print(f"Connect: {conn_info.uri}")

# When the agent is done, delete immediately (or let TTL handle it)
service.delete()

TypeScript SDK​

import { FoundryDB } from '@foundrydb/sdk';

const fdb = new FoundryDB({ apiKey: 'your-api-key' });

const service = await fdb.services.create({
  name: 'agent-session-cache',
  engine: 'valkey',
  version: '8.1',
  plan: 'tier-2',
  zone: 'eu-helsinki',
  storageGb: 20,
  labels: { agent_framework: 'crewai', agent_purpose: 'session-cache' },
  ttl: '6h',
});

await service.waitUntilReady();

const { host, port, password } = service.connectionInfo();
// Use the Valkey instance...

CLI for Scripting​

For agents that shell out to CLI tools:

# Create and wait in one command
fdb services create \
  --name agent-workspace-$(uuidgen | head -c 8) \
  --engine postgresql \
  --version 17 \
  --plan tier-2 \
  --storage 50 \
  --zone eu-helsinki \
  --preset pgvector \
  --label agent_framework=autogen \
  --label agent_purpose=analysis \
  --ttl 4h \
  --wait \
  --output json

# List all agent-created services
fdb services list --label created_by=agent --output json

# Clean up all expired agent services (TTL handles this, but manual cleanup is available)
fdb services list --label created_by=agent --status stopped --output json \
  | jq -r '.[].id' \
  | xargs -I {} fdb services delete {}

Common Agent Architectures​

Here are the most common multi-engine patterns we see agents deploying on FoundryDB.

RAG Pipeline (PostgreSQL + Valkey)​

The most popular pattern. PostgreSQL with pgvector stores document embeddings. Valkey caches query results and stores conversation history. Kafka is optional for high-throughput document ingestion.

# Agent creates a complete RAG stack
vector_db = fdb.services.create(
    name="rag-vectors",
    engine="postgresql",
    preset="pgvector",
    plan="tier-4",
    storage_gb=100,
    zone="eu-helsinki",
    labels={"stack": "rag", "role": "vector-store"},
)

cache = fdb.services.create(
    name="rag-cache",
    engine="valkey",
    plan="tier-2",
    storage_gb=20,
    zone="eu-helsinki",
    labels={"stack": "rag", "role": "cache"},
)

Conversational AI (MongoDB + Valkey)​

MongoDB stores conversation histories, user profiles, and tool call logs. Its flexible schema adapts to the evolving structure of agent interactions without migrations. Valkey handles session state and rate limiting.

Multi-Agent Coordination (Kafka + MongoDB + PostgreSQL)​

When multiple agents collaborate (CrewAI, AutoGen, LangGraph), Kafka serves as the event bus for inter-agent communication. MongoDB stores agent state and task results. PostgreSQL handles structured data that agents query with SQL.

Ephemeral Analysis (PostgreSQL with TTL)​

Data analysts use agents to create temporary databases, load datasets, run complex queries, and export results. The database auto-deletes after the analysis is complete.

# Temporary analysis database that self-destructs in 2 hours
analysis_db = fdb.services.create(
    name=f"analysis-{task_id}",
    engine="postgresql",
    plan="tier-3",
    storage_gb=50,
    zone="eu-helsinki",
    ttl="2h",
    labels={"agent_purpose": "data-analysis", "task_id": task_id},
)

Service Labels and Observability​

When agents create databases autonomously, observability becomes critical. Who created this database? Why? Is it still needed? FoundryDB's label system provides the answers.

Every service supports arbitrary key-value labels. We recommend a standard set for agent-created services:

These labels are queryable through the API and visible in the dashboard. Operators can filter by created_by=agent to see all agent-provisioned databases, or by agent_framework=langchain to see databases created by a specific framework.

# Dashboard view: all agent-created services
fdb services list --label created_by=agent

# Cost tracking: total spend by agent framework
fdb billing usage --group-by label:agent_framework

# Cleanup: find agent databases older than 7 days
fdb services list --label created_by=agent --created-before 7d

Building for the Agent Era​

The shift toward agent-driven database provisioning is accelerating. As agent frameworks mature and more workflows become autonomous, the database platform needs to be a first-class participant in the agent ecosystem, not an afterthought that requires human intervention.

FoundryDB's approach is to meet agents where they are: MCP for LLM-native tool use, SDKs for framework integration, presets for instant configuration, TTL for lifecycle management, and labels for observability. The database becomes another tool in the agent's toolkit, provisioned and managed as naturally as making an API call or reading a file.

Explore the AI agent infrastructure documentation to integrate FoundryDB with your agent workflows. The MCP server is available today, and the Python and TypeScript SDKs support all service management operations.

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.

How It Works​

The AI Query Console is a two-step pipeline: translate, then execute. These are separate API calls, which means you always see the generated SQL before anything runs against your database. You can review it, edit it, or discard it entirely.

Step 1: Translate​

You send a natural language question to the translate endpoint. FoundryDB passes your question to Claude along with the database dialect (PostgreSQL or MySQL) and the engine version. Claude generates a read-only SQL query and a brief explanation of what it does.

curl -u user:password -X POST \
  https://api.foundrydb.com/managed-services/{service-id}/ai-query/translate \
  -H "Content-Type: application/json" \
  -d '{"question": "Show the top 10 largest tables by size"}'

The response includes the generated SQL, an explanation, and the database dialect used:

{
  "sql": "SELECT tablename, pg_total_relation_size(quote_ident(tablename)) AS size FROM pg_tables WHERE schemaname = 'public' ORDER BY size DESC LIMIT 10",
  "explanation": "Lists the 10 largest tables in the public schema",
  "database_type": "postgresql"
}

If Claude generates a query that violates safety rules, the sql field is returned empty and a warning field explains why the query was blocked.

Step 2: Execute​

Once you have the SQL (or have edited it to your liking), you send it to the execute endpoint:

curl -u user:password -X POST \
  https://api.foundrydb.com/managed-services/{service-id}/ai-query/execute \
  -H "Content-Type: application/json" \
  -d '{"sql": "SELECT tablename, pg_total_relation_size(quote_ident(tablename)) AS size FROM pg_tables WHERE schemaname = '\''public'\'' ORDER BY size DESC LIMIT 10"}'

The response contains column names, row data, the row count, and execution time in milliseconds:

{
  "columns": ["tablename", "size"],
  "rows": [
    ["orders", 2147483648],
    ["events", 1073741824],
    ["users", 536870912]
  ],
  "row_count": 3,
  "execution_ms": 15,
  "truncated": false
}

Results are capped at 1,000 rows. If the result set exceeds that limit, truncated is set to true.

Safety Guardrails​

The AI Query Console enforces read-only access at three layers, so no single point of failure can allow a write operation.

1. Prompt-level constraints. The system prompt instructs Claude to generate only SELECT, SHOW, DESCRIBE, and EXPLAIN statements. It explicitly forbids INSERT, UPDATE, DELETE, DROP, CREATE, ALTER, TRUNCATE, and multi-statement queries.

2. Server-side SQL validation. Before execution, the controller parses the SQL and rejects anything that is not a recognized read-only statement. It strips comments, blocks semicolons (preventing multi-statement injection), and scans for dangerous keywords even inside subqueries and CTEs.

3. Database-level read-only mode. The connection to your database is opened in read-only transaction mode. On PostgreSQL, this sets default_transaction_read_only = ON and a 30-second statement_timeout. On MySQL, it uses SET SESSION TRANSACTION READ ONLY and max_execution_time = 30000. Even if a write query somehow passes the first two layers, the database itself rejects it.

These layers are independent. A failure at the AI level is caught by validation. A failure at validation is caught by the database. Your data stays safe.

Supported Database Engines​

The translate endpoint generates dialect-correct SQL based on your service's engine type and version. If you have a PostgreSQL 17 service, it generates PostgreSQL 17-compatible queries. If you have a MySQL 8.4 service, it generates MySQL 8.4-compatible queries. You do not need to specify the dialect yourself.

Schema Context Awareness​

When Claude generates SQL for your service, it knows the database dialect and version. This means it can reference engine-specific system views accurately. Ask a PostgreSQL service about slow queries, and it queries pg_stat_statements. Ask a MySQL service the same question, and it queries performance_schema.

The translate endpoint also accepts an optional database_name parameter. By default, queries run against defaultdb (the default database created for every FoundryDB service). If you want to query a different database on the same service, pass it explicitly:

curl -u user:password -X POST \
  https://api.foundrydb.com/managed-services/{service-id}/ai-query/translate \
  -H "Content-Type: application/json" \
  -d '{"question": "How many rows are in each table?", "database_name": "analytics"}'

The Dashboard Experience​

The AI Query Console is built into the FoundryDB dashboard as a tab on every PostgreSQL and MySQL service. The workflow is straightforward:

1. Type a question in the text field (or click one of the suggested examples).
2. Click Generate SQL (or press Cmd+Enter / Ctrl+Enter).
3. Review the generated SQL. Edit it if you want.
4. Click Run Query to execute.
5. View results in a paginated table with column headers, row counts, and execution time.

The console tracks a local query history (up to 20 entries) so you can revisit previous questions without retyping them. If you modify the generated SQL before executing, a "Modified" badge appears so you can tell at a glance whether the query is the original or your edited version.

Example Questions to Try​

For PostgreSQL services:

• "Show the top 10 largest tables by size"
• "List active connections grouped by user"
• "Show slow queries from the last hour"
• "What indexes are unused?"
• "Show table row counts for all user tables"

For MySQL services:

• "Show the top 10 largest tables by size"
• "List active connections grouped by user"
• "Show the most frequently run queries"
• "What indexes exist on each table?"
• "Show table row counts for all tables"

API Reference​

Both endpoints require authentication and a running service.

Translate request body:

Execute request body:

Execute response:

Error Handling​

The API returns RFC 7807 problem details for errors:

• 400: Empty question, question exceeding 1,000 characters, unsupported database type, service not in Running state, or blocked SQL.
• 404: Service not found or access denied.
• 501: AI Query feature not configured (missing Anthropic API key). Contact your administrator.

Get Started​

The AI Query Console is available on every PostgreSQL and MySQL service in FoundryDB. Open your service in the dashboard, navigate to the AI Query tab, and ask your first question.

If you prefer the API, check out the full AI Query documentation for request and response schemas, or explore the feature with the FoundryDB CLI.

Don't have a FoundryDB account yet? Sign up and have a production-ready PostgreSQL or MySQL service running in under five minutes.

Babelfish for PostgreSQL changes the equation. It adds a SQL Server wire-protocol layer (TDS) on top of PostgreSQL, so your existing applications connect to port 1433 and run T-SQL queries as before. No driver changes. No syntax rewrites. On FoundryDB, you get a fully managed Babelfish instance running on PostgreSQL 16 with backups, TLS, monitoring, and point-in-time recovery built in.

What Is Babelfish?​

Babelfish is an open source extension for PostgreSQL, originally developed by AWS and now maintained by the community. It adds two capabilities to a standard PostgreSQL instance:

1. TDS wire protocol on port 1433. SQL Server clients (SSMS, sqlcmd, ADO.NET, JDBC with the SQL Server driver) connect to this port and interact with the database using their native protocol.
2. T-SQL language support. Stored procedures, functions, triggers, and queries written in Transact-SQL execute on the PostgreSQL engine without modification.

The underlying database is still PostgreSQL. You get full access to the PostgreSQL wire protocol on port 5432 in parallel, which means new services can use standard PostgreSQL drivers while legacy applications continue using TDS.

Dual-Protocol Access​

Every Babelfish service on FoundryDB exposes two ports:

Both ports point to the same data. A row inserted via TDS on port 1433 is immediately visible through a PostgreSQL query on port 5432. This dual-protocol model lets you migrate incrementally: keep the legacy app on TDS while building new features against the PostgreSQL interface.

Provisioning a Babelfish Service​

A single API call provisions a production-ready Babelfish instance. FoundryDB handles the custom PostgreSQL 16 binary, the Babelfish extension initialization, TLS certificates, and firewall rules.

# Via CLI
fdb services create \
  --name legacy-crm \
  --engine mssql \
  --version 4.8 \
  --plan tier-4 \
  --storage 100 \
  --storage-tier maxiops \
  --zone se-sto1

# Via API
curl -u admin:password -X POST \
  https://api.foundrydb.com/managed-services \
  -H "Content-Type: application/json" \
  -d '{
    "name": "legacy-crm",
    "database_type": "mssql",
    "version": "4.8",
    "plan_name": "tier-4",
    "storage_size_gb": 100,
    "storage_tier": "maxiops",
    "zone": "se-sto1"
  }'

Under the hood, FoundryDB provisions a VM from a pre-built Packer template that includes the Babelfish-patched PostgreSQL 16 binary at /opt/babelfish/. The agent initializes the cluster with data checksums enabled, loads the babelfishpg_tds extension, creates the internal babelfish_db database, and calls sys.initialize_babelfish to set up the T-SQL catalog. The TDS listener starts on port 1433 automatically.

Provisioning typically completes in under five minutes.

Connecting Your Application​

Once the service is running, retrieve your credentials and DNS hostname from the FoundryDB dashboard or API.

SQL Server Clients (TDS, Port 1433)​

Use any SQL Server driver or tool. The connection looks identical to connecting to a real SQL Server instance.

# sqlcmd
sqlcmd -S your-service.db.foundrydb.com,1433 -U app_user -P 'your-password' \
  -Q "SELECT @@VERSION"

# .NET / ADO.NET connection string
Server=your-service.db.foundrydb.com,1433;Database=defaultdb;User Id=app_user;Password=your-password;Encrypt=true;TrustServerCertificate=false;

# JDBC (SQL Server driver)
jdbc:sqlserver://your-service.db.foundrydb.com:1433;databaseName=defaultdb;user=app_user;password=your-password;encrypt=true;

PostgreSQL Clients (Port 5432)​

PGPASSWORD='your-password' psql \
  "host=your-service.db.foundrydb.com user=app_user dbname=defaultdb sslmode=verify-full"

SQL Server Management Studio (SSMS)​

Open SSMS and enter:

• Server name: your-service.db.foundrydb.com,1433
• Authentication: SQL Server Authentication
• Login: your database user
• Password: your database password

Check "Encrypt connection" in the connection properties. SSMS will connect over TDS and display the database objects as it would for any SQL Server instance.

What T-SQL Syntax Works​

Babelfish 4.x supports a broad subset of T-SQL. For most CRUD applications, stored procedure logic, and reporting queries, the migration is straightforward.

Supported:

• DML: SELECT, INSERT, UPDATE, DELETE, MERGE
• Programmability: CREATE PROCEDURE, CREATE FUNCTION, CREATE TRIGGER
• SQL Server data types: NVARCHAR, DATETIME, UNIQUEIDENTIFIER, BIT, MONEY, and others
• System views: partial sys. catalog emulation, INFORMATION_SCHEMA views
• Session settings: SET NOCOUNT ON, SET ANSI_NULLS ON, and other common SET options

Not supported:

If your application uses SQL Server Agent for scheduled jobs, replace those with cron, a task scheduler like Celery, or an external orchestrator. For full-text search, consider pairing your Babelfish service with an OpenSearch instance on FoundryDB.

For the complete compatibility matrix, refer to the official Babelfish documentation.

Migration Steps​

1. Assess Your T-SQL Codebase​

Use the Babelfish Compass tool to analyze your existing SQL Server database. It scans DDL scripts, stored procedures, and functions, then reports which constructs are supported, partially supported, or unsupported.

# Export your schema from SQL Server
sqlcmd -S old-server -U sa -Q "EXEC sp_generate_inserts" -o schema.sql

# Run Babelfish Compass against the DDL
java -jar BabelfishCompass.jar schema.sql

2. Provision and Load Schema​

Create your FoundryDB Babelfish service, then connect via TDS and run your DDL scripts directly.

sqlcmd -S your-service.db.foundrydb.com,1433 -U app_user -P 'your-password' \
  -i schema.sql

3. Migrate Data​

For initial data loads, export from SQL Server using bcp or a custom ETL pipeline, then import via the same TDS connection. For smaller datasets, INSERT ... SELECT over linked tooling works fine.

4. Update Connection Strings​

Point your application's SQL Server connection string to the FoundryDB hostname. Since the TDS protocol is the same, most applications require only a hostname change.

5. Validate with Both Protocols​

Run your application test suite against the TDS endpoint. In parallel, connect via PostgreSQL on port 5432 to verify that the data is accessible from both protocols.

Backups and Recovery​

Babelfish on FoundryDB uses pgBackRest for continuous WAL archiving. Point-in-time recovery (PITR) lets you restore to any second within the retention window.

curl -u admin:password -X POST \
  https://api.foundrydb.com/managed-services/{id}/backups/restore \
  -H "Content-Type: application/json" \
  -d '{
    "restore_point": "2026-04-05T14:30:00Z",
    "target_service_name": "crm-restored"
  }'

PostgreSQL Configuration​

Since Babelfish runs on PostgreSQL 16, you tune it like any PostgreSQL instance. Adjust shared_buffers, max_connections, and other parameters through the FoundryDB configuration API.

curl -u admin:password -X PATCH \
  https://api.foundrydb.com/managed-services/{id}/configuration \
  -H "Content-Type: application/json" \
  -d '{
    "parameters": {
      "max_connections": "200",
      "shared_buffers": "2GB"
    }
  }'

Feature Matrix​

FoundryDB's Babelfish service includes the same operational features as other engines on the platform:

When Babelfish Is the Right Choice​

Babelfish works best for applications where the T-SQL surface area is standard CRUD, reporting, and stored procedure logic. If your codebase avoids CLR integration, linked servers, and SQL Server Agent, the migration path is clean.

For applications that depend heavily on SQL Server-specific features, a full PostgreSQL rewrite may still be the better long-term investment. Babelfish gives you a middle ground: move off SQL Server licensing today, then gradually shift T-SQL code to native PostgreSQL syntax at your own pace.

Get Started​

Provision a Babelfish service on FoundryDB and run your T-SQL workload against it. The dual-protocol access means you can test without touching your application code.

• Babelfish documentation on FoundryDB
• API reference
• Create a free account

But automated daily backups are only half the story. For PostgreSQL, MySQL, and MongoDB, FoundryDB continuously archives write-ahead logs (WAL), binary logs (binlog), or oplogs to enable point-in-time recovery (PITR). This means you can restore to any specific second within a 7-day window, not just to the last daily snapshot.

This post covers how backups work across all engines, how to trigger and restore them, and how to use PITR to recover from the kind of mistakes that daily snapshots cannot fix.

How Backups Work Per Engine​

FoundryDB uses the native backup tooling for each database engine. This is intentional. Native tools are the most reliable, best-tested path for each engine, and they integrate with the engine's own consistency guarantees.

For PostgreSQL, pgBackRest handles full and incremental backups with built-in verification, parallelism, and encryption. WAL segments are archived continuously to S3, so the recovery window extends from the last full backup to the most recent archived WAL segment.

For MySQL, a logical dump captures the schema and data, while binlog archiving captures every write operation between dumps. Restore replays the dump, then applies binlogs up to the target timestamp.

For MongoDB, mongodump captures a consistent snapshot of all collections, and oplog archiving captures the stream of write operations. PITR replays the oplog from the dump point to the target time.

Backup Encryption​

All backups are encrypted with AES-256-GCM before leaving the database server. Each backup gets a unique encryption key. Keys rotate automatically every 90 days. Object storage adds a second layer of server-side encryption for defense in depth.

You do not need to configure encryption. It is always on.

# Verify encryption status on any backup
curl -u $API_KEY:$API_SECRET \
  https://api.foundrydb.com/managed-services/{id}/backups/{backup_id} \
  | jq '{encrypted: .encryption_enabled, algorithm: .encryption_algorithm}'

{"encrypted": true, "algorithm": "AES-256-GCM"}

Triggering an On-Demand Backup​

Automated backups run daily, but you can trigger a manual backup at any time. This is useful before a risky schema migration, a bulk data load, or a major application deployment.

curl -u $API_KEY:$API_SECRET -X POST \
  https://api.foundrydb.com/managed-services/{id}/backups \
  -H "Content-Type: application/json" \
  -d '{"backup_type": "manual"}'

{
  "id": "bkp_m7x2k9",
  "backup_type": "manual",
  "status": "in_progress",
  "created_at": "2026-04-06T15:30:00Z"
}

Manual backups are retained until you explicitly delete them. Automated backups follow the 7-day retention policy.

Listing Backups​

curl -u $API_KEY:$API_SECRET \
  https://api.foundrydb.com/managed-services/{id}/backups

{
  "backups": [
    {
      "id": "bkp_abc123",
      "backup_type": "automated",
      "status": "completed",
      "size_bytes": 1073741824,
      "created_at": "2026-04-06T02:00:00Z"
    },
    {
      "id": "bkp_m7x2k9",
      "backup_type": "manual",
      "status": "completed",
      "size_bytes": 1073741824,
      "created_at": "2026-04-06T15:30:00Z"
    }
  ]
}

Point-in-Time Recovery​

Daily backups protect against hardware failure and data corruption. PITR protects against the other kind of disaster: human error. Someone runs DELETE FROM orders without a WHERE clause at 14:32:17. With daily backups, you lose everything since the last snapshot. With PITR, you restore to 14:32:16 and lose nothing.

How PITR Works​

PITR combines two pieces: a base backup (the most recent full snapshot) and a continuous stream of change records (WAL segments, binlogs, or oplog entries). To restore to a specific point in time, FoundryDB restores the base backup and then replays the change stream up to the exact target timestamp.

The PITR window on FoundryDB is 7 days. WAL, binlog, and oplog archives are retained for 7 days, so you can restore to any second within that window.

Restoring to a Specific Time​

Restoring always creates a new service. Your existing service keeps running undisturbed.

curl -u $API_KEY:$API_SECRET -X POST \
  https://api.foundrydb.com/managed-services/{id}/backups/restore \
  -H "Content-Type: application/json" \
  -d '{
    "restore_point": "2026-04-06T14:32:16Z",
    "target_service_name": "orders-db-restored",
    "plan_name": "tier-2",
    "zone": "se-sto1"
  }'

The restored service provisions a new VM, restores the base backup, replays the change stream to the specified timestamp, and starts accepting connections. Depending on database size, this takes 5 to 30 minutes.

Restoring from a Specific Backup​

If you want to restore from a particular daily or manual backup rather than a point in time:

curl -u $API_KEY:$API_SECRET -X POST \
  https://api.foundrydb.com/managed-services/{id}/backups/{backup_id}/restore \
  -H "Content-Type: application/json" \
  -d '{
    "target_service_name": "orders-db-from-backup",
    "plan_name": "tier-2",
    "zone": "se-sto1"
  }'

Monitoring Restore Progress​

curl -u $API_KEY:$API_SECRET \
  https://api.foundrydb.com/managed-services/{restored_service_id} \
  | jq '{name: .name, status: .status}'

Watch the status field transition from pending to provisioning to running. Once the status is running, your restored database is ready to accept connections.

Testing Your Backups​

A backup you have never restored is a backup you cannot trust. FoundryDB makes it easy to test restores because every restore creates a new, independent service. There is no risk to your production data.

A simple monthly practice:

1. Trigger a manual backup of your production service.
2. Restore it to a new service with a test name.
3. Connect to the restored service and run validation queries against your data.
4. Delete the test service when you are done.

# 1. Trigger manual backup
curl -u $API_KEY:$API_SECRET -X POST \
  https://api.foundrydb.com/managed-services/{id}/backups \
  -H "Content-Type: application/json" \
  -d '{"backup_type": "manual"}'

# 2. Restore to a test service (use the backup ID from step 1)
curl -u $API_KEY:$API_SECRET -X POST \
  https://api.foundrydb.com/managed-services/{id}/backups/{backup_id}/restore \
  -H "Content-Type: application/json" \
  -d '{
    "target_service_name": "monthly-restore-test",
    "plan_name": "tier-2",
    "zone": "se-sto1"
  }'

# 3. Validate data on the restored service
PGPASSWORD=restored_pass psql \
  "host=monthly-restore-test.foundrydb.com user=app_user dbname=defaultdb sslmode=verify-full" \
  -c "SELECT count(*) FROM orders;"

# 4. Clean up
curl -u $API_KEY:$API_SECRET -X DELETE \
  https://api.foundrydb.com/managed-services/{restored_service_id}

This costs only the compute time for the restored service (minutes, not hours) and gives you confidence that your backups are actually recoverable.

Retention Policies​

Manual backups are never automatically deleted. If you create manual backups before deployments, remember to clean up old ones periodically:

curl -u $API_KEY:$API_SECRET -X DELETE \
  https://api.foundrydb.com/managed-services/{id}/backups/{backup_id}

Disaster Recovery Checklist​

Before you need to restore in a real incident, prepare now:

1. Test restores regularly. Restore to a new service and verify your data. Monthly is a good cadence.
2. Verify PITR is active. Check your service metrics to confirm WAL/binlog/oplog archiving is running continuously.
3. Document your RTO and RPO. Know how long a restore takes for your database size and how much data loss you can tolerate.
4. Take manual backups before risky operations. Schema migrations, bulk deletes, and version upgrades all warrant a pre-change backup.
5. Keep your allowed_cidrs updated. A restored service inherits the source service's network rules. Make sure your application can connect.

What's Next​

Backups and PITR are available on every FoundryDB service with no additional configuration. If you are running a database that matters, take 10 minutes to test a restore today. The best time to discover a problem with your backup strategy is before you need it.

Read the full Backups and Restore documentation for API details and per-engine specifics. If you are not yet on FoundryDB, create your first service and see automated backups working within minutes.

FoundryDB supports blue-green deployments as a first-class maintenance operation. You can validate prerequisites, provision a parallel green environment, let replication sync the data, and switchover when you are confident. If something goes wrong before or after the switch, you roll back.

Why Blue-Green Instead of Rolling Updates​

Rolling updates upgrade one node at a time within your existing cluster. They work well for minor version bumps and configuration changes, and FoundryDB supports them with pause/resume controls. But rolling updates have limitations:

The tradeoff is straightforward. Blue-green costs more during the transition (you are running two environments), but gives you a safety net that rolling updates cannot match. For production databases where even a 60-second failover is unacceptable, blue-green is the right choice.

How It Works on FoundryDB​

A blue-green deployment on FoundryDB follows a six-state lifecycle:

Running → BlueGreenCreating → BlueGreenSyncing → BlueGreenReady → BlueGreenSwitching → BlueGreenCleaning → Running

1. Creating. FoundryDB provisions a new "green" VM with the target database version. Same compute plan, same storage tier, same configuration as your live "blue" environment.
2. Syncing. Streaming replication starts from blue to green. All writes to the blue environment are continuously replicated to the green environment.
3. Ready. Once replication lag drops below your configured threshold (default: 5000 ms), the deployment enters the ready state. You can now inspect the green environment and run validation queries.
4. Switching. You trigger the switchover. DNS records update to point to the green environment. This is atomic: your connection strings do not change.
5. Cleaning. The old blue environment is retained briefly for rollback, then automatically cleaned up.
6. Running. The service returns to normal operation on the new environment.

At any point before the switchover completes, you can roll back. Traffic returns to the original blue environment and the green environment is torn down.

Step 1: Validate Prerequisites​

Before starting a deployment, check whether your service supports blue-green for the target version. The validate endpoint returns a clear pass/fail result with specific error messages if something blocks the deployment.

curl -u user:password -X POST \
  https://api.foundrydb.com/managed-services/{id}/blue-green/validate \
  -H "Content-Type: application/json" \
  -d '{"target_version": "17.7"}'

A successful validation returns:

{
  "valid": true,
  "warnings": [],
  "errors": [],
  "current_version": "17.3",
  "target_version": "17.7",
  "database_type": "postgresql",
  "upgrade_type": "minor",
  "replication_mode": "streaming"
}

The validation checks four things: that your service is in Running state, that no other maintenance operation is already active, that the version increment is sequential (no skipping, e.g., 15 to 17), and that the database engine supports the deployment type.

Known limitation: Major version blue-green (e.g., PostgreSQL 16 to 17) is not yet supported for PostgreSQL and MySQL. Streaming replication cannot work across major versions due to WAL/binlog format incompatibility. Logical replication support is planned for a future release. For major version upgrades on these engines, use the in-place pg_upgrade or mysql_upgrade paths instead.

Step 2: Create the Deployment​

Once validation passes, create the blue-green deployment:

curl -u user:password -X POST \
  https://api.foundrydb.com/managed-services/{id}/blue-green \
  -H "Content-Type: application/json" \
  -d '{
    "target_version": "17.7",
    "replication_lag_ms": 5000
  }'

The response returns a deployment ID and confirms the service is transitioning:

{
  "id": "6fa85f64-5717-4562-b3fc-2c963f66afa6",
  "service_id": "a1b2c3d4-...",
  "status": "in_progress",
  "target_version": "17.7",
  "replication_lag_ms": 5000,
  "created_at": "2026-04-06T14:30:00Z"
}

The replication_lag_ms parameter controls how close the green environment must be to the blue environment before the deployment is considered ready for switchover. Lower values mean tighter consistency but may take longer to stabilize under heavy write loads. The minimum is 100 ms.

You can also schedule deployments for a future maintenance window by adding scheduled_at:

curl -u user:password -X POST \
  https://api.foundrydb.com/managed-services/{id}/blue-green \
  -H "Content-Type: application/json" \
  -d '{
    "target_version": "17.7",
    "replication_lag_ms": 1000,
    "scheduled_at": "2026-04-10T02:00:00Z"
  }'

Step 3: Monitor and Validate​

Poll the deployment status to track replication progress:

curl -u user:password \
  https://api.foundrydb.com/managed-services/{id}/blue-green/{deployment-id}

Once the status shows ready (the BlueGreenReady state), the green environment is fully synced. This is your window to run any validation you need: connect to the green service, run test queries, verify that your application logic works against the new version.

Step 4: Switchover​

When you are satisfied that the green environment is correct, trigger the switchover:

curl -u user:password -X PUT \
  https://api.foundrydb.com/managed-services/{id}/blue-green/{deployment-id}/switchover

The service must be in BlueGreenReady state. If it is not (for example, if replication has not caught up), the API returns a 409 Conflict with the current state.

After switchover, DNS records are updated to point to the green environment. Your application's connection strings remain the same. The old blue environment is retained briefly, then cleaned up automatically.

Rollback​

If something goes wrong before or after the switchover (but before cleanup completes), roll back:

curl -u user:password -X PUT \
  https://api.foundrydb.com/managed-services/{id}/blue-green/{deployment-id}/rollback

Traffic re-points to the original blue environment and the green environment is torn down. Rollback is not available after the deployment reaches completed or cancelled status.

To cancel a deployment that has not yet switched over (for example, if you decide not to proceed during the validation phase), use the cancel endpoint instead:

curl -u user:password -X DELETE \
  https://api.foundrydb.com/managed-services/{id}/blue-green/{deployment-id}

This cleans up the green environment and returns the service to Running.

When to Use Each Strategy​

Use rolling updates when:

• Applying configuration changes across your cluster
• Performing minor version patches on multi-node services
• You can tolerate a brief failover (~60 seconds) during primary promotion
• Minimizing temporary resource cost matters

Use blue-green deployments when:

• Zero downtime is a hard requirement
• You want to validate the target version before committing
• You need the ability to roll back instantly after switchover
• You are performing same-version maintenance (VM replacement, OS patching via a fresh environment)

Both strategies are available for the same service. You can use rolling updates for routine patches and reserve blue-green for higher-stakes upgrades.

Get Started​

Blue-green deployments are available on all FoundryDB database engines that support streaming replication: PostgreSQL, Valkey, MongoDB, and Kafka. Start by validating your target version, then create your first blue-green deployment.

Read the full Maintenance & Upgrades documentation for details on maintenance windows, rolling updates, and version upgrade paths. Or create a free FoundryDB account and try it on a test service.

In 2026, RAG is no longer experimental. It powers customer support bots, internal knowledge search, legal document analysis, and code assistants at thousands of companies. The architecture has stabilized around a common pattern: ingest documents, generate embeddings, store vectors, retrieve at query time. What varies is how well you operate the infrastructure underneath.

This post walks through building a production RAG pipeline on FoundryDB using PostgreSQL with pgvector, Kafka for document ingestion, and Valkey for result caching.

Architecture Overview​

The pipeline has four stages:

1. Ingest: Documents arrive via Kafka topics. Producers can be web scrapers, file upload handlers, or webhook receivers.
2. Embed: A consumer reads from Kafka, chunks the documents, calls an embedding API (OpenAI, Cohere, or a local model), and writes vectors to PostgreSQL.
3. Store: PostgreSQL with pgvector stores embeddings alongside metadata. HNSW indexes enable sub-millisecond approximate nearest neighbor search.
4. Query: At query time, the user's question is embedded, similar vectors are retrieved from PostgreSQL, and the results (plus the original question) are sent to the LLM. Valkey caches frequent queries to reduce latency and cost.

┌──────────┐    ┌───────┐    ┌────────────────────┐    ┌────────┐
│ Documents├───►│ Kafka ├───►│ PostgreSQL pgvector │◄───┤ App/LLM│
└──────────┘    └───────┘    └────────────────────┘    └───┬────┘
                                                           │
                                                      ┌────▼────┐
                                                      │  Valkey  │
                                                      │ (cache)  │
                                                      └─────────┘

Deploying the Services​

Create all three services using the FoundryDB CLI. Each service is production-ready with TLS, automated backups, and monitoring out of the box.

# PostgreSQL with pgvector enabled
fdb services create \
  --name rag-vectors \
  --engine postgresql \
  --version 17 \
  --plan tier-4 \
  --storage 100 \
  --storage-tier maxiops \
  --zone eu-helsinki \
  --preset pgvector

# Kafka for document ingestion
fdb services create \
  --name rag-ingest \
  --engine kafka \
  --version 3.9 \
  --plan tier-4 \
  --storage 200 \
  --zone eu-helsinki

# Valkey for query result caching
fdb services create \
  --name rag-cache \
  --engine valkey \
  --version 8.1 \
  --plan tier-2 \
  --storage 20 \
  --zone eu-helsinki

The --preset pgvector flag automatically enables the pgvector extension on your PostgreSQL instance. All three services deploy in the same EU zone, keeping inter-service latency under 1ms.

Setting Up the Vector Store​

Once PostgreSQL is running, create your embeddings table and index. The schema stores the embedding vector, the original text chunk, and metadata for filtering.

-- Enable pgvector (already done if you used the pgvector preset)
CREATE EXTENSION IF NOT EXISTS vector;

-- Embeddings table: 1536 dimensions for OpenAI text-embedding-3-small
CREATE TABLE embeddings (
    id          bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    content     text NOT NULL,
    metadata    jsonb NOT NULL DEFAULT '{}',
    embedding   vector(1536) NOT NULL,
    created_at  timestamptz NOT NULL DEFAULT now()
);

-- HNSW index for approximate nearest neighbor search
-- m=24 and ef_construction=200 are good defaults for 1M+ vectors
CREATE INDEX idx_embeddings_hnsw ON embeddings
    USING hnsw (embedding vector_cosine_ops)
    WITH (m = 24, ef_construction = 200);

-- Metadata index for filtered queries
CREATE INDEX idx_embeddings_metadata ON embeddings USING gin (metadata);

Kafka Topic for Document Ingestion​

Create a topic for incoming documents. Using multiple partitions allows parallel processing by embedding workers.

# Get Kafka connection details
fdb services get rag-ingest --format json | jq '.connection_info'

# Create the documents topic with 6 partitions
fdb kafka topics create \
  --service rag-ingest \
  --name documents \
  --partitions 6 \
  --replication-factor 1 \
  --config retention.ms=604800000

Here is a Python consumer that reads documents from Kafka, generates embeddings, and stores them in PostgreSQL:

import json
from kafka import KafkaConsumer
from openai import OpenAI
import psycopg

# Initialize clients
openai_client = OpenAI()
pg_conn = psycopg.connect("postgresql://user:pass@rag-vectors.foundrydb.com/defaultdb?sslmode=verify-full")

consumer = KafkaConsumer(
    "documents",
    bootstrap_servers="rag-ingest.foundrydb.com:9093",
    security_protocol="SASL_PLAINTEXT",
    sasl_mechanism="SCRAM-SHA-256",
    sasl_plain_username="app_user",
    sasl_plain_password="your-password",
    value_deserializer=lambda m: json.loads(m.decode("utf-8")),
    group_id="embedding-workers",
)

def chunk_text(text: str, max_tokens: int = 512) -> list[str]:
    """Split text into overlapping chunks."""
    words = text.split()
    chunks = []
    for i in range(0, len(words), max_tokens - 50):
        chunk = " ".join(words[i:i + max_tokens])
        if chunk:
            chunks.append(chunk)
    return chunks

for message in consumer:
    doc = message.value
    chunks = chunk_text(doc["content"])

    # Batch embed all chunks
    response = openai_client.embeddings.create(
        model="text-embedding-3-small",
        input=chunks
    )

    # Bulk insert into PostgreSQL
    with pg_conn.cursor() as cur:
        for chunk, emb_data in zip(chunks, response.data):
            cur.execute(
                """INSERT INTO embeddings (content, metadata, embedding)
                   VALUES (%s, %s, %s::vector)""",
                (chunk, json.dumps(doc.get("metadata", {})), emb_data.embedding)
            )
    pg_conn.commit()

Querying with Caching​

The query path embeds the user's question, searches PostgreSQL for similar vectors, and caches the result in Valkey. Subsequent identical queries return instantly from cache.

import hashlib
import json
import valkey
import psycopg
from openai import OpenAI

openai_client = OpenAI()
pg_conn = psycopg.connect("postgresql://user:pass@rag-vectors.foundrydb.com/defaultdb?sslmode=verify-full")
cache = valkey.Valkey(
    host="rag-cache.foundrydb.com", port=6380,
    username="app_user", password="your-password", ssl=True
)

def search(query: str, top_k: int = 5, cache_ttl: int = 3600) -> list[dict]:
    # Check cache first
    cache_key = f"rag:{hashlib.sha256(query.encode()).hexdigest()}"
    cached = cache.get(cache_key)
    if cached:
        return json.loads(cached)

    # Embed the query
    response = openai_client.embeddings.create(
        model="text-embedding-3-small",
        input=[query]
    )
    query_vec = response.data[0].embedding

    # Similarity search via pgvector
    with pg_conn.cursor() as cur:
        cur.execute(
            """SELECT content, metadata,
                      1 - (embedding <=> %s::vector) AS similarity
               FROM embeddings
               ORDER BY embedding <=> %s::vector
               LIMIT %s""",
            (query_vec, query_vec, top_k)
        )
        results = [
            {"content": row[0], "metadata": row[1], "similarity": float(row[2])}
            for row in cur.fetchall()
        ]

    # Cache results
    cache.set(cache_key, json.dumps(results), ex=cache_ttl)
    return results

Performance: IVFFlat vs HNSW​

pgvector supports two index types. Choosing the right one depends on your dataset size and query pattern.

For most RAG applications, HNSW is the right choice. The recall difference matters: at 95% recall, 1 in 20 queries misses a relevant chunk. At 99%+, missed context is rare.

Two tuning parameters to know:

• ef_search (HNSW): higher values increase recall at the cost of latency. Default is 40; set to 100-200 for production RAG.
• Parallel query: enable SET max_parallel_workers_per_gather = 4 for similarity searches across large tables.

-- Tune HNSW search quality (set per session or in postgresql.conf)
SET hnsw.ef_search = 150;

-- Enable parallel workers for large scans
SET max_parallel_workers_per_gather = 4;

Why This Stack Works​

This architecture handles the full RAG lifecycle without duct tape:

• Kafka decouples document ingestion from embedding generation. You can scale embedding workers independently, replay failed batches, and add new document sources without changing downstream code.
• PostgreSQL pgvector stores vectors alongside your relational data. No need for a separate vector database. You can join embeddings with user tables, filter by metadata using standard SQL, and use transactions for consistency.
• Valkey eliminates redundant embedding API calls and database queries. A 1-hour TTL on cached results cuts costs significantly for repeated queries.
• FoundryDB handles the operational overhead: automated backups, TLS everywhere, monitoring, and all three services in one dashboard.

Next Steps​

Deploy this pipeline on FoundryDB and start indexing your documents. The quick start guide covers creating your first service, and the PostgreSQL documentation has details on pgvector configuration and tuning.

For production deployments, consider adding read replicas to your PostgreSQL service for query scaling, and enabling Kafka's multi-node mode for ingestion high availability.

Connection pooling sits between your application and the database, multiplexing many client connections over a small number of backend connections. FoundryDB provides PgBouncer for PostgreSQL and ProxySQL for MySQL, both managed through the API with no manual SSH or config file editing required.

Why Connection Pooling Matters​

Without a pooler, every application process (every serverless function invocation, every container replica, every worker thread) opens its own connection to the database. This creates two problems:

• Connection overhead. Each backend connection consumes memory and CPU regardless of whether it is actively running a query. At scale, you hit max_connections limits before you hit actual query throughput limits.
• Connection storms. When an application scales horizontally (auto-scaling containers, Lambda cold starts), dozens of connections open simultaneously. The database spends more time authenticating and forking processes than answering queries.

A pooler solves both by maintaining a fixed pool of backend connections and assigning them to client requests on demand. Your application can open 5,000 client connections while the database sees only 50 active backends.

PgBouncer for PostgreSQL​

PgBouncer runs on every node of your PostgreSQL service, listening on port 6432. Enable it with a single API call.

Enabling PgBouncer​

curl -u user:password -X POST \
  https://api.foundrydb.com/managed-services/{serviceId}/pooler/enable \
  -H "Content-Type: application/json" \
  -d '{
    "database_name": "defaultdb",
    "database_user": "app_user",
    "pool_mode": "transaction",
    "default_pool_size": 25,
    "max_client_conn": 2000
  }'

The database_user must be an existing application user (create one via the Users API first). Superuser accounts like postgres and internal system users are blocked for security.

The response returns a list of task_ids, one per node. PgBouncer is ready once all tasks reach completed status.

Pool Modes​

The pool_mode parameter controls when a backend connection is returned to the pool.