Databases

Overview

A database is the component responsible for storing data durably and letting a system query and update it. It matters because it's often the source of truth and the hardest part to scale. Choosing the right type and structure early prevents painful migrations later.

Syntax / Usage

The two broad families are relational (SQL) databases with structured tables and strict schemas, and non-relational (NoSQL) databases optimized for flexibility or specific access patterns.

Relational (SQL)          Non-relational (NoSQL)
+----+--------+           { "id": 42,
| id | name   |             "name": "Ada",
+----+--------+             "roles": ["admin"] }
| 42 | Ada    |
+----+--------+           (document / key-value / wide-column)

SQL shines when data is structured and relationships and transactions matter. NoSQL shines for huge scale, flexible schemas, or simple key-based lookups.

Examples

A banking app uses PostgreSQL because transactions must be atomic and consistent — money should never be double-counted:

SELECT balance FROM accounts WHERE id = 42;

A social feed uses a key-value store like DynamoDB to fetch a user's timeline by user ID at massive scale, where flexible, denormalized data beats strict relations.

Common Mistakes

• Choosing NoSQL for hype when relational data fits better
• Missing indexes, making common queries slow as data grows
• Treating the single primary database as infinitely scalable
• No backups or tested restore process
• Storing large blobs (images, video) in the database instead of object storage

See Also

system-design-fundamentals system-design-caching system-design-scalability