Database Design

Why bad database design is the debt that never stops compounding

Most database problems aren't discovered until it's expensive to fix them. The schema that worked at 1,000 records slows to a crawl at 1,000,000. The document structure that seemed flexible becomes a query nightmare when you need to filter, aggregate, or join. Missing an index on the right field turns a 5ms query into a 5-second one.

The choices you make when designing a schema — normalization vs. denormalization, how you model relationships, what you index — have a multiplying effect on every query ever written against that data. Getting them right early is far cheaper than migrating a production database under live traffic later.

Choosing the right database type matters too. MongoDB's document model is genuinely better for certain access patterns. PostgreSQL's relational model and JSONB support makes it the right default for most SaaS products. The choice should follow the data, not the hype.

How I approach database design

I design schemas around the queries they need to serve, not in isolation from the application.

• Schema design workshops to map your domain model, access patterns, and growth projections before writing a single line
• Index strategy based on real query analysis — compound indexes, partial indexes, text indexes where they'll have impact
• Migration scripts with rollback so schema changes can be deployed and reversed safely in production
• Query optimization using EXPLAIN and slow query logs to find and fix the queries that matter most

Good database design is invisible when it works. You'll notice it in fast queries, predictable performance, and the absence of the 3am "the database is slow" incident.