Bring Your Own Database

Store your agents, calls, and knowledge in your own PostgreSQL — full data sovereignty and EU data residency.

What is BYODB?

By default, all tenant data (agents, calls, knowledge, messages) is stored in CustomWeb Agents's managed Supabase PostgreSQL. BYODB lets you point the platform at your own PostgreSQL database instead, so your data never leaves infrastructure you control.

This matters for:

  • EU data residency — data stays in an EU-hosted database you own.
  • Enterprise security — your DBA audits every schema change; your backup policy governs retention.
  • Data portability — export or query your data directly without going through any API.
Note · BYODB stores tenant operational data (agents, calls, knowledge). It does not move routing data (your business record, API keys, integrations config, billing). Those always stay in the platform DB because they're needed to locate your custom DB.

Supported databases

Any standard PostgreSQL 14+ database over a standard connection URL is supported. Tested providers:

ProviderHow to get a connection URLNotes
SupabaseProject Settings → Database → Connection string → URI tab (use the Session Pooler URL on port 5432)Choose the session-mode pooler URL; transaction-mode pooler has connection-count limits that can interrupt long operations.
NeonDashboard → Project → Connection Details → Connection stringEnable the connection pooler (PgBouncer) for production. Disable it for the initial schema provision if you see "prepared statement already exists" errors.
RailwayProject → Postgres service → Variables tab → DATABASE_URLRailway uses TLS by default; the URL includes sslmode=require automatically.
Render PostgresDashboard → your PostgreSQL instance → Info → Connections → External Database URLUse the External URL (not Internal) unless you're also hosting the app on Render in the same VPC.
Any PostgreSQLpostgresql://user:password@host:5432/dbnameMust be reachable from the internet (or your hosting provider's IP ranges). Add sslmode=require for TLS.
Important · MySQL, PlanetScale, MongoDB, and other non-PostgreSQL databases are not supported — the schema uses PostgreSQL-specific features (UUIDs, JSONB, enum types, partial indexes).

Connecting your database

  1. Go to Dashboard → Integrations. Find Custom Database (BYODB) in the Storage & Privacy section and click it.
  2. Read the data migration warning — existing data stays archived on CustomWeb's servers (see below).
  3. Paste your PostgreSQL connection URL into the URL field.
  4. Click Test connection to verify the platform can reach your database (runs a SELECT 1 probe — no writes).
  5. Once the test passes, click Connect & Provision. The platform will run the full schema DDL inside a PostgreSQL transaction, creating all required tables, indexes, and enum types. This takes a few seconds.
  6. Done. All new data (agents you create, calls that happen, documents you upload) will be written to your database.
Note · The connection URL is encrypted with AES-256-GCM before storage. It is never logged or exposed to the browser.

What gets provisioned

On first connect, the platform runs a versioned DDL migration that creates the full operational schema in your database. The tables created include:

  • Assistant, AssistantVersion — agent configs and version history
  • Call, Message — call records and transcript messages
  • KnowledgeBase, KnowledgeDocument, KnowledgeSource, KnowledgePortalUser — KB infrastructure
  • Tool, WorkflowGraph, WorkflowNode, WorkflowEdge — tools and workflow definitions
  • UsageEvent, Event — billing ledger and audit trail
  • TestSuite, EvalRun, EvalCase — automated test infrastructure

A special table `_byodb_meta` is created to track which migration version has been applied. The platform uses this to apply incremental DDL updates automatically as the schema evolves — you never need to run migrations manually.

Tip · The DDL runs inside a PostgreSQL transaction. If any statement fails, the entire migration rolls back cleanly and your database is left unchanged. The connection error is surfaced in the UI.

Data migration and the blank-slate rule

When you connect a custom database, existing data (agents, calls, knowledge) is NOT automatically migrated from the platform database to your database. That data stays archived on CustomWeb's servers.

Why: automated data migration across databases is a destructive, difficult-to-reverse operation. We don't do it automatically to protect you from data loss.

What this means in practice:

  • You will see a "fresh" dashboard after connecting — no agents, no calls, no knowledge (they are still archived on the platform DB).
  • New agents you create go into your database. Old ones stay on the platform DB and are accessible if you disconnect later.
  • The Integrations panel shows the date BYODB was activated — agents created before vs after that date can be reconciled manually if needed.
Tip · If you need a full data export before connecting, use Settings → Privacy & data → Export data. This gives you a complete JSON bundle of all your data in the current platform DB.

Disconnecting

To revert to the platform database: Integrations → Custom Database → Disconnect. The platform stops writing to your database immediately. New data routes to the platform DB. Data already in your database is not deleted.

Important · After disconnecting, your own PostgreSQL still holds all the data that was written while BYODB was active. The platform DB does not automatically import it back. If you want to reconcile both datasets, use the v1 REST API to export from your DB and re-import to the platform.

Platform setup (self-hosted / white-label operators)

If you operate CustomWeb Agents as a white-label platform, BYODB requires one env var to be set in your deployment:

VariableValueRequired
SETTINGS_ENCRYPTION_KEY32-byte hex string (64 hex chars) — generate with: openssl rand -hex 32Yes — without this, connection URLs cannot be encrypted and the connect endpoint will refuse requests.
# Generate a fresh encryption key (run once, store the output):
openssl rand -hex 32

Add it to your deployment environment (Vercel → Project Settings → Environment Variables, or your Render/Railway service's env section). It must be the same value across all deployments — changing it will make existing encrypted URLs unreadable.

Important · The encryption key is a platform secret, not a per-business secret. It should only be accessible to your deployment infrastructure, never to end users.