Your vibe-coded database is a mess (mine was too)

Quick confession: I love vibe coding. I've shipped more products in the last two years with AI than in the ten years before that. But there's a dirty little secret nobody posts about — while your frontend looks fantastic, your database is quietly turning into a crime scene.

How the drift happens #

You prompt your way through feature after feature, and every session the AI "helpfully" adds a column here, a table there, a slightly different naming convention everywhere. You rename a table, change your mind, change it back, forget which version the app actually uses. Three weeks later you have users, user_data and userProfiles plus a couple of orphaned tables you're afraid to touch. That's schema drift, it's a given (see what I did there?), and every vibe-coded project has it. I know because it happened to me while building MyRoomie v3, and I figured maybe I'm not the only startupper struggling with this.

So I built Capysquash #

Because I'm extra, instead of just fixing my own database I built a tool: Capysquash. It's written in Go — same language as pgquery, Postgres's official parser — and it's deterministic at its core, which matters: you don't want an AI guessing how to fix what another AI broke. You throw your migration files at it, it tracks every object, mutation and extension (including third-party stuff like Supabase, Clerk, Drizzle) and gives you back one clean, optimized, current file. There's an open source version and a SaaS one for the lazy (me).

And then the hosting question. Everyone will point you to Neon, Supabase or PlanetScale — great products, genuinely. But branching, edge replicas and a dashboard with 40 tabs is overkill when you just want a database that exists and doesn't ask questions. That's the other half of what I'm building: drop-in, no-bs Postgres, up and running with 2 CLI commands in about 3 minutes. That's it. That's the product.

The rule of thumb #

After all these experiments: the tooling around AI coding should be simpler than what we had before, not more complex. If setting up your database takes longer than building the feature, the tooling is wrong, not you.

It's early and some parts are still kinda rough, which is exactly why I want people banging on it. capysquash.dev — try it, break it, tell me what sucks. Honest feedback beats any signup number.

Anyway. Go check on your database. It knows what you did.