A small product surface is a feature

The whole product fits in a sentence

CapyDB is managed Postgres with previews, backups and restores, imports, and the connective tissue — keys, webhooks, integrations — to wire it into a deployment. That is the product. You just read all of it.

This is not modesty. It is the design decision everything else falls out of, and it is worth explaining why we keep making it on purpose.

Less product theater

A lot of infrastructure products keep expanding until the database is just one tile in a much bigger platform story. Each new tile is pitched as convenience, and each one is also: a new dashboard section, a new pricing dimension, a new set of failure modes, a new thing the docs have to explain, and a new dependency your application quietly grows.

CapyDB goes the other way. The database is the product. Everything else exists to make using that database easier — and has to justify itself against the question "does this help someone run Postgres, or does it help us look bigger?"

The features that survived that question are the operational ones people actually reach for under pressure: a restore that can land in a throwaway preview before it touches production, an import preflight that says no before anything breaks, credential rotation that re-pushes env vars to Vercel and Netlify so nothing goes stale.

More portability

There is no proprietary driver, no SDK requirement, no query layer. You connect with the same postgres:// URL shape and the same clients you would use against any Postgres — psql, pg, pgx, psycopg, Prisma, ActiveRecord. The framework guides are short because there is almost nothing CapyDB-specific to say in them, which is the point.

That cuts both ways, deliberately. pg_dump over the direct connection works like it does anywhere, so leaving CapyDB is exactly as easy as arriving. If your app already works with Postgres, CapyDB should feel like a hosting decision, not a rewrite — and a hosting decision you can reverse.

Honest boundaries

Smaller scope also makes the messaging better, because we can state the edges without squinting. We can say exactly what the product does, exactly who it is for, and exactly which adjacent categories it is not trying to replace — there is a whole post about that. The docs carry the same posture: the limits page has actual numbers in it, the security page lists the badges we have not earned, and the disaster recovery page tells you failover is a human, not a magic toggle.

A small surface is what makes that honesty affordable. You can only document every sharp edge of a product you can still see all of.

What you get out of it

Onboarding is reading one quickstart. Debugging is debugging Postgres, which the entire internet knows how to do. Migration in either direction is a dump and a restore. And when something does go wrong, the set of components that could be responsible is short enough to actually enumerate.

Every layer we did not build is a layer you will never have to learn, work around, or rip out later. We intend to keep not building them.