TL;DR
SQL itu relational, structured, pake tabel. NoSQL itu flexible, bisa document/key-value/graph. SQL bagus buat data terstruktur dan relasi kompleks. NoSQL bagus buat data ga terstruktur dan scaling horizontal.
Ini pertanyaan yang sering banget muncul, baik di interview maupun waktu lagi design sistem baru. Jawabannya? Tergantung use case-nya.
Ga ada yang lebih bagus secara absolut. SQL dan NoSQL itu tools yang beda, cocok buat masalah yang beda juga. Yang penting adalah paham kapan pake yang mana.
SQL database (atau Relational Database) itu database yang nyimpan data dalam bentuk tabel-tabel yang saling berelasi. Setiap tabel punya kolom (fields) yang terdefinisi dengan jelas, dan data disimpan dalam baris (rows).
Contoh SQL database populer:
- PostgreSQL - Open source, fitur lengkap
- MySQL - Populer buat web applications
- Microsoft SQL Server - Enterprise solution
- Oracle - Enterprise, mahal, fiturnya lengkap
- SQLite - Lightweight, embedded database
-- Tabel customers
CREATE TABLE customers (
id SERIAL PRIMARY KEY,
nama VARCHAR(100),
email VARCHAR(100) UNIQUE,
kota VARCHAR(50)
);
-- Tabel orders
CREATE TABLE orders (
id SERIAL PRIMARY KEY,
customer_id INT REFERENCES customers(id),
tanggal DATE,
total DECIMAL(15,2)
);
-- Query dengan JOIN
SELECT c.nama, COUNT(o.id) as total_orders
FROM customers c
JOIN orders o ON c.id = o.customer_id
GROUP BY c.nama;
NoSQL (Not Only SQL) itu kategori database yang ga pake struktur tabel tradisional. Data bisa disimpan dalam berbagai format yang lebih flexible.
Ada 4 jenis utama NoSQL:
Simpan data dalam format document (biasanya JSON/BSON). Setiap document bisa punya struktur yang beda-beda.
Contoh: MongoDB, CouchDB
{
"_id": "user123",
"nama": "Budi Santoso",
"email": "budi@email.com",
"alamat": {
"jalan": "Jl. Sudirman No. 123",
"kota": "Jakarta",
"kodepos": "12190"
},
"orders": [
{"id": "ord1", "total": 150000},
{"id": "ord2", "total": 250000}
]
}
Paling simple. Cuma ada key dan value. Super cepat buat read/write.
Contoh: Redis, Amazon DynamoDB, Memcached
key: "user:123:name"
value: "Budi Santoso"
key: "session:abc123"
value: "{user_id: 123, login_time: '2024-01-15'}"
Optimized buat query yang butuh baca banyak data sekaligus. Data disimpan per kolom, bukan per baris.
Contoh: Apache Cassandra, HBase
Khusus buat data yang punya banyak relasi kompleks. Cocok buat social network, fraud detection, dll.
Contoh: Neo4j, Amazon Neptune
| Aspek | SQL | NoSQL |
|---|---|---|
| Schema | Fixed, harus didefinisikan dulu | Flexible, bisa berubah-ubah |
| Scaling | Vertical (upgrade server) | Horizontal (tambah server) |
| Relasi | Built-in dengan JOINs | Manual atau embedded |
| Consistency | Strong (ACID) | Eventually consistent (BASE) |
| Query | SQL standar | Beda-beda tiap database |
| Learning Curve | Lebih gampang, standar | Harus belajar tiap database |
SQL database punya constraint dan foreign keys yang menjaga integritas data. Kalau kamu coba insert data yang ga valid, database bakal reject.
-- Constraint mencegah email duplikat
CREATE TABLE users (
id SERIAL PRIMARY KEY,
email VARCHAR(100) UNIQUE NOT NULL
);
-- Ini bakal error kalau email udah ada
INSERT INTO users (email) VALUES ('budi@email.com');
SQL bisa jalanin query kompleks, kayak JOIN, subquery, window functions, dan sejenisnya.
-- Query kompleks yang susah di NoSQL
SELECT
kategori,
bulan,
total_penjualan,
SUM(total_penjualan) OVER (
PARTITION BY kategori
ORDER BY bulan
) as running_total
FROM penjualan
WHERE tahun = 2024;
Transaksi dijamin atomic. Kalau ada yang gagal, semua di-rollback.
BEGIN;
UPDATE accounts SET balance = balance - 100000 WHERE id = 1;
UPDATE accounts SET balance = balance + 100000 WHERE id = 2;
COMMIT;
-- Kalau salah satu gagal, dua-duanya di-rollback
SQL adalah standar industri. Skill SQL kamu transferable ke database manapun.
Kalau mau ubah struktur, harus ALTER TABLE. Di production dengan jutaan row, ini bisa lama dan risky.
-- Menambah kolom di tabel besar bisa lama
ALTER TABLE users ADD COLUMN phone VARCHAR(20);
SQL database biasanya di-scale vertical (upgrade server yang ada). Horizontal scaling (sharding) lebih ribet.
Kalau data-nya ga cocok dengan format tabel (JSON nested, varying fields), SQL jadi kurang optimal.
Ga perlu definisiin struktur di awal. Tiap document bisa beda struktur.
// User A punya alamat
{name: "Budi", alamat: {kota: "Jakarta"}}
// User B ga punya alamat, tapi punya social media
{name: "Siti", twitter: "@siti", instagram: "@siti.id"}
NoSQL designed buat distributed systems. Tinggal tambah server, otomatis ke-handle.
Buat read/write simple dan high volume, NoSQL bisa jauh lebih cepat.
Format JSON familiar buat developer. Ga perlu translate antara object dan tabel.
Data mungkin ga langsung konsisten di semua nodes. Buat transaksi finansial, ini bisa jadi masalah.
JOIN dan query kompleks susah atau ga mungkin. Harus di-handle di application layer.
Setiap database punya query language sendiri. MongoDB pake aggregation pipeline, Redis pake commands berbeda, dll.
Karena ga ada JOIN, data sering di-duplicate. Ini trade-off untuk read performance.
Pilih SQL database kalau:
E-commerce dengan customers, orders, products yang saling berelasi.
customers → orders → order_items → products
→ categories
Sistem finansial, banking, payment processing di mana data integrity critical.
Dashboard analytics yang butuh aggregate data dari berbagai tabel dengan query kompleks.
Kalau tim udah jago SQL, switching ke NoSQL ada learning curve.
Pilih NoSQL database kalau:
User-generated content, logs, sensor data yang formatnya bervariasi.
Aplikasi dengan jutaan concurrent users yang butuh horizontal scaling.
Caching, session storage, real-time feeds yang ga butuh complex queries.
MVP atau prototype yang schema-nya masih sering berubah.
Yuk liat gimana perusahaan tech Indonesia pake SQL dan NoSQL.
Gojek pake kombinasi keduanya:
- PostgreSQL - Buat core business data (orders, payments, merchant data)
- Redis - Caching dan real-time data (driver location, session)
- Cassandra - Event logging dan analytics data
Kenapa? Order dan payment butuh ACID compliance (SQL), tapi tracking location jutaan driver per detik butuh speed (NoSQL).
Tokopedia juga hybrid:
- MySQL/PostgreSQL - Product catalog, orders, user data
- MongoDB - Product reviews dan user-generated content
- Redis - Shopping cart, session management
- Elasticsearch - Product search
Product reviews cocok di MongoDB karena strukturnya bisa beda-beda (ada yang include foto, rating breakdown, dll).
Flight dan hotel prices berubah terus. Redis dipake buat cache supaya ga query ke partner API terus-terusan.
Kebanyakan startup modern pake pendekatan hybrid:
┌─────────────────┐ ┌─────────────────┐
│ PostgreSQL │ │ MongoDB │
│ │ │ │
│ - Users │ │ - Activity logs │
│ - Orders │ │ - User content │
│ - Transactions │ │ - Analytics │
└────────┬────────┘ └────────┬────────┘
│ │
└───────────┬───────────┘
│
┌──────┴──────┐
│ Redis │
│ │
│ - Sessions │
│ - Cache │
│ - Rate limit│
└─────────────┘
Istilahnya adalah "polyglot persistence": pake database yang tepat untuk tiap use case dalam satu aplikasi.
| Use Case | Database Choice |
|---|---|
| Core transactions | PostgreSQL/MySQL |
| User sessions | Redis |
| Product search | Elasticsearch |
| Analytics events | MongoDB/Cassandra |
| Recommendations | Neo4j (graph) |
| File metadata | MongoDB |
Ini beberapa pertanyaan yang sering muncul:
Q: "Kapan kamu akan pilih NoSQL daripada SQL?"
A: Butuh horizontal scaling buat data volume tinggi, requirements yang masih sering berubah, atau use case spesifik kayak caching (Redis) dan search (Elasticsearch).
Q: "Apa trade-off utama NoSQL?"
A: Eventual consistency. Data mungkin ga langsung sync, susah buat complex queries, dan ada data duplication. Tapi gain-nya scalability dan flexibility.
Q: "Bagaimana handling relasi di NoSQL?"
A: Ada 2 pendekatan: embedding (masukkan related data ke dalam document yang sama) atau referencing (simpan ID dan query terpisah). Embedding bagus buat data yang sering diakses bareng, referencing buat data yang besar atau sering berubah.
SQL itu dasar dari semua. Konsep kayak normalization, joins, dan indexing berlaku di mana-mana.
Setelah nyaman dengan SQL, coba MongoDB. Ini yang paling populer dan banyak resource-nya.
Jangan cuma ikut-ikutan. Pahami kenapa pilih satu database, bukan karena "trending".
Bikin project kecil pake SQL, terus bikin versi NoSQL-nya. Rasain sendiri bedanya.
SQL vs NoSQL soal milih yang paling cocok buat kebutuhan aplikasi kamu.
Pilih SQL kalau:
- Data terstruktur dan relasional
- Butuh ACID transactions
- Complex queries dan reporting
- Data integrity adalah prioritas
Pilih NoSQL kalau:
- Data nggak terstruktur atau gampang berubah
- Butuh horizontal scaling
- Simple read/write dengan volume tinggi
- Rapid development dengan schema flexible
Atau pilih keduanya (hybrid approach) kalau aplikasi kamu cukup kompleks.
Yang paling penting: pahami requirements aplikasi kamu dulu, baru pilih tool yang tepat. Jangan over-engineer dengan stack kompleks kalau PostgreSQL udah cukup.
Mau praktek langsung? Mulai latihan SQL gratis
Latihan interaktif, langsung di browser.
Cara pakai pandas cut dan qcut buat binning data numerik jadi kelompok. Bedanya, kapan pakai yang mana, plus contoh segmentasi pelanggan UMKM.
Cara pakai pandas rolling buat hitung moving average dan haluskan data time series yang naik-turun. Lengkap dengan contoh penjualan harian UMKM.
Data transaksi harian sering terlalu ramai buat dilihat. Pandas resample ngeringkasnya jadi total per minggu atau per bulan cuma dengan satu baris, asal indeksnya tanggal.