Pertanyaan yang sering diajukan
- Kapan Postgres benar-benar kehabisan kapasitas?
- Setelah indeks, pooling, partisi, replica, dan write async diterapkan—bukan saat satu query lambat muncul di APM.
- Apakah semua read harus ke replica?
- Tidak—simpan read transaksional di primary; arahkan analitik dan ekspor yang toleran lag ke replica.
- Apakah sharding sering menjadi langkah pertama yang tepat?
- Jarang. Sharding tanpa profil tabel panas yang jelas biasanya menggandakan biaya operasional tanpa memperbaiki akar masalah.
Kebanyakan tim yang mengira perlu menulis ulang database sebenarnya butuh beberapa perubahan Postgres yang tepat. Berikut lima yang kami rekomendasikan, berurutan prioritas.
1. Apakah indeks cocok dengan query nyata?
EXPLAIN ANALYZE pada setiap query di puncak APM. Jika query menyentuh tabel >100k baris dan indeks tidak terlihat di plan, perbaiki itu dulu. Indeks komposit yang cocok dengan bentuk WHERE + ORDER BY membalas dalam hitungan hari.
2. Apakah connection pooling dikonfigurasi benar?
Instance Postgres dengan 200 slot koneksi akan jatuh jauh sebelum kehabisan CPU. Pasang PgBouncer (atau setara cloud) di depan setiap app server, dan alokasikan koneksi per layanan.
3. Bisakah baris dingin dipindah dari jalur panas?
Jika 80% baris hanya dibaca sekali setahun, partisi berdasarkan tanggal atau pindahkan ke tabel cold_*. Tabel panas muat di memori; tabel dingin tidak harus.
4. Apakah read replica dipakai untuk workload yang tepat?
Replica mudah ditambah dan mudah disalahgunakan. Kirim query mahal tetapi toleran lag (dashboard analitik, ekspor) ke replica. Simpan read transaksional di primary.
5. Haruskah efek samping berat tetap di transaksi request?
Jika mengirim email, mengindeks dokumen pencarian, atau memperbarui counter denormalisasi dalam transaksi yang sama dengan write yang terlihat pengguna, pindahkan ke background job. Latensi, throughput, dan reliabilitas membaik.
Poin penting
- Indeks dan pool sebelum shard—kebanyakan momen "butuh database baru" bisa diperbaiki di Postgres.
- Partisi atau arsip data dingin agar working set tetap di memori.
- Shard hanya saat pola akses terdokumentasi dan tabel panas jelas.
Kapan benar-benar perlu shard?
Setelah kelima langkah di atas. Jika Postgres tunggal masih tidak cukup, Anda punya gambaran jelas tabel dan pola akses mana yang di-shard—dan waktu satu tahun lagi untuk melakukannya dengan baik.