About CapyDB

Why CapyDB exists

Because most builders do not need a full backend platform, a proprietary database API, or a brand-new infrastructure philosophy. They need Postgres.

So we reduced managed Postgres to one primitive: the database cell - an isolated Postgres runtime with its own process, storage, credentials, and CPU/RAM limits, dedicated to a single project. The API manages cells; you use normal Postgres URLs.

Everything else in the product is the lifecycle around that primitive: provisioning, direct and pooled connections, preview databases, backups, imports, restores, and extensions.

Who it is for

• >>Vibe coders turning a weekend build into a real app
• >>Hackers and tinkerers who want a connection string, not a ceremony
• >>Indie hackers and small teams shipping fast
• >>Teams that want the database boring and the stack their own

What we optimize for

• >>Isolation: every project in its own cell - process, credentials, storage quota, CPU, and memory
• >>Simplicity: standard postgres:// connections and normal tooling
• >>Performance: direct and pooled access with a lean control plane
• >>Reliability: verified backups, point-in-time restore, disposable previews, and predictable workflows

What we are not trying to be

Not a BaaS. If you want auth, storage, functions, and the whole kitchen sink, use a product built for that.

Not an exotic storage rewrite either. Real Postgres processes on real hardware, isolated per project - engineering effort spent on making one primitive excellent instead of making many features exist.