Documentation
CapyDB is managed Postgres built on one primitive - the isolated database cell. Standard direct and pooled connections, disposable previews, backups and PITR restores, imports, integrations, webhooks, and a real API. No proprietary SDK required.
One primitive: the database cell
Every project runs in its own database cell - an isolated Postgres runtime with a dedicated process, storage, credentials, network boundary, and CPU/RAM limits. Not a schema on a shared server. The API manages the cell lifecycle; you use normal Postgres URLs. How the cell works →
What you actually get
- Standard
postgres://connections for direct and pooled access, with Postgres 16, 17, or 18 selected per database (17 by default) - One isolated database cell per project, grouped under organizations
- Disposable preview databases with empty or clone modes and TTL cleanup
- On-demand and scheduled backups, point-in-time restores, and pinned restore points
- Imports from any reachable Postgres, with a preflight that tells you up front whether the import will work
- 14 allowlisted Postgres extensions - pgvector and PostGIS included - manageable per database from the dashboard, API, and CLI
- Usage threshold alerts on storage and connections, delivered to the dashboard, webhooks, and email
- Deployment integrations for Vercel and Netlify, user sync from Clerk, Auth0, or Better Auth into your own database, and a GitHub Action for preview databases per PR
- Outbound webhooks, org and project-scoped API keys, an audit log, Studio (SQL runner and table browser), and live metrics
- A CLI, a TypeScript SDK, an MCP server, a Terraform provider, and an OpenAPI-documented HTTP API
Why the surface stays small
CapyDB is intentionally boring in the best way. You get Postgres plus the few workflows that keep shipping teams out of trouble.
The goal is to let you keep your existing stack and swap infrastructure, not force a new way of writing apps. Everything in these docs works against plain Postgres connections and a plain HTTP API.
How operations run
Lifecycle actions - provisioning, backups, restores, imports, preview create/reset/delete, credential rotation - are asynchronous jobs. The API answers 202 Accepted with a job object you can poll until it reaches completed or failed. The dashboard, CLI (--wait), SDK, and GitHub Action all wrap this for you.
Current deployment model
The current v1 layout runs the control plane, worker, metadata database, and customer Postgres on dedicated single-tenant EU cloud infrastructure. Human authentication is handled by Clerk; programmatic access uses API keys. Plans (Vibe, Ship, Business) are billed per organization through Polar.