Hvordan velger du databaser i systemdesign?

Question

Accepted Answer

Å velge riktig **database** er en nøkkelbeslutning i systemdesign — mellom **SQL (relasjonelt)** og **NoSQL**-typer (dokument, nøkkel-verdi, osv.), basert på dataene, tilgangsmønstre, skala og konsistensbehov. Ulike databaser passer til ulike krav.

## SQL vs NoSQL (hovedvalget)

```text
SQL (relational: PostgreSQL, MySQL) → structured data, tables, relationships, ACID:
  ✓ strong consistency, complex queries/joins, transactions, well-defined schema
  ✓ for: relational data, transactions, complex queries (most traditional apps)
NOSQL → various non-relational models, flexible schema, often easier horizontal scaling:
  → DOCUMENT (MongoDB) → flexible JSON-like docs
  → KEY-VALUE (Redis, DynamoDB) → simple, fast lookups, caching
  → WIDE-COLUMN (Cassandra) → massive scale, high write throughput
  → GRAPH (Neo4j) → relationships/networks
  ✓ for: flexible schema, huge scale, specific access patterns, high throughput
```

## Hvordan velge

```text
Consider:
  → DATA structure → relational/structured (SQL) vs flexible/varied (NoSQL document)
  → ACCESS PATTERNS → complex queries/joins (SQL) vs simple key lookups (key-value)
  → SCALE → massive horizontal scale / huge write volume (some NoSQL) vs moderate (SQL fine)
  → CONSISTENCY → strong consistency/transactions (SQL) vs eventual OK (some NoSQL)
  → choose the database that FITS the requirements (not just what's trendy)
```

## Polyglot persistence

```text
→ Use DIFFERENT databases for different needs in one system ("polyglot persistence"):
  e.g. PostgreSQL for core data + Redis for caching + Elasticsearch for search
→ no single database is best for everything → use the right tool for each job
```

## Hvorfor det betyr noe

Å forstå hvordan man velger databaser er grunnleggende fordi **databasevalg er en nøkkelbeslutning i systemdesign** som påvirker systemets egenskaper betydelig, så det er viktig kunnskap.

Databasen er sentral i de fleste systemer, og å velge riktig — mellom **SQL (relasjonelt)** og de ulike **NoSQL**-typene — basert på krav er en viktig arkitektonisk beslutning.

Å forstå **SQL vs NoSQL**-skillet er grunnleggende: SQL-databaser tilbyr sterk konsistens, komplekse spørringer og joins, transaksjoner og strukturerte skjemaer (som passer relasjonelle data og tradisjonelle applikasjoner), mens NoSQL-databaser tilbyr fleksible skjemaer og ofte enklere horisontal skalering, med ulike typer (dokument, nøkkel-verdi, bredkolonne, graf) som passer ulike behov (fleksible data, massiv skala, høyt gjennomstrømning, spesifikke tilgangsmønstre).

Å forstå **hvordan velge** — basert på datastruktur (relasjonelt vs fleksibelt), tilgangsmønstre (komplekse spørringer vs enkle oppslag), skala (massiv horisontal skalering vs moderat) og konsistensbehov (sterk vs eventuell) — er nøkkelferdigheten, med det viktige prinsippet om å velge databasen som **passer kravene** i stedet for hva som er trendete.

Å forstå **polyglot persistence** — å bruke ulike databaser for ulike behov i ett system (f.eks. PostgreSQL for kjerndata, Redis for caching, Elasticsearch for søk) — reflekterer den modne erkjennelsen at ingen enkelt database er best for alt, så å bruke riktig verktøy for hver oppgave er ofte optimalt.

Ettersom databasen er sentral i de fleste systemer og å velge riktig (SQL vs NoSQL-typer, basert på data, tilgangsmønstre, skala og konsistens) påvirker systemets egenskaper betydelig og er en nøkkelbeslutning i designet, og siden å forstå hvordan velge og polyglot-persistence-tilnærmingen er grunnleggende, er å forstå hvordan velge databaser essensielt, grunnleggende systemdesign-kunnskap — en nøkkelbeslutning i systemdesign som krever forståelse av databasealternativene og hvordan matche dem til krav, og sentral for å designe systemer med hensiktsmessig datalagring.