We are very intentionally not a BaaS

Different job, different tool

Supabase and Firebase exist for BaaS-style workflows: auth, file storage, edge functions, realtime subscriptions, client SDKs, row-level-security-as-API. D1 and Neon exist for edge-shaped database stories. These are good products solving real problems, and if those are your problems, use them.

CapyDB is the answer to a simpler question: can I just have managed Postgres without adopting a whole platform?

That narrower scope is not a compromise we are talking ourselves into. It is the point.

What adopting a platform actually costs

A BaaS earns its keep by being your auth, your storage, your API layer, and your database at once. Which means it is also your auth migration, your storage migration, your API rewrite, and your database migration if you ever leave — simultaneously. The pieces are designed to be greater than the sum of their parts, and the coupling is the price of that.

There is also a quieter cost: every feature of the platform you do not use still shapes the ones you do. The dashboard, the pricing, the docs, the failure modes — all sized for the whole platform, not for your slice of it.

If you have a backend already — Next.js, Rails, Django, Go, whatever — you do not need a backend-as-a-service. You need the database part to be excellent and the rest of your stack to remain yours.

What we ship instead

The full list, with no asterisks:

• Direct and pooled Postgres connections — standard protocol, standard drivers, TLS required
• Disposable preview databases with TTLs
• Backups, restores, and point-in-time recovery, including restore-into-a-preview so you can look before you overwrite
• Imports from existing Postgres sources, with a preflight that grades the migration before anything destructive happens
• Organization and project-scoped API keys, signed webhooks, and Vercel/Netlify integrations that keep DATABASE_URL current

Notice what is on the list: a database and the operational workflows around a database. Notice what is not: your auth, your storage, your functions, your client SDK.

Where the line is

When using a BaaS, the auth, storage, and functions integrate beautifully with the database — that is the value. With CapyDB, your auth is Clerk or Auth0 or your own, your storage is S3 or R2, your functions are your deployment platform's — and they all talk to the database the way they would talk to any Postgres: with a connection string. (We will happily sync your Clerk users into a plain Postgres table so emails become a JOIN — but the table is yours, in your schema, nothing proprietary to query through.)

If you want the platform experience, genuinely: pick a platform. If you want your stack to stay yours and the database to be somebody's whole job, that somebody is us.