Backend, APIs & data · Mixed

Databases: choose and don't regret it

In one line: In most cases a relational database is the right answer, and any other choice needs a reason you can state in a sentence.

Why relational by default

Consistency, flexible queries, constraints that prevent broken data, and mature tooling. Most of what's considered a “relational limitation” is solved with a correct schema and indexes.

Document stores suit when the structure truly varies between records; key-value stores for cache and transient state; time-series stores for metrics. These are additions, not a replacement.

Decisions that set the future

Keys. Stable and immutable; don't use business information as a key.

Constraints. Foreign keys, uniqueness and non-nullness. A constraint in the store beats a check in code — it catches the path you didn't think of too.

Times. Store in a consistent, explicit time zone, with a creation and update time per record.

What actually breaks systems

Queries in a loop that create hundreds of calls instead of one, a missing index on a column you filter by, and long transactions that lock. All three surface only at real volume.

Going deeper

Enable slow-query logging from day one and review it weekly. And when you add an index, measure — a needless index slows writes and takes space, and not every query plan improves from it.