# Strategi Sharding PostgreSQL: Kapan dan Bagaimana Menskalakan Database Anda

> Panduan pragmatis tentang sharding dan partisi PostgreSQL — mencakup partisi tabel, tabel terdistribusi Citus, dan kebenaran jujur tentang kapan Anda benar-benar perlu melakukan sharding.

URL: https://www.matthewswong.com/id/blog/postgresql-sharding-strategy/

- Author: Matthews Wong (https://www.matthewswong.com/id/about/)
- Published: 2025-06-10
- Updated: 2026-10-17
- Category: DevOps

PostgreSQL dapat menangani jutaan baris dan ribuan koneksi bersamaan pada satu node — sebagian besar aplikasi tidak pernah membutuhkan sharding. Tetapi ketika Anda memang melampaui ambang batas itu, keputusan sharding membentuk seluruh arsitektur Anda selama bertahun-tahun. Pada beban kerja bergaya ERP, satu node database sering kali menangani seluruh data perusahaan dengan nyaman. Panduan ini mencakup spektrum dari partisi tabel (yang dapat dan harus Anda lakukan lebih awal) hingga sharding terdistribusi penuh dengan Citus.

## Spektrum: Partisi vs Sharding

Partisi dan sharding saling berkaitan tetapi berbeda. Partisi membagi tabel besar menjadi tabel fisik yang lebih kecil (partisi) pada node database yang sama. Ini meningkatkan kinerja kueri dengan pemangkasan — kueri dengan klausa WHERE pada kunci partisi hanya memindai partisi yang relevan. Sharding mendistribusikan partisi tersebut ke beberapa node database, memungkinkan scale-out horizontal.

### Partisi Tabel Asli PostgreSQL

PostgreSQL telah mendukung partisi tabel deklaratif sejak versi 10. Dua strategi yang paling berguna adalah partisi RANGE (berdasarkan tanggal — sangat baik untuk data time-series seperti log audit, event, dan invoice) dan partisi HASH (berdasarkan hash ID tenant atau ID pengguna). Untuk tabel audit_logs sistem ERP dengan jutaan baris per tahun, partisi berdasarkan bulan mengurangi waktu kueri dari detik menjadi milidetik.

> Untuk tabel audit trail di sebuah ERP: partisi tabel bervolume tinggi Anda berdasarkan created_at bulan dari hari pertama. Jalur migrasi dari tabel yang tidak dipartisi ke yang dipartisi itu menyakitkan — Anda perlu mengganti nama tabel lama, membuat induk yang dipartisi baru, menyalin data, dan melakukan swap. Melakukannya di awal ketika tabel kosong hampir tidak memerlukan biaya dan menghemat jendela pemeliharaan darurat ketika tabel mencapai 50 juta baris.

## Citus: PostgreSQL Terdistribusi

Citus memperluas PostgreSQL dengan eksekusi kueri terdistribusi di seluruh node koordinator dan node pekerja. Tabel didistribusikan melalui kolom distribusi — Citus hash nilai kolom dan menugaskan setiap shard (subset baris) ke node pekerja. Citus 12 memperkenalkan sharding berbasis skema, yang ideal untuk SaaS multi-tenant — setiap tenant mendapatkan skema mereka sendiri, dan Citus memperlakukan skema sebagai batas shard.

### Memilih Kolom Distribusi yang Tepat

Pilihan kolom distribusi menentukan kinerja kueri. Aturan emas: kueri yang memfilter pada kolom distribusi cepat; kueri yang tidak adalah scatter-gather (menyentuh semua shard). Untuk ERP multi-tenant, tenant_id adalah kolom distribusi yang jelas — semua kueri dari sesi tenant memfilter pada tenant_id mereka, sehingga lokalitas data dimaksimalkan.

> **Sharding memperumit foreign key dan join**

> Dalam pengaturan PostgreSQL yang di-shard, foreign key dan join lintas shard tidak tersedia atau sangat mahal. Anda kehilangan jaminan integritas referensial standar — Anda harus menerapkannya di lapisan aplikasi. Transaksi yang mencakup beberapa shard memerlukan protokol transaksi terdistribusi. Migrasi skema harus diterapkan ke semua shard secara bersamaan. Jangan lakukan sharding sampai Anda benar-benar menghabiskan penskalaan vertikal.

## Kapan Anda Benar-benar Membutuhkan Sharding

Sinyal yang menunjukkan Anda membutuhkan sharding: CPU atau I/O node database utama Anda secara konsisten di atas 70% meskipun ada optimasi kueri dan pengindeksan; tabel terbesar Anda dalam ratusan gigabyte dan tumbuh lebih cepat dari yang dapat Anda tambahkan penyimpanan; Anda memiliki arsitektur multi-tenant di mana isolasi data tenant adalah persyaratan keras.

## Read Replica Sebelum Sharding

Sebelum mempertimbangkan sharding, tambahkan read replica PostgreSQL. Sebagian besar aplikasi berat dalam membaca — 80-90% kueri adalah bacaan. Primary + 2 read replica melipattigakan kapasitas baca Anda tanpa perubahan skema. Arahkan kueri analitik, pembuatan laporan, dan endpoint API hanya-baca ke replica; arahkan penulisan ke primary.

## Jalur Migrasi: Dari Single Node ke Sharded

Migrasi dari node PostgreSQL tunggal ke kluster Citus yang di-shard adalah non-trivial. Jalur yang direkomendasikan: pertama tambahkan partisi ke tabel terbesar Anda di node tunggal. Kemudian provisikan koordinator Citus + pekerja. Migrasikan tabel yang dipartisi ke tabel terdistribusi menggunakan create_distributed_table() Citus. Perbarui string koneksi aplikasi Anda untuk menunjuk ke koordinator Citus. Rencanakan 2-4 minggu pekerjaan migrasi untuk database besar.

## Sumber & Bacaan Lebih Lanjut

- Citus Data / Microsoft — Understanding Partitioning and Sharding in Postgres and Citus
- Citus Docs — Choosing Distribution Column
- PostgreSQL Documentation — Table Partitioning

## Source links

- https://www.citusdata.com/blog/2023/08/04/understanding-partitioning-and-sharding-in-postgres-and-citus/
- https://docs.citusdata.com/en/stable/sharding/data_modeling.html
- https://www.postgresql.org/docs/current/ddl-partitioning.html

## FAQ

### Apa perbedaan antara partisi tabel dan sharding di PostgreSQL?

Partisi tabel membagi tabel besar menjadi partisi fisik yang lebih kecil pada node database yang sama, meningkatkan kinerja kueri melalui pemangkasan partisi. Sharding melangkah lebih jauh dengan mendistribusikan partisi tersebut ke beberapa node database untuk memungkinkan scale-out horizontal. Anda bisa menggunakan partisi tanpa sharding — artikel ini merekomendasikan memulai dengan partisi terlebih dahulu dan menambahkan sharding hanya ketika penskalaan vertikal benar-benar sudah habis.

### Kapan deployment PostgreSQL benar-benar membutuhkan sharding?

Artikel ini mengidentifikasi sinyal yang jelas: CPU atau I/O node utama secara konsisten di atas 70% meski sudah dioptimasi, tabel terbesar mencapai ratusan gigabyte dan terus tumbuh, isolasi data tenant adalah persyaratan arsitektur yang wajib, atau jendela backup dan restore sudah terlalu lama. Jika tidak ada kondisi tersebut yang berlaku, langkah yang tepat adalah pengindeksan yang lebih baik, optimasi kueri, atau read replica — bukan sharding.

### Bagaimana cara memilih kolom distribusi yang tepat saat menggunakan Citus?

Kolom distribusi menentukan apakah kueri hanya menyentuh satu shard atau menyebar ke semua shard. Aturan emas dari artikel ini: kueri yang memfilter pada kolom distribusi berjalan cepat; kueri yang tidak adalah operasi scatter-gather yang menyentuh setiap shard. Untuk ERP multi-tenant, tenant_id adalah pilihan yang jelas karena semua kueri dalam sesi tenant sudah memfilter berdasarkan kolom tersebut. Hindari kolom dengan distribusi nilai yang miring atau kolom yang sering berubah.

### Mengapa sebaiknya menambahkan read replica sebelum mempertimbangkan sharding?

Sebagian besar aplikasi lebih banyak membaca — artikel ini mencatat bahwa 80–90% kueri adalah operasi baca. Menambahkan satu primary ditambah dua read replica melipattigakan kapasitas baca tanpa perubahan skema, cukup dengan mengarahkan kueri analitik, pembuatan laporan, dan endpoint API hanya-baca ke replica, serta penulisan ke primary. Ini hanya perubahan konfigurasi di framework seperti NestJS dengan TypeORM atau Prisma, dan memberikan ruang yang signifikan sebelum sharding diperlukan.

### Apa saja trade-off dan komplikasi utama yang muncul akibat sharding?

Sharding menghilangkan jaminan integritas referensial standar — foreign key dan join lintas shard tidak tersedia atau sangat mahal, sehingga integritas harus diterapkan di lapisan aplikasi. Transaksi yang mencakup beberapa shard memerlukan protokol transaksi terdistribusi, dan migrasi skema harus diterapkan ke semua shard secara bersamaan. Artikel ini juga memperingatkan bahwa migrasi dari single node ke kluster Citus adalah proses yang tidak sepele, dengan rekomendasi merencanakan 2–4 minggu pekerjaan migrasi untuk database besar.

---

- HTML version: https://www.matthewswong.com/id/blog/postgresql-sharding-strategy/
- English: https://www.matthewswong.com/en/blog/postgresql-sharding-strategy/
- Site index for agents: https://www.matthewswong.com/llms.txt
- Sitemap: https://www.matthewswong.com/sitemap.xml
- API description (OpenAPI): https://www.matthewswong.com/openapi.json