PostgreSQL 14 mencapai akhir masa dukungannya pada 12 November 2026. Mulai tanggal itu, PostgreSQL Global Development Group tidak lagi merilis pembaruan bug maupun keamanan untuk versi tersebut, dan kerentanan yang ditemukan di tahun-tahun berikutnya akan tetap ada tanpa tambalan resmi. Database produksi yang masih berjalan di PG 14 kini menumpang pada keberuntungan, bukan pada dukungan.
Kabar baiknya: jadwal ini bukan kejutan. Siklus dukungan PostgreSQL sudah bertahun-tahun konsisten lima tahun per versi besar, dan PG 14 dirilis September 2021. Tim yang menjalankan inventaris database yang sehat seharusnya sudah punya rencana sejak PG 14 masuk tahun terakhirnya. Artikel ini merangkum pilihan upgrade yang tersedia, perangkap yang sering muncul, dan urutan kerja yang realistis untuk database produksi.
Cek Versi dan Inventaris Sebelum Memilih Jalur
Mulai dari fakta di lapangan, bukan dari hafalan:
psql -At -c “SELECT version();”
psql -At -c “SELECT extname, extversion FROM pg_extension ORDER BY 1;”
Baris kedua penting karena hambatan upgrade paling sering bukan di core PostgreSQL, melainkan di extension yang belum menyediakan build untuk versi besar tujuan. Catat juga versi OS dan cara instalasi: Ubuntu 24.04 membawa PostgreSQL 16 dari arsip resmi distro, jadi lompatan dari 14 ke 16 atau lebih baru biasanya berarti menambah repositori PGDG terlebih dahulu.
Tiga Jalur Upgrade dan Kapan Masing-masing Layak
- pg_upgrade adalah jalur in-place. Database baru dibuat di cluster versi tujuan, berkas data dipindahkan atau ditautkan, dan hasilnya berjalan cepat bahkan untuk ukuran besar. Imbangannya adalah downtime: database harus berhenti selama proses, dan rollback berarti kembali ke cluster lama dengan data yang sudah berubah. Jalankan pg_upgrade –check jauh sebelum hari-H untuk menangkap mismatch extension dan encoding sejak dini.
- Logical replication mengalirkan perubahan dari cluster lama ke cluster baru yang tetap hidup. Downtime nyata hanya satu momen switchover berupa berhenti tulis sesaat, urutkan sequence, dan arahkan aplikasi. Jalur ini layak untuk database yang tidak boleh berhenti pada jam kerja, dengan dua perangkap yang wajib dijadwalkan: perubahan skema (DDL) tidak direplikasi otomatis, dan posisi sequence tidak ikut mengalir sehingga harus disinkronkan manual sebelum switchover.
- Dump dan restore lewat pg_dump adalah jalur paling sederhana dan paling lambat. Semantik hasilnya bersih karena seluruh objek dibangun ulang, tetapi durasi tumbuh linear dengan ukuran data. Layak untuk database kecil-menengah atau lingkungan staging, bukan untuk cluster ratusan gigabyte yang jadwal downtime-nya mahal.
Versi tujuan: bergeser langsung ke versi besar terbaru yang sudah matang di lingkungan Anda. Lompatan antar banyak versi besar didukung pg_upgrade, jadi menargetkan versi sekarang sekaligus mengurangi frekuensi upgrade berikutnya, asalkan aplikasi dan extension sudah diuji di sana.
Satu aturan yang berlaku untuk ketiga jalur: backup yang bisa direstore dibuat sebelum langkah pertama, dan jadwal pengujian restore sama dengan jadwal upgrade itu sendiri. pg_upgrade mengubah berkas data secara tidak bisa-dikembalikan pada cluster tujuan, logical replication tidak menyalin objek yang luput dari publication, dan restore dari dump adalah satu-satunya jaminan yang tidak bergantung pada jalur upgrade mana pun berjalan mulus. Database tanpa backup teruji yang berencana upgrade besar adalah dua proyek risiko, bukan satu.
Urutan Kerja yang Realistis
- Bangun cluster versi tujuan di staging dengan salinan data produksi, jalankan aplikasi sungguhan di atasnya, dan biarkan berjalan beberapa hari. Uji dengan rencana query yang sama: perubahan planner antar versi besar kadang mengubah performa query tertentu, dan ini terlihat hanya dengan trafik nyata.
- Untuk jalur logical replication, siapkan publication di sumber dan subscription di tujuan, tunggu initial sync selesai, lalu latih prosedur switchover berulang kali di staging sampai satu orang bisa menjalankannya dari runbook tanpa improvisasi.
- Cek kompatibilitas driver klien dan pooler. Versi lama libpq atau driver JDBC biasanya tetap jalan, tetapi fitur baru protokol hanya terbuka dengan versi terbaru. Jangan biarkan pertanyaan ini muncul pertama kali saat switchover.
- Jadwalkan jendela pemeliharaan meski pakai logical replication, karena ada komponen yang tetap perlu perhatian: analisis ulang statistik di cluster baru agar planner punya data segar, dan penghapusan cluster lama hanya setelah masa observasi berlalu.
Setelah Upgrade: Jangan Biarkan Siklus Ini Berulang
Upgrade yang baru selesai adalah momen terbaik untuk mencegah kejadian yang sama. Dua kebiasaan yang menahan akumulasi utang versi: catat tanggal akhir dukungan setiap versi besar yang berjalan di inventaris, dan sediakan satu lingkungan staging yang bisa menampung versi besar berikutnya kapan pun, sehingga pengujian kompatibilitas jadi rutin, bukan proyek. Database yang selalu berada satu versi besar di belakang yang terbaru itu kondisi yang sehat; yang berjalan di versi tanpa dukungan bukan kondisi, melainkan kutipan risiko yang menunggu tanggal.
Referensi
- Kebijakan dukungan versi PostgreSQL: https://www.postgresql.org/support/versioning/
- Dokumentasi pg_upgrade: https://www.postgresql.org/docs/current/pgupgrade.html
- Dokumentasi logical replication: https://www.postgresql.org/docs/current/logical-replication.html
- Repositori paket PGDG untuk Ubuntu: https://www.postgresql.org/download/linux/ubuntu/