Where the Data Lives
Choosing a database is mostly choosing which guarantee you are willing to give up. Then it is about making the one you chose go fast.
6 articles · about 55 min in total
Start with SQL vs NoSQL: How to Actually ChooseChoosing a database is mostly choosing which guarantee you are willing to give up. Every system on the menu is fast at something because it decided not to be strict about something else.
The SQL versus NoSQL framing has aged badly, because it compares a query language to a category that never had a definition. The useful question is narrower: what consistency does this workload need, what shape are the reads, and how much of the correctness are you willing to move into application code.
After that decision, most database work is about making the choice you made go fast, and that is largely indexing. An index is a trade of write cost and storage for read speed, and the reason so many are wrong is that people add them by intuition instead of reading the query plan.
The path ends on caching and text encoding for the same reason. Both are where a working database quietly starts returning wrong answers: a stale cache and a mismatched collation produce the same symptom, which is data that is correct in storage and wrong on screen.
Key takeaways
- Choosing a database is choosing which guarantee to give up, since systems gain speed by relaxing consistency, flexibility or durability somewhere.
- An index trades write cost and storage for read speed, so an index nobody queries is a permanent tax with no benefit.
- Composite index column order determines which queries can use it, which is why the same columns in a different order behave completely differently.
- A cache introduces a second source of truth, so invalidation strategy has to be designed at the same time as the cache itself.
Step 1: SQL vs NoSQL: How to Actually Choose
The honest default for most apps is Postgres, and NoSQL is a tool you reach for with a reason, not a lifestyle. Here is how to tell which one your project actually needs.
May 22, 2026 · 8 min read
Step 2: Database Architecture Patterns for High-Scale Systems
Most teams pick Postgres by default and that is usually right. Here is how to know when it stops being right, and what the alternatives actually cost you.
Feb 11, 2026 · 11 min read
Step 3: Database Indexes: Why Postgres Ignores the One You Added
A database index is a sorted copy of one or more columns that turns a full table scan into a handful of page fetches. The part nobody explains is why the index you already have sits there unused while your query crawls. Usually it is the way the query is written, not the absence of an index.
Aug 4, 2026 · 10 min read
Step 4: CAP Is Not “Pick Two of Three”, and It Describes the Rare Case
The famous framing is wrong twice over. Partition tolerance was never something you choose, and the trade-off only exists while a partition is happening. Which means CAP is silent about the decision you actually make every day, and PACELC is the version that names it.
Jul 29, 2026 · 9 min read
Step 5: What Is Caching and Why Everything Uses It
Caching is the oldest trick in computing: store an expensive result once, hand it back cheaply forever after. It lives in your CPU, your browser, the CDN, and your database. Here is how it works and when it quietly becomes a liability.
Jun 16, 2026 · 8 min read
Step 6: Unicode and UTF-8: Why Your Emoji Breaks the Database
A character, a code point, and an encoding are three different things, and almost every text bug you have ever shipped comes from a layer that confused two of them. Here is the whole model, with the actual bytes.
Aug 20, 2026 · 9 min read
Frequently asked questions
- Should I use SQL or NoSQL?
- Default to a relational database unless you can name the specific guarantee you need to relax. Relational systems now handle JSON, scale further than most applications require, and give you transactions and constraints that otherwise have to be reimplemented in application code.
- How do database indexes actually work?
- An index is a separate sorted structure that lets the engine find rows without scanning the table. It speeds reads and slows writes, because every insert and update must maintain it. Reading the query plan is the only reliable way to know whether yours is being used.
- Does column order matter in a composite index?
- Yes, a great deal. An index on (a, b) can serve queries filtering on a, or on a and b, but generally not one filtering only on b. Getting the order wrong produces an index that exists, costs writes, and is never used.
- When does caching make things worse?
- When invalidation is harder than the original query, when the cache hides a load problem until it fails cold, and when the hit rate is low enough that you have added a network hop and a consistency bug to save nothing measurable.