The 3 database schema mistakes that will haunt you at scale
Every backend dev has shipped a schema they later regretted. Here are the three patterns I see blow up most often — and what to do instead.
1. Storing everything as JSON columns
It feels flexible at first. Then you need to query by a nested field, add an index, or enforce a constraint. Now you're writing gnarly workarounds instead of clean SQL. Rule of thumb: if you'll ever filter or join on it, it needs a real column.
2. No soft deletes on critical tables
Hard deletes are permanent. One bad migration or admin action and your data is gone. Add deleted_at timestamps to any table where data loss would cause a support ticket. It costs almost nothing and saves everything.
3. Skipping migration versioning from day one
"I'll add migrations later" — famous last words. By the time you need them, your staging and production schemas have diverged and you're doing manual ALTER TABLEs at 2am. Start with versioned migrations on day one. Tools like Flyway, Alembic, or even raw numbered SQL files work.
These three fixes take maybe an hour total and save you weeks of pain later. I built SchemaVault to give backend devs battle-tested schemas and migration templates so you never have to learn these lessons the hard way.