Ilustrasi perbandingan tabel terstruktur dan dokumen bebas

Di artikel sebelumnya latihanmu mentok di satu pertanyaan bagus: kalau produknya ada 1000, menulis data satu per satu di kode jelas tidak masuk akal. Jawabannya adalah database, lapisan tempat data tinggal secara permanen dan rapi. Tapi begitu kamu googling, langsung muncul perang kubu: SQL vs NoSQL. Mana yang benar?

Posisinya di perjalanan belajarmu: ini episode 4 dari series Peta Tech Stack. Kamu sudah kenal tumpukannya (#5), ruang makannya (#6), dan dapurnya (#7). Sekarang kita buka gudang penyimpanannya. Setelah ini, episode 5 (#9) akan merangkum semuanya jadi panduan memilih stack untuk proyek pertamamu.

Database Itu Gudang, SQL dan NoSQL Itu Sistem Penataannya

Mulai dari analogi sehari-hari, sesuai janji kita. Bayangkan dua cara menyimpan barang.

SQL itu seperti lemari arsip kantor. Setiap laci punya label tetap, setiap map di dalamnya punya format yang sama: nama, tanggal, nomor. Rapi, konsisten, gampang dicari. Tapi kalau tiba-tiba kamu perlu menyimpan barang yang bentuknya beda dari format map, repot: harus ubah dulu struktur lacinya.

NoSQL itu seperti tas serbaguna atau gudang fleksibel. Kamu bisa memasukkan kotak, amplop, botol, apa saja, tanpa mengubah struktur gudangnya. Fleksibel dan cepat diisi. Tapi kalau barangnya sudah ribuan dan kamu butuh laporan rapi ("tampilkan semua transaksi bulan lalu diurutkan nominalnya"), gudang fleksibel bikin kamu kerja ekstra.

Secara teknis: SQL (Structured Query Language) adalah database relasional. Data disimpan dalam tabel berisi baris dan kolom, dengan schema (struktur) yang ditetapkan di awal. Contohnya MySQL, PostgreSQL, dan SQLite. NoSQL ("not only SQL") adalah database non-relasional dengan struktur fleksibel: bisa berupa dokumen (mirip JSON), key-value, atau graf. Contohnya MongoDB, Redis, dan Firebase.

Contoh yang sama, dua cara simpan. Data pengguna bernama Anna:

-- SQL: tabel dengan kolom tetap
CREATE TABLE users (
  id INT PRIMARY KEY,
  name VARCHAR(50),
  email VARCHAR(100)
);
INSERT INTO users VALUES (1, 'Anna', 'anna@email.com');

-- NoSQL (MongoDB): dokumen fleksibel
db.users.insertOne({
  name: 'Anna',
  email: 'anna@email.com',
  skills: ['HTML', 'CSS']
});

Alur berpikir di balik perbedaannya: di SQL, kamu mendefinisikan struktur dulu (CREATE TABLE), baru mengisi data. Komputer jadi tahu persis bentuk datanya dan bisa menjamin konsistensi. Di NoSQL, kamu langsung menyimpan dokumen apa adanya. Perhatikan dokumen Anna versi NoSQL punya field skills yang tidak ada di tabel SQL. Di SQL, menambah field berarti mengubah struktur tabel. Di NoSQL, dokumen berikutnya tinggal menyertakan field baru. Fleksibilitas itu ada harganya: tidak ada yang menjamin semua dokumen punya field yang sama.

Berhenti dan tebak dulu! Aplikasi kasir menyimpan transaksi. Suatu hari pemiliknya mau menambah field "metode pembayaran" ke semua transaksi lama dan baru. Menurut logika di atas, di database mana perubahan ini lebih mudah dilakukan: SQL atau NoSQL? Dan apa risikonya di masing-masing?

Jawaban: lebih mudah di NoSQL, tapi lebih aman di SQL. Di NoSQL, transaksi baru tinggal menyertakan field baru, tidak perlu mengubah apa-apa. Risikonya: transaksi lama tidak punya field itu, jadi laporan bisa bolong tanpa kamu sadari. Di SQL, kamu harus mengubah struktur tabel secara eksplisit (tambah kolom), yang memaksa kamu memikirkan nasib data lama. Lebih repot di awal, tapi konsistensinya terjaga. Inilah trade-off inti yang harus kamu pahami, bukan sekadar "mana yang lebih bagus".

Kapan Pilih SQL, Kapan Pilih NoSQL

Bukan soal bagus atau jelek. Soal cocok atau tidak. Ini panduan praktisnya:

Pilih SQL kalau: datamu terstruktur dan relasinya jelas (pengguna punya banyak pesanan, pesanan berisi banyak produk), kamu butuh transaksi yang bisa diandalkan (uang berpindah tidak boleh setengah jalan, ini disebut ACID), dan kamu butuh laporan kompleks dengan gabungan tabel (JOIN). Contoh nyata: aplikasi bank, kasir, e-commerce, sistem booking.

Pilih NoSQL kalau: struktur datamu sering berubah atau tidak seragam, kamu butuh kecepatan tulis/baca sangat tinggi dalam volume besar, dan aplikasimu harus mudah diskalakan ke banyak server. Contoh nyata: aplikasi chat, feed media sosial, analitik real-time, katalog produk dengan atribut yang beda-beda.

Catatan penting untuk pemula: untuk proyek belajar pertamamu, SQL hampir selalu pilihan yang lebih baik. Kenapa? Karena SQL memaksamu berpikir tentang struktur data dengan benar: tabel apa saja, relasinya bagaimana, datanya konsisten atau tidak. Skill itu transferable ke mana-mana. NoSQL yang fleksibel justru bisa menutupi desain data yang berantakan. Nanti di kurikulum ini kamu belajar SQL dulu (Fase 5, artikel #63-67: database relasional, CRUD, JOIN, sampai desain database), karena itu fondasinya.

Mitos 1: NoSQL Itu Pengganti SQL, SQL Sudah Kuno

Mitos ini lahir dari hype sekitar tahun 2010-an, saat NoSQL naik daun dan banyak yang meramalkan kematian SQL. Ramalannya meleset. Satu setengah dekade kemudian, database SQL paling populer (PostgreSQL, MySQL) justru makin kuat dan tetap menjadi pilihan default sebagian besar aplikasi.

Kenyataannya, keduanya hidup berdampingan dan sering dipakai bersamaan dalam satu aplikasi. Contoh umum: data transaksi dan pengguna disimpan di PostgreSQL (butuh konsistensi), sementara cache dan data sesi disimpan di Redis (butuh kecepatan). Memilih satu kubu secara ideologis itu seperti tukang yang cuma mau pakai obeng dan menolak palu. Profesional memakai keduanya sesuai kebutuhan.

Mitos 2: NoSQL Berarti Tanpa Struktur Sama Sekali

Nama "NoSQL" menipu. Ia singkatan dari "not only SQL", bukan "no structure". Database NoSQL tetap butuh desain, cuma desainnya beda: bukan tabel dan relasi, tapi bentuk dokumen dan pola aksesnya.

Contoh jebakannya: pemula menyimpan semua data dalam satu dokumen raksasa karena "kan fleksibel", lalu aplikasinya melambat saat dokumennya membengkak. Atau menyimpan data yang sama di banyak tempat tanpa strategi, lalu pusing saat harus mengubahnya. Fleksibilitas tanpa desain sama dengan kekacauan yang tertunda. Aturannya tetap sama di kedua kubu: pahami dulu bagaimana datamu akan dipakai, baru tentukan cara menyimpannya.

Kuis cepat: Kamu membangun aplikasi dompet digital. Pengguna transfer saldo ke pengguna lain. Database mana yang paling tepat?

Skalabilitas: Vertikal vs Horizontal

Satu istilah yang sering muncul dalam perdebatan ini: skalabilitas. Sederhananya, apa yang kamu lakukan saat aplikasimu makin ramai.

Database SQL umumnya scale up (vertikal): servernya diganti yang lebih kuat. Seperti mengganti kompor kecil dengan kompor besar. Ada batasnya: sebesar apa pun kompornya, tetap satu kompor.

Database NoSQL umumnya scale out (horizontal): servernya ditambah, bebannya dibagi. Seperti menambah kompor lagi di dapur. Secara teori bisa ditambah terus.

Kedengarannya NoSQL menang telak. Tapi untuk 99 persen aplikasi yang akan kamu buat sebagai pemula, satu server SQL yang decent sudah lebih dari cukup. Masalah skala raksasa adalah masalah yang menyenangkan untuk dimiliki: artinya aplikasimu sudah sukses. Jangan memilih teknologi berdasarkan masalah yang belum kamu punya.

Berhenti dan tebak dulu! Dua startup baru berdiri. Startup A langsung memakai database yang bisa scale out ke 100 server "untuk jaga-jaga kalau viral". Startup B memakai satu database SQL biasa dan fokus ke produknya. Menurut logika artikel ini, siapa yang mengambil keputusan lebih bijak? Kenapa?

Jawaban: startup B. Alasannya: masalah terbesar startup baru bukan skala, tapi apakah ada yang mau memakai produknya. Teknologi scale-out menambah kompleksitas (dan biaya belajar) untuk masalah yang belum ada. Kalau nanti benar-benar viral, migrasi bisa dilakukan saat sumber daya sudah ada. Prinsipnya: pilih teknologi untuk masalah hari ini, bukan masalah khayalan tahun depan. Ini pola pikir yang sama yang akan kita pakai di artikel berikutnya saat memilih tech stack.

Latihan dan Langkah Berikutnya

Latihan kali ini melatih matamu membaca kebutuhan data:

  1. Klasifikasikan 3 aplikasi. Ambil tiga aplikasi dari latihan artikel #5 (bedah aplikasi favoritmu). Untuk tiap aplikasi, tentukan: bagian datanya yang mana yang cocok SQL dan yang mana yang cocok NoSQL, beserta alasannya satu kalimat. Contoh: "Riwayat transaksi ojek online cocok SQL karena butuh konsistensi uang; posisi driver real-time cocok NoSQL karena butuh kecepatan tulis tinggi."
  2. Desain tabel pertamamu (di atas kertas). Untuk aplikasi catatan sederhana: tabel apa saja yang dibutuhkan? Kolomnya apa? Relasinya bagaimana? Cukup 2 tabel (misalnya users dan notes). Ini pemanasan untuk artikel #67 nanti, di mana kita mendesain database beneran.

Langkah berikutnya: artikel #9, Cara Memilih Tech Stack untuk Proyek Pertamamu. Episode penutup series Peta Tech Stack. Semua peta yang kita gambar di #5 sampai #8 kita pakai untuk menjawab pertanyaan paling praktis: dengan semua pilihan ini, saya harus mulai dari mana? Sampai jumpa di episode terakhir series ini.