Early data modeling for backend teams: migrations first or design the data layer in isolation?

I have started forcing myself to prototype data models before touching any real database and it has changed how I build backend systems.

Recently I was working on a feature that looked simple on paper. Once I actually mapped it out the cracks showed up fast. many-to-manys that should not exist, state that belonged in events instead of tables, and fields that were clearly derived but I was about to persist anyway.

Instead of spinning up Postgres + migrations I used a dev tool to model tables, relations, constraints, and expected query patterns. Think schema design + backend thinking, without committing to infra or an ORM.

That alone surfaced:

• write-heavy vs read-heavy paths early
• where indexes would actually matter
• which entities were leaking responsibilities
• API shapes that would've been painful to version later

Once the model looked sane, translating it to actual SQL and migrations was almost mechanical. No rewrites. No "we will fix it later" debt.

We ended up building an internal tool around this workflow (now called drawline.app) because we kept repeating it. Mock the database first. stress it mentally. then ship. It is not a replacement for a real DB, but it is been great for backend prototyping, schema reviews, and sanity-checking system design before code exists.