Databases: SQL vs. NoSQL
Every other decision in this Part rests on this one — how the product's data is structured, stored, and queried.
5.1.1Definition
A database is a structured system for storing, retrieving, and managing data reliably at scale. SQL (relational) databases organize data into tables with fixed schemas and relationships enforced by the database itself. NoSQL databases — document, key-value, wide-column, or graph — store data in more flexible shapes, trading some consistency guarantees for scale or schema flexibility.
5.1.2Why It Exists
Applications need to persist data beyond a single request, and different data shapes and access patterns are served better by different storage models. A social feed's rapidly-changing, loosely-structured posts fit a document store; a bank's transaction ledger, where correctness and relationships between accounts matter absolutely, fits a relational model. No single database model is correct for every workload — the category exists precisely because that trade-off is real.
5.1.3When to Use Each
| Model | Strengths | Best fit |
|---|---|---|
| SQL (PostgreSQL, MySQL) | Strong consistency, relationships, transactions | Financial systems, ERP (2.13), CRM (2.12), most SaaS products (2.9) |
| Document (MongoDB) | Flexible schema, fast iteration | Content-heavy apps, rapidly evolving product data |
| Key-Value (Redis, DynamoDB) | Extremely low-latency lookups | Caching (5.9), session storage (5.3), leaderboards |
| Graph (Neo4j) | Relationship-heavy traversal | Social networks (2.8), recommendation engines |
5.1.4Common Mistakes
- Choosing NoSQL for scale the product will never reach. Adopting a distributed document store for a workload a single PostgreSQL instance would comfortably serve for years, adding operational complexity with no corresponding benefit.
- Modeling relational data in a document store anyway. Recreating foreign-key-style joins manually in application code because the team is used to relational thinking, losing NoSQL's actual advantages while keeping none of SQL's guarantees.
- Skipping indexes until performance becomes a visible problem, then adding them under production pressure rather than as part of initial schema design.
- No migration strategy. Schema changes applied directly to production with no versioned migration history, making rollback or team collaboration unreliable.
5.1.5Best Practices
- Default to a relational database unless a specific access pattern clearly demands otherwise — most products' data is more relational than it first appears.
- Use versioned migrations (e.g., via an ORM's migration tool) for every schema change, never manual production edits.
- Index for the queries the application actually runs, verified with query plans, not guessed in advance.