Database Sharding vs Partitioning: Kapan Data Perlu Dipecah?

Tabel transaksi atau log aktivitas kalian udah nembus ratusan juta sampai miliaran row? Kalau iya, kita satu klub. 😅

Awalnya, pas data masih ribuan row, semua query SELECT jalan secepat kilat. Tapi begitu ukuran tabel membengkak sampai puluhan gigabyte, semuanya berubah:

• Index B-Tree nggak muat lagi di RAM (buffer pool).
• Setiap INSERT baru mulai kerasa lambat gara-gara proses index balancing yang berat.
• Query laporan bulanan bikin CPU database melonjak sampai 100% dan ngunci row lainnya.

Pas teknik optimasi standar kayak indexing dan connection pooling udah nggak mempan lagi, langkah arsitektur berikutnya adalah mecah data.

Nah, dua istilah yang paling sering muncul di sini adalah Partitioning dan Sharding. Kedengerannya mirip, sih, tapi arsitektur, tujuan, dan tingkat kerumitannya beda banget. Yuk, kita bedah satu-satu biar kalian nggak salah pilih.

Ibaratnya Kayak Apa, Sih?

Biar gampang, bayangin pengelolaan berkas dokumen kantor.

Table Partitioning itu kayak satu lemari arsip besar yang dikasih sekat laci. Berkasnya udah menumpuk setinggi gunung, jadi kalian pasang sekat bertanda Laci 2024, Laci 2025, dan Laci 2026. Semua tetap di lemari fisik yang sama—satu server database. Pas staf nyari surat Mei 2025, dia langsung buka Laci 2025 tanpa nyisir laci tahun lain. Proses instan inilah yang disebut Partition Pruning.

Database Sharding itu beda cerita. Kalau lemarinya udah penuh sampai ruangan kantor nggak muat, kalian malah nyewa 3 gedung gudang terpisah: Jakarta, Surabaya, dan Medan. Berkas nasabah Jawa barat masuk Jakarta, Jawa timur masuk Surabaya, Sumatra masuk Medan. Datanya benar-benar tersebar di mesin fisik yang berbeda. Jadi, kalau gudang Jakarta kebanjiran, gudang Surabaya dan Medan tetap jalan normal.

Sebenernya Apa Sih Table Partitioning Itu?

Partitioning itu fitur bawaan dari sistem manajemen database relasional modern kayak PostgreSQL dan MySQL.

Secara logis, aplikasi tetap lihat datanya sebagai satu tabel utuh—misal orders. Tapi secara fisik di level disk, database mecahnya jadi tabel-tabel partisi yang lebih kecil.

Tipe partitioning yang populer ada tiga:

1. Range Partitioning—mecah data berdasarkan rentang nilai, paling umum berdasarkan tanggal. Contohnya orders_2026_q1, orders_2026_q2.
2. List Partitioning—mecah data berdasarkan daftar nilai diskret, misal kode negara: ID, SG, MY.
3. Hash Partitioning—mecah data secara merata pakai fungsi modulo hash dari kolom kunci.

Di PostgreSQL, deklarasi partisinya ngangenin banget:

-- 1. Buat master table dengan partisi Range tanggal
CREATE TABLE orders (
    order_id BIGSERIAL,
    customer_id BIGINT NOT NULL,
    order_date DATE NOT NULL,
    total_amount NUMERIC(12, 2),
    status VARCHAR(20),
    PRIMARY KEY (order_id, order_date)
) PARTITION BY RANGE (order_date);

-- 2. Buat partisi fisik untuk kuartal 1 & 2 tahun 2026
CREATE TABLE orders_2026_q1 PARTITION OF orders
    FOR VALUES FROM ('2026-01-01') TO ('2026-04-01');

CREATE TABLE orders_2026_q2 PARTITION OF orders
    FOR VALUES FROM ('2026-04-01') TO ('2026-07-01');

Ketika aplikasi jalankan SELECT * FROM orders WHERE order_date = '2026-02-15', PostgreSQL otomatis cuma memindai orders_2026_q1 dan ngabaikan partisi lainnya. Itu Partition Pruning yang tadi kita singgung. 😎

Oh iya, perhatiin kolom order_date harus ikut jadi bagian primary key. Soalnya, PostgreSQL mewajibkan kolom partisi masuk ke key uniknya. Kalau nggak, CREATE TABLE-nya bakal langsung ngamuk.

Terus, Database Sharding Itu Apa Bedaannya?

Kalau Partitioning mecah tabel di dalam satu server, Sharding justru ngedistribusikan data ke banyak server database mandiri yang disebut shard.

Tiap server shard adalah instance database lengkap yang nyimpen subset data tertentu. Arsitektur ini bentuk sejati dari Horizontal Scaling (Scale-Out).

Kunci suksesnya adalah milih sharding key yang tepat buat memetakan data ke shard tujuan:

1. Hash-Based Sharding—hitung nilai hash dari ID, misal hash(user_id) % jumlah_shard. Distribusinya merata, tapi range query jadi susah. Buat nambah atau ngurangin jumlah shard tanpa bikin data berantakan, teknik consistent hashing sering dipakai.
2. Range-Based Sharding—mecah berdasarkan rentang alfabet atau wilayah, misal user A–M di Shard 1 dan N–Z di Shard 2. Rentan bikin Hotspot Shard kalau satu kelompok data jauh lebih aktif.
3. Directory / Lookup-Based Sharding—nyimpen tabel pemetaan terpusat (lookup service) yang nyatet ID mana ada di shard mana. Fleksibel banget, tapi tabel lookup-nya bisa jadi single point of failure dan bottleneck baru.

Apa Aja Sih Susahnya Sharding?

Jangan buru-buru sharding sebelum benar-benar kepepet, ya. Kerumitan arsitekturnya bukan main. 😅

Pertama, kita kehilangan Cross-Shard JOIN. Tabel pelanggan di Shard A dan tabel transaksi di Shard B nggak bisa lagi di-JOIN pakai SQL biasa. Query-nya harus digabung manual di level aplikasi backend (Application-Level Join).

Kedua, muncul urusan transaksi terdistribusi. Menjamin prinsip ACID di beberapa server fisik butuh protokol Two-Phase Commit (2PC) atau Saga Pattern yang ribet dan lambat.

Ketiga, ada Re-Sharding. Pas kapasitas 4 shard udah penuh dan kalian mau nambah jadi 8, memindahkan data lama antar server (data rebalancing) tanpa downtime itu pekerjaan yang bikin keringetan.

Biar nggak bikin pusing sendiri, ekosistem cloud modern nyediain middleware terdistribusi kayak Vitess buat MySQL skala raksasa, Citus Data buat PostgreSQL, atau database NewSQL kayak CockroachDB.

Kapan Pakai Partitioning, Kapan Baru Sharding?

Penskalaan database itu perjalanan bertahap, jadi urutannya penting:

1. Optimasi dulu yang murah: rapikan query, pasang index komposit, dan cache data panas (hot data) di Redis.
2. Baru pakai Table Partitioning kalau data historis—log, audit trail, order lama—mulai menumpuk di satu server, dan kapasitas disk maupun RAM-nya masih cukup. Bonusnya, hapus data kedaluwarsa jadi cepet: DROP TABLE partisi lama jauh lebih gesit ketimbang DELETE FROM ... WHERE date < ....
3. Database Sharding cuma kalau volume data dan write throughput udah ngelewatin kapasitas mesin terbesar yang bisa disewa (Vertical Scale Limit), atau sistem butuh isolasi data per wilayah geografis (data residency compliance).

Jadi, Kapan Data Bener-bener Perlu Dipecah?

Partitioning itu langkah rapi buat ngatur tabel raksasa yang masih betah di satu mesin. Sedangkan sharding adalah senjata pamungkas, dipakai pas satu server bener-bener udah nggak mampu lagi.

Mulailah dari yang murah: optimasi query, connection pool, dan caching. Naik ke partitioning kalau dirasa perlu. Baru deh, pertimbangkan sharding kalau sistem udah menembus skala jutaan transaksi per detik di panggung global.

Selamat ber-scaling ria, dan semoga data kalian tetap rapi tersimpan di laci-laci shard-nya! 👋