Startup Database Design Mistakes: Why Your MVP Can't Scale
Startup database design mistakes that block scale: nullable chaos, missing indexes, JSON-as-schema, soft-delete uniqueness, migration fear—and SQL patterns that keep MVPs evolvable.
Startup database design mistakes rarely hurt at demo scale—they hurt when dashboards crawl, migrations induce fear, or subtle inconsistency bugs appear under concurrency. Most painful issues trace back to nullable ambiguity, missing indexes, schema avoidance via JSON blobs, and migration cultures that reward manual heroics.
Pair with backend mistakes, MVP technical debt, and AWS serverless data access patterns.
Mistake 1 — Nullability as procrastination
Nulls should encode real optional states, not “we’ll decide later.”
Symptoms: inconsistent UI states, duplicated business logic guessing meanings, analytics that disagree.
Better: explicit enums/status columns; NOT NULL where business rules require presence; constraints that forbid impossible combinations.
Mistake 2 — Deferring indexes until production screams
Local datasets hide full scans.
Symptoms: queries fine at 10k rows; unacceptable at 500k.
Better: design indexes against expected access paths; validate with EXPLAIN on realistic volumes; revisit after shipping real workloads—especially for marketplace listing feeds tied to marketplace architecture.
Mistake 3 — JSON substitution for relational entities
JSON helps genuinely semi-structured extensions—not core transactional entities needing joins and integrity.
Symptoms: impossible reporting, inconsistent validation, duplicate sources of truth.
Better: normalize entities participating in money movement and permissions; reserve JSON for bounded extensions.
Mistake 4 — Soft deletes without uniqueness strategy
Soft deletes aid auditing but break naive uniqueness constraints.
Symptoms: “duplicate email” collisions across deleted rows; confusing analytics.
Better: partial unique indexes where supported; consistent query filters; retention policies aligned with privacy commitments.
Mistake 5 — Migration fear → manual prod edits
Symptoms: schema drift, undocumented hotfixes, undeployable environments.
Better: repeatable migrations tested in staging; backwards-compatible expand/contract habits where uptime matters.
Mistake 6 — Weak tenant boundaries
Even if you launch “single-tenant-ish,” decide how tenant_id (or equivalent) maps—waiting until enterprise demands isolation often forces painful retrofitting—often intertwined with authorization (auth architecture).
Query hygiene checklist
- Avoid
SELECT *on hot paths - Prefer keyset pagination for feeds vs naive OFFSET at scale
- Watch N+1 patterns in ORMs—measure before blaming frameworks
SQL vs NoSQL for MVP
Choose SQL when relational integrity, reporting flexibility, and transactional workflows dominate—which describes many SaaS/marketplace cores.
Choose NoSQL when access patterns are narrow, partition keys stable, and consistency tradeoffs consciously accepted—often specialization, not day-one default.
Frequently asked questions
Shard early?
Almost never before vertical scaling + query fixes exhaust leverage.
ORMs the root cause?
Usually modeling and indexing—not the ORM itself.
Quick win?
Constraints + indexes aligned to measured queries—cheap insurance against corruption + latency cliffs.
Budget implications?
Reworking schemas mid-flight is expensive—scope early with backend development cost.
Bottom line
Avoiding startup database design mistakes means encoding business rules explicitly, indexing for real workloads, keeping transactional entities relational, building migration confidence early—and aligning schema boundaries with how authorization and tenants actually behave at scale.