PostgreSQL 14 EOL 12 November 2026: Rencana Upgrade ke 18

PostgreSQL 14 memasuki akhir masa dukungan pada 12 November 2026, sekitar dua minggu setelah batch artikel ini disusun. Data resmi di postgresql.org/versions.json mencatat rilis pertama PostgreSQL 14 adalah 30 September 2021 dengan masa dukungan lima tahun, sementara versi terbaru yang dilayani saat ini adalah 18.6 dan minor terakhir untuk jalur 14 adalah 14.24. Setelah tanggal itu, tidak ada lagi patch keamanan, tidak ada perbaikan bug, dan tidak ada rilis minor baru untuk jalur 14.

Berapa lama lagi PostgreSQL 14 didukung?

Sampai 12 November 2026. Kebijakan versi PostgreSQL memberi lima tahun dukungan penuh per major, dan jalur 14 dimulai 30 September 2021 sehingga berakhir pada November 2026. Sesudah itu, server 14 tetap bisa dijalankan, tetapi tidak lagi menerima perbaikan keamanan dari proyek PostgreSQL.

Angka di atas bukan perkiraan. Berkas versions.json yang dipublikasikan proyek PostgreSQL memuat baris untuk tiap major: tanggal rilis pertama, tanggal akhir dukungan, dan nomor minor terakhir. Untuk jalur 14, catatan itu berbunyi rilis 30 September 2021 dan akhir dukungan 12 November 2026. Halaman kebijakan versioning di situs yang sama menjelaskan aturannya: lima tahun sejak rilis pertama, dengan satu rilis minor tiap kuartal dalam masa dukungan.

Masalahnya bukan soal versi ketinggalan zaman. Masalahnya adalah CVE yang tidak lagi ditambal di jalur 14. Ketika proyek PostgreSQL merilis patch keamanan untuk 15, 16, 17, dan 18, jalur 14 tidak ikut. Artinya satu VPS dengan PostgreSQL 14 yang terbuka ke publik akan makin lama makin jadi target yang mudah, karena celah yang sudah diperbaiki di jalur lain tetap terbuka di situ.

Versi mana yang sebaiknya jadi tujuan upgrade?

Tujuan paling masuk akal adalah PostgreSQL 18, karena itu versi current dengan masa dukungan sampai 14 November 2030, sehingga satu kali kerja pindah bisa menutup empat tahun ke depan. Jalur 17 bisa jadi pilihan realistis kalau ada ekstensi yang belum mendukung 18, dengan catatan masih perlu upgrade lagi sebelum 8 November 2029.

Tabel di bawah merangkum jalur yang masih hidup berdasarkan versions.json proyek PostgreSQL per 30 Oktober 2026. Yang perlu diperhatikan bukan cuma tanggal akhir, tapi juga jarak antarjalur: kalau server masih di 14, lompatan ke 18 berarti empat major sekaligus, dan itu bukan pekerjaan satu jam.

Major	Rilis pertama	Akhir dukungan	Minor terakhir	Status
14	30 September 2021	12 November 2026	14.24	Habis dalam hitungan hari
15	13 Oktober 2022	11 November 2027	15.19	Masih didukung
16	14 September 2023	9 November 2028	16.15	Masih didukung
17	26 September 2024	8 November 2029	17.11	Masih didukung
18	25 September 2025	14 November 2030	18.6	Current

Dua kolom terakhir sengaja dipasang berdampingan. Nomor minor terus naik selama masa dukungan karena proyek PostgreSQL merilis patch kuartalan, dan setiap patch membawa perbaikan keamanan. Selisih antara 14.24 dan patch berikutnya yang tidak akan pernah terbit itulah yang jadi risiko nyata, bukan selisih nomor major.

Kapan harus pakai pg_upgrade dan kapan dump-restore?

Pakai pg_upgrade kalau ukuran basis data besar dan downtime harus pendek, karena metode ini memindahkan berkas data lama ke format baru tanpa menyalin seluruh isi tabel. Pakai dump dan restore kalau basis data kecil, lintas platform, atau ada ekstensi yang tidak kompatibel, karena cara itu menghasilkan cluster yang bersih dari sisa konfigurasi lama.

Dokumentasi pg_upgrade menyebut dua mode: mode salin yang menulis ulang seluruh berkas, dan mode link yang membuat hard link sehingga prosesnya jauh lebih cepat tetapi cluster lama tidak bisa dipakai lagi setelahnya. Untuk VPS dengan disk terbatas, mode link sering jadi satu-satunya pilihan yang muat, dengan konsekuensi harus ada backup fisik sebelum eksekusi.

Yang sering terlewat bukan perintah utamanya, tapi empat hal di sekitarnya. Pertama, binary lama dan baru harus tersedia bersamaan; di Debian dan Ubuntu itu berarti memasang paket postgresql-18 tanpa menghapus postgresql-14 dulu. Kedua, ekstensi harus punya versi yang cocok untuk major tujuan, misalnya PostGIS atau pg_stat_statements. Ketiga, jalur data di konfigurasi baru harus menunjuk ke direktori cluster hasil initdb baru, bukan direktori lama. Keempat, setelah upgrade selesai, jalankan analyze supaya planner punya statistik yang benar.

Bagaimana urutan kerja yang aman untuk server produksi?

Urutan paling aman adalah mengukur dulu, mencoba di salinan, baru memotong produksi. Tanpa salinan uji, kesalahan konfigurasi kecil seperti port, socket directory, atau locale bisa memaksa rollback di tengah jendela maintenance yang sudah diumumkan ke pengguna.

1. Catat versi dan ekstensi yang terpasang: SELECT version(), lalu daftar isi pg_extension dan pg_available_extensions.
2. Ukur ukuran basis data dan tabel terbesar, supaya perkiraan waktu salin atau link masuk akal.
3. Ambil backup fisik dan uji restore ke mesin lain. Backup yang belum pernah direstore belum terbukti bisa dipakai.
4. Pasang binary major tujuan di samping binary lama, lalu jalankan initdb untuk cluster baru.
5. Jalankan pg_upgrade dengan flag pemeriksaan lebih dulu, baru eksekusi penuh.
6. Nyalakan cluster baru di port berbeda, lalu jalankan aplikasi ke sana sebelum mengubah port produksi.
7. Setelah yakin, hentikan cluster lama, pindahkan port, dan simpan backup di tempat terpisah dari server.

Poin keenam adalah yang paling menentukan. Menjalankan aplikasi nyata ke cluster baru sebelum memotong port memberi kesempatan menemukan masalah query, tipe data, atau ekstensi saat jalur rollback masih murah. Praktik ini juga membuat pengujian tidak bergantung pada asumsi bahwa pg_upgrade yang exit tanpa error berarti semuanya beres.

Untuk tim yang tidak bisa menanggung downtime sama sekali, jalur lain adalah logical replication: cluster baru diisi lewat subscription, lalu di-cutover saat lag mendekati nol. Cara ini memakan waktu lebih lama di awal, tapi memindahkan risiko ke fase yang bisa diulang.

Bagaimana mengecek apakah infrastruktur masih memakai jalur 14?

Jalankan SELECT version() di setiap instance dan bandingkan nomor majornya. Server yang menjawab PostgreSQL 14.x berarti masih di jalur yang habis 12 November 2026, sementara jawaban 15.x ke atas berarti sudah lewat dari risiko ini.

Pemeriksaan yang sama perlu dilakukan pada instance yang mudah terlupa: replica baca, server staging, database aplikasi internal, dan container lama yang masih dipakai untuk analitik. Satu instance 14 yang tertinggal di jaringan internal tetap jadi pintu masuk, karena patch keamanan tidak lagi datang untuknya.

Kalau setelah 12 November 2026 masih ada instance 14, prioritaskan menutup akses jaringannya dulu, baru menyusun jadwal upgrade. Menutup akses adalah tindakan yang bisa dilakukan hari itu juga, sementara upgrade butuh jendela waktu dan pengujian.

Untuk perencanaan kapasitas, patokan kasar yang dipakai banyak tim: satu jendela maintenance dua sampai empat jam cukup untuk basis data berukuran puluhan gigabyte dengan pg_upgrade mode link, sementara basis data ratusan gigabyte lebih aman dipecah menjadi beberapa tahap dengan logical replication. Angka ini bergantung pada kecepatan disk VPS, jumlah indeks, dan jumlah tabel, jadi pengukuran di salinan tetap wajib sebelum jadwal dipotong produksi.

Apa yang paling sering rusak setelah upgrade major?

Tiga hal paling sering menimbulkan kejutan: perilaku collation pada kolom teks, ekstensi yang belum punya versi untuk major baru, dan rencana query yang berubah karena statistik belum dikumpulkan. Ketiganya bukan kegagalan data, tapi gejalanya sering terbaca seperti data hilang.

Collation menentukan urutan hasil ORDER BY dan cara perbandingan teks. Ketika cluster baru memakai definisi collation yang berbeda dari cluster lama, urutan nama pada aplikasi bisa berubah, dan indeks unik yang dulu lolos bisa menolak nilai tertentu. Cara mendeteksinya sederhana: bandingkan hasil query ORDER BY pada kolom teks antara cluster lama dan baru memakai potongan data yang sama.

Ekstensi adalah sumber masalah kedua. pg_upgrade akan berhenti kalau ada ekstensi yang tidak dikenal di cluster tujuan, dan itu sebenarnya kabar baik karena gagal di awal lebih murah daripada gagal saat aplikasi berjalan. Sebelum eksekusi, daftar ekstensi yang terpasang dan pastikan tiap ekstensi punya paket untuk major tujuan.

Yang ketiga adalah statistik. Cluster hasil pg_upgrade membawa tabel dan indeks, tetapi planner butuh statistik yang baru untuk memilih rencana eksekusi. Dokumentasi pg_upgrade menyarankan menjalankan analyze setelah proses selesai, dan pada tabel besar langkah ini sebaiknya dipecah bertahap supaya tidak menahan I/O terlalu lama.

Satu hal lagi yang jarang masuk catatan: objek global seperti role, tablespace, dan konfigurasi autentikasi tidak ikut dalam pg_upgrade. Untuk itu, pg_dumpall dengan flag globals-only adalah cara standar memindahkan role beserta atributnya, dan hasilnya perlu diperiksa sebelum cluster baru diaktifkan.

FAQ

Apakah PostgreSQL 14 langsung mati pada 12 November 2026?

Tidak. Server tetap menyala dan menerima query, tetapi tidak lagi mendapat patch keamanan maupun perbaikan bug dari proyek PostgreSQL. Setelah tanggal itu, satu-satunya sumber perbaikan adalah distributor paket, dan itu pun terbatas.

Apakah upgrade minor dari 14.20 ke 14.24 butuh dump dan restore?

Tidak. Upgrade minor dalam satu major cukup dengan mengganti binary lalu restart, karena format data tidak berubah. Yang butuh pg_upgrade atau dump-restore adalah lompatan antar-major, misalnya 14 ke 18.

Bisakah langsung lompat dari 14 ke 18 dengan pg_upgrade?

Bisa, karena pg_upgrade mendukung lompatan langsung antar-major selama binary tujuan tersedia dan ekstensi kompatibel. Yang tidak didukung adalah menjalankan pg_upgrade antar-arsitektur berbeda atau antar-sistem operasi yang berbeda tanpa langkah tambahan.

Berapa lama masa dukungan tiap major PostgreSQL?

Lima tahun sejak rilis pertama, sesuai halaman versioning proyek. Untuk jalur 18 yang rilis 25 September 2025, akhir dukungan jatuh pada 14 November 2030, jadi satu kali pindah ke 18 menutup empat tahun ke depan.