DATA MODELS · SCALE · GUARANTEES

A database
is not a logo.

It is where business rules become structure, access, and guarantees. Choosing well does not begin with a product comparison: it begins by writing down the questions the system must answer, the states it must never accept, and how it should fail.

ONE DECISION CHAINFROM PRODUCT TO STORAGE

01QUESTIONSwhat we read and write
02MODELhow data connects
03GUARANTEESwhat must remain true
04ENGINEwhat we can operate

PRODUCTSTORAGE

PUBLISHED: AUG 10 2026
READING: ~18 min
LANGUAGE: EN · ES
ORIGIN: BettaTech video

01 / START WITH THE QUESTIONS

Design the queries
before the tables.

The same set of entities can support completely different models. The right shape depends on how information enters, changes, and leaves the system.

QUERY-FIRST DESIGN

A workload, not a feature list.

Before choosing technology, write the critical paths as observable contracts. Each one should have expected volume, latency, consistency, and failure behavior.

01 · IDENTITYget_order(order_id)
02 · LISTlist_orders(customer_id, created_at DESC)
03 · CRITICAL WRITEreserve_stock(sku, quantity)
04 · SEARCHsearch_products(text, filters)

The minimum decision canvas

Access

What is read and written, with which filters, ordering, and cardinality.

Invariants

What must be unique, atomic, ordered, or referentially valid.

Load

Current and peak volume, read/write ratio, growth, and bytes per item.

Distribution

Regions, residency, natural partitions, hot keys, and latency tolerance.

Failure

What the system returns when a node, region, or projection falls behind.

Operations

Backups, restore, migrations, observability, and the team’s real experience.

02 / FOUR MODELS, NOT FOUR BRANDS

Each model optimizes
a way of asking.

Relational, document, key–value, and graph are not maturity levels. They are representations that make some operations natural and others expensive.

01PostgreSQL · MySQL · SQL Server

Relational

SHINES WHEN: Invariants and relationships matter, while questions evolve.
NATURAL QUERY: JOIN, filter, aggregate, and transact across entities.
PAYS WITH: Explicit schema and migrations; distributed coordination has a cost.

02MongoDB · Couchbase

Document

SHINES WHEN: Data is read together and its shape varies by type or version.
NATURAL QUERY: Fetch one complete aggregate by identity and navigate fields.
PAYS WITH: Duplication and multi-document updates; flexibility still needs design.

03Redis · DynamoDB

Key–value

SHINES WHEN: The key is known and access must stay predictable at scale.
NATURAL QUERY: GET/PUT by partition key; ranges when a sort key exists.
PAYS WITH: Limited ad hoc queries; a poor key creates hot partitions.

04Neo4j · Amazon Neptune

Graph

SHINES WHEN: Relationship depth and shape are the product.
NATURAL QUERY: Neighbors, paths, communities, and variable traversals.
PAYS WITH: Another language and operating model; simple relationships do not improve by magic.

03 / NORMALIZE AND DENORMALIZE

The shape of data
is also a trade-off.

Normalization reduces duplication and centralizes rules. Denormalization brings data closer to a specific read. The key is deciding which representation is authoritative and which is a projection.

WRITE MODEL · NORMALIZED

One rule lives in one place.

Customer, order, product, and order line each have an identity. Keys and constraints protect relationships: changing an email does not require rewriting order history.

READ MODEL · DENORMALIZED

One screen resolves in one read.

{
  "order_id": "1042",
  "customer": "Ana",
  "total": 129.90,
  "items": ["keyboard", "mouse"]
}

A projection can repeat name, total, and products to serve order details without joins. It is rebuilt from events or the source of truth and accepts a defined freshness window.

OWNERSHIP RULE
Duplicating data can be correct. Duplicating authority almost never is.

04 / INDEXES

Speed up a question,
not “the database.”

An index is another representation maintained by the engine so it can find rows without scanning the entire table. It buys faster reads with storage and extra work on every write.

WITHOUT INDEX

Table scan

●

Cost grows with the rows examined.

WITH INDEX

B-tree lookup

The engine walks an ordered structure to the useful range.

WHAT TO MEASUREquery + selectivity + plan + frequency

Design from WHERE, JOIN, and ORDER BY

Column order in a composite index changes which prefixes the planner can use.

Count the write cost

INSERT, UPDATE, and DELETE maintain indexes too. An unused index is active debt.

Read the real plan

EXPLAIN and production metrics show whether the index removes work or a scan is cheaper.

05 / SCALE WITHOUT SHORTCUTS

More nodes change
the guarantees.

Scale is not a binary property. Replication, partitioning, and distribution move the limit, but also introduce lag, coordination, and new intermediate states.

Vertical scale

More CPU, RAM, or I/O for one instance.

Simple and effective up to a physical or economic limit; it does not solve availability on its own.

Replicas

Copies for reads, failover, or regional proximity.

They increase read capacity but require a definition for lag and read-after-write.

Sharding

Each partition owns a subset of keys.

It distributes storage and writes; joins, transactions, rebalancing, and hot keys become harder.

06 / CAP, WITHOUT THE SLOGAN

It is not choosing
two letters forever.

CAP describes what a replicated system can promise during a network partition. In that interval, an operation cannot provide both linearizable consistency and a successful response from both sides.

CCONSISTENCYone current history

AAVAILABILITYevery request gets a response

PACTIVE PARTITIONnodes cannot communicate

REJECT OR WAIT

Preserve consistency

One side becomes temporarily unavailable rather than accept divergent states.

ANSWER ON BOTH SIDES

Preserve availability

Concurrent versions or stale data are accepted and reconciled later.

THE NUANCE

The partition is the condition, not a feature to discard. Outside it, consistency and availability can coexist. The choice may vary by operation, data, and time.

07 / ONE SYSTEM, MULTIPLE VIEWS

Polyglot persistence,
with one truth.

Using multiple engines is valid when workloads genuinely differ. Sustainable design assigns one responsibility to each store and makes propagation explicit.

CASE: COMMERCESOURCE OF TRUTH + PROJECTIONS

APIcommands

POSTGRESorders + payments

OUTBOXdurable events

REDIShot reads

SEARCHcatalog

POSTGRES

Transactional authority. An order and its payment protect invariants together.

REDIS

Disposable projection. It may expire or disappear without losing truth.

Eventually consistent projection optimized for text and filters.

08 / DECISION METHOD

From a question
to a defensible choice.

Technology is a conclusion. This order keeps the conversation connected to the product and makes the choice reviewable when the workload changes.

01
Write the access patterns
Queries, commands, frequency, cardinality, ordering, filters, and latency target.
02
Define invariants and authority
Which states are invalid and which system decides the accepted version.
03
Estimate load and growth
Peaks, read/write ratio, bytes per entity, retention, and geographic distribution.
04
Choose the simplest model
The one that solves the critical path without premature projections or coordination.
05
Design indexes and partitioning
Using real queries, key distribution, and observed plans.
06
Test failure and operations
Restore, lag, dead node, partition, migration, hot key, and user-visible degradation.

DESIGN REVIEW

Questions for the design review

01What is the source of truth?
02Which query shapes the model?
03Which inconsistency is unacceptable?
04Which data may be stale, and for how long?
05What is the partition key, and can it become hot?
06How is restore performed and tested?
07Which signal proves we need another engine?

THE DECISION IN ONE LINE

Questions first.
Model second. Engine last.

Durable data design does not memorize a comparison table: it connects product behavior, invariants, volume, and failure. Once that chain is written, choosing technology stops being a preference contest.

09 / SOURCES AND NEXT STEPS

Design the queriesbefore the tables.

A workload, not a feature list.

The minimum decision canvas

Access

Invariants

Load

Distribution

Failure

Operations

Each model optimizesa way of asking.

Relational

Document

Key–value

Graph

The shape of datais also a trade-off.

One rule lives in one place.

One screen resolves in one read.

Speed up a question,not “the database.”

Table scan

B-tree lookup

Design from WHERE, JOIN, and ORDER BY

Count the write cost

Read the real plan

More nodes changethe guarantees.

Vertical scale

Replicas

Sharding

It is not choosingtwo letters forever.

Preserve consistency

Preserve availability

Polyglot persistence,with one truth.

From a questionto a defensible choice.

Write the access patterns

Define invariants and authority

Estimate load and growth

Choose the simplest model

Design indexes and partitioning

Test failure and operations