"Database mana yang harus saya pakai?" adalah salah satu pertanyaan system design paling sering ditanyakan — dan paling sering salah dijawab. Jawaban jujurnya: tidak ada database universal. Setiap pilihan adalah trade-off antara query pattern, skala, dan konsistensi.

Peta Keluarga Database

┌─ Relational (SQL) ──────── Postgres, MySQL, SQL Server
│
├─ Document ────────────── MongoDB, CouchDB, DynamoDB
│
├─ Key-Value ──────────── Redis, DynamoDB, Memcached
│
├─ Columnar / Wide-column ─ Cassandra, BigTable, HBase
│
├─ Graph ──────────────── Neo4j, Amazon Neptune, Dgraph
│
├─ Search ──────────────── Elasticsearch, OpenSearch, Algolia
│
└─ Time-series ────────── InfluxDB, TimescaleDB, Prometheus

Kapan Memilih Apa?

Relational (SQL) — default yang sehat

Pilih kalau: data punya relasi jelas (user, order, product), butuh transaksi ACID, query ad-hoc dengan JOIN, tim familiar dengan SQL. Contoh: e-commerce, perbankan, ERP, SaaS B2B. Postgres cocok untuk 80% kasus.

Document (MongoDB, DynamoDB)

Pilih kalau: struktur data bervariasi per record (schema flexibility), query selalu by key atau nested field, butuh horizontal scale mudah. Contoh: katalog produk dengan atribut berbeda per kategori, CMS, event log. Hati-hati: jangan pakai untuk data yang sangat relasional — JOIN di MongoDB memaksa kamu menduplikasi atau melakukan aplikasi-level join yang rapuh.

Key-Value (Redis)

Pilih kalau: butuh lookup super cepat by single key, tidak butuh query kompleks, data relatif kecil (cache, session, rate limit counter, leaderboard). Contoh: cache layer, session store, real-time counter, pub/sub.

Columnar (Cassandra, BigTable)

Pilih kalau: write-heavy, data sangat besar (terabyte+), query pattern sudah diketahui di depan (tidak ad-hoc), butuh multi-datacenter write. Contoh: event tracking, IoT telemetry, Netflix viewing history. Peringatan: schema Cassandra harus dirancang untuk query, bukan untuk data.

Graph (Neo4j)

Pilih kalau: relasi antar entity adalah first-class citizen (bukan sekedar foreign key), query butuh multi-hop traversal. Contoh: social network ("teman dari teman"), rekomendasi, fraud detection (deteksi pola transaksi), knowledge graph.

Search (Elasticsearch)

Pilih kalau: butuh full-text search, fuzzy matching, aggregation kompleks atas log. Bukan database primary — biasanya replika dari sumber kebenaran lain.

Time-series (InfluxDB, TimescaleDB)

Pilih kalau: data write-once, indexed by time, volume besar, query "range atas interval waktu". Contoh: metrics monitoring, sensor IoT, trading tick data.

Matriks Keputusan Singkat

CAP Positioning Singkat

• Postgres / MySQL single-node → CA (tidak distributed)
• Postgres dengan replica sync → CP leaning
• MongoDB (default config) → CP
• DynamoDB, Cassandra → AP (tunable consistency)
• Redis single-node → CA, Redis Cluster → AP

Polyglot Persistence — Realita Production

Sistem production jarang pakai satu database. Contoh real-world stack e-commerce:

Postgres        → orders, users, inventory (source of truth, ACID)
Redis           → session, cart, rate limit, cache
Elasticsearch   → product search
S3 + CDN        → product images
BigQuery        → analytics & reporting
Kafka + Cassandra → event log / click stream

Setiap database menjawab kebutuhan spesifik. Yang penting: pilih satu source of truth (biasanya Postgres), replika ke sisanya via CDC atau event.

Anti-Pattern Umum

1. "NoSQL lebih cepat jadi kita pakai MongoDB untuk semua" → tiba-tiba butuh JOIN, denormalisasi meledak.
2. "Redis tahan lama kan, simpan saja data utama di sana" → Redis by default bukan durable store — data bisa hilang.
3. "Elasticsearch fleksibel untuk semua query" → bukan ACID, indexing lag, bukan source of truth.
4. "Graph DB untuk semua relasi" → JOIN di SQL sudah efisien sampai ribuan hop pertama; Neo4j menang di traversal yang sangat dalam saja.
5. Sharding prematur → shard sebelum butuh = kompleksitas tanpa benefit.

Cara Berpikir yang Benar

Urutan pertanyaan saat memilih database:

1. Apa bentuk data? (relasional, document, graph, time-series, dll)
2. Apa pattern query? (ad-hoc SQL vs lookup by key vs traversal)
3. Berapa rasio read:write? (read-heavy → replica mudah; write-heavy → butuh arsitektur berbeda)
4. Apa SLA konsistensi? (boleh eventual? atau harus strong?)
5. Skala realistis 1 tahun? (jangan over-engineer untuk "jutaan user" kalau masih 100 user)

Database terbaik biasanya yang paling membosankan — yang tim kamu sudah paham dan sudah terbukti di banyak production.

🎭 Analogi sehari-hari: Pilih wadah masak.

• Wajan biasa (Postgres) = serbaguna, fit 80% masakan
• Rice cooker (Redis) = cepat untuk satu jenis (nasi/cache), bukan untuk gulai
• Oven (Elasticsearch) = bagus untuk roasting (search), bukan untuk goreng cepat
• Slow cooker (BigQuery) = analytics jangka panjang, bukan order live

Pilih sesuai jenis masakan, bukan karena trend.

💡 "Boring is good": Postgres + Redis cukup untuk 99% startup. Trendy DB (DynamoDB, MongoDB, Cassandra) bagus tapi butuh expertise + tooling matang. Senior engineer pilih boring = predictable, debuggable, hire-able.

⚠️ Jebakan klasik:

• NoSQL untuk relational data = denormalisasi meledak, query sulit
• Sharding prematur = kompleksitas tanpa benefit
• Graph DB untuk shallow relation = SQL JOIN sudah cukup
• Elasticsearch sebagai source of truth = indexing lag + eventual consistency
• Mengikuti trend tanpa cek pattern akses = pain di tahun ke-2

🎯 Default startup stack:

• Source of truth: Postgres (transactional + relational)
• Cache + session: Redis
• Search: Postgres FTS dulu, Elasticsearch kalau benar-benar butuh
• Analytics: start dengan Postgres replica, BigQuery saat data > 100GB

TL;DR: Pilih database based on data shape + query pattern + scale realistic. Postgres = 80% kasus. Polyglot persistence di production tapi satu source of truth. Boring + battle-tested > trendy.