PostgreSQL 19 Terbit 19 November, Sebagian Fiturnya Resmi Dibatalkan

Bismillahirrohmanirohim..

Ada satu kebiasaan komunitas PostgreSQL yang menurut saya jarang ditiru proyek lain: kalau sebuah fitur belum benar-benar siap, fitur itu dibuang — bukan dipaksakan masuk lalu ditambal belakangan. Bulan ini kebiasaan itu kelihatan sangat jelas di PostgreSQL 19, rilis mayor yang tadinya diperkirakan mendarat Oktober, lalu harus puas dengan tanggal baru: 19 November 2026.

Dua tanggal perlu dicatat di kalender: 12 November dan 19 November. Yang pertama adalah hari terakhir hidup PostgreSQL 14. Yang kedua adalah hari lahir PostgreSQL 19. Seminggu berselang, satu versi pensiun dan satu versi baru mulai bekerja.

Oke, mari saya ceritakan apa yang sebenarnya terjadi.

Kenapa PostgreSQL 19 baru terbit 19 November

Pengumuman resminya keluar 15 Oktober 2026: PostgreSQL 19 RC 1 sudah bisa diunduh. Biasanya satu release candidate cukup, lalu beberapa minggu kemudian versi final keluar. Kali ini tidak.

Alasannya ditulis sendiri oleh PostgreSQL Global Development Group di pengumuman RC 1. Jadwal pembaruan rutin untuk semua versi yang masih didukung jatuh pada 12 November 2026, dan pembaruan itu akan membawa “sejumlah besar perbaikan”. Daripada merilis 19 lebih dulu lalu mengejar dengan tambalan, tim rilis memilih memasukkan perbaikan itu ke dalam 19.

Konsekuensinya: akan ada RC 2 pada 12 November, bersamaan dengan pembaruan rutin tersebut, dan general availability 19 November. Tanggal itu masih bisa bergeser kalau ada masalah yang menuntut RC tambahan.

Jujur, saya suka cara berpikirnya. Menunda seminggu demi memasukkan perbaikan yang sudah ada di tangan jauh lebih murah daripada mengejar tanggal lalu menanggung akibatnya di server orang lain.

Fitur yang resmi dibatalkan

Bagian yang paling ramai dibicarakan justru terjadi lebih awal, pada Beta 4 (24 September). Dalam pengumuman beta itu, komunitas menyatakan sesuatu yang sangat jarang diucapkan proyek besar: mereka menarik sejumlah fitur yang sudah diumumkan.

Daftarnya bukan daftar sepele:

SQL/PGQ, yaitu kemampuan menanyakan tabel relasional sebagai property graph, lengkap dengan CREATE PROPERTY GRAPH dan GRAPH_TABLE.
Menyalakan atau mematikan data checksums saat server tetap online.
Update dan delete temporal lewat klausa FOR PORTION OF.
Perintah ALTER TABLE ... MERGE PARTITIONS dan SPLIT PARTITIONS.
Fungsi pg_get_role_ddl(), pg_get_tablespace_ddl(), dan pg_get_database_ddl().
Satu perubahan teknis yang memaksa LC_COLLATE menjadi C di proses postmaster.

Alasan yang tertulis di pengumuman Beta 4 singkat dan tegas. Komunitas “sangat percaya bahwa PostgreSQL harus, pertama dan terutama, andal”, dan mereka juga menjaga jadwal rilis yang bisa diprediksi. Karena tidak bisa mendapatkan keduanya sekaligus, fitur-fiturnya dikeluarkan dan disimpan untuk rilis mayor berikutnya.

Yang tersisa tetap bukan rilis kosong. Ada REPACK dengan opsi CONCURRENTLY yang merapikan tabel tanpa mengunci baca-tulis, ekstensi pg_plan_advice untuk menstabilkan keputusan planner, perintah WAIT supaya replica bisa menunggu sampai perubahan tertentu benar-benar sampai, autovacuum paralel untuk indeks, serta logical replication yang menyalin nilai sequence. Untuk pekerjaan harian di VPS, daftar itu lebih dari cukup.

Cerita di balik layar: AI ikut menemukan bug

Yang membuat kasus ini menarik buat saya adalah tulisan Peter Eisentraut, salah satu committer PostgreSQL, pada 9 Oktober. Judulnya cukup jujur: “The reverts will continue until morale improves”.

Di situ ia menyebut sekitar 8 sampai 10 fitur signifikan ditarik dari cabang 19 sejak beta dimulai — padahal satu revert per siklus sudah dianggap banyak.

Ia tidak mencari kambing hitam. Sebagian memang karena kodenya belum cukup baik, sebagian karena beberapa fitur punya cacat arsitektur yang tidak mungkin dibereskan cepat di tengah beta. Tapi ada satu faktor yang paling layak dicatat: review kode berbantuan LLM menemukan ekor masalah pinggiran jauh lebih cepat daripada cara manual. Dalam sekejap tim berhadapan dengan puluhan laporan cacat, dan meski rata-rata perbaikannya hanya tiga baris, tetap ada biaya tetap untuk menangani masing-masing — sampai kehabisan waktu.

Ada juga faktor kedua yang lebih membumi: antara April dan Agustus 2026, banyak pengembang senior tersedot menangani perbaikan keamanan (yang ia sebut “Vulnpocalypse”), sehingga review tambahan di masa beta berkurang. Itu sebabnya sebagian revert baru muncul sangat telat.

Satu kalimat Eisentraut yang saya garis bawahi sendiri: komunitas lebih memilih menjaga jadwal rilis daripada menunda demi mengejar lebih banyak perbaikan. Tidak populer, tapi konsisten dengan janji rilis mayor tahunan yang membuat PostgreSQL mudah dijadwalkan oleh tim ops.

12 November: deadline yang lebih mendesak

Sekarang bagian yang lebih praktis. Di halaman kebijakan versi PostgreSQL tertulis aturan yang sederhana: setiap versi mayor didukung lima tahun sejak rilis pertama, lalu satu pembaruan terakhir, lalu selesai.

PostgreSQL 14 pertama terbit 30 September 2021. Rilis terakhirnya dijadwalkan 12 November 2026, dan setelah tanggal itu tidak ada lagi perbaikan bug maupun patch keamanan. Versi 13 sudah lebih dulu tidak didukung, jadi 14 adalah versi tertua yang masih hidup — dan hidupnya tinggal hitungan hari.

Kalau ada database PostgreSQL 14 di VPS yang menjalankan aplikasi produksi, ini waktunya bergerak. Bukan karena 14 meledak pada 13 November, tapi karena patch keamanan berikutnya tidak akan datang lagi.

Yang berubah saat benar-benar naik ke 19

Untuk yang berencana lompat ke PostgreSQL 19 setelah rilis, beberapa perubahan bawaan di catatan rilis resmi perlu dibaca sebelum pg_upgrade:

JIT sekarang mati secara default. Sebelumnya JIT menyala sendiri berdasarkan perkiraan biaya optimizer, dan perkiraan itu dinilai tidak bisa diandalkan. Query analitik besar yang dulu memanfaatkan JIT perlu menyalakannya manual.
Kompresi TOAST default pindah dari pglz ke lz4, jadi kolom teks dan JSON besar dipadatkan dan dibuka lebih cepat. Tapi lz4 harus tersedia di sistem operasi.
Dukungan autentikasi RADIUS dihapus karena hanya bisa lewat UDP dan dinilai tidak bisa diperbaiki. Satu baris radius yang tersisa di pg_hba.conf bisa membuat server menolak start.
standard_conforming_strings dipaksa selalu on. Dump lama yang dibuat pg_dump versi pra-19 dengan setelan off tidak akan termuat dengan benar, jadi dump ulang memakai pg_dump dari 19.
Indeks btree_gist pada kolom inet dan cidr menghalangi upgrade. Operator class itu ternyata bisa menyembunyikan baris yang seharusnya muncul; default-nya sekarang GiST biasa, dan pg_upgrade akan berhenti kalau menemukan indeks lama seperti itu.
max_locks_per_transaction naik dari 64 ke 128, karena alokasi lock berubah. Kalau nilainya pernah dinaikkan manual, angkanya perlu disesuaikan agar kapasitasnya setara.
Encoding MULE_INTERNAL dihapus, dan nama database, role, atau tablespace tidak lagi boleh mengandung carriage return atau line feed.

Tidak ada satu pun dari daftar itu yang menakutkan kalau dibaca sebelum upgrade. Yang menakutkan adalah menemukannya saat upgrade sudah setengah jalan, pukul dua pagi, sementara aplikasi sedang ramai. wkwkwk.

Jadi, tunggu atau pindah sekarang?

Pendapat saya: dua-duanya, tapi dengan urutan yang jelas.

Untuk siapa pun yang masih di PostgreSQL 14, urusannya bukan menunggu 19 — urusannya keluar dari 14 sebelum 12 November. Naik ke 18 (atau 17 kalau ada ekstensi yang belum siap) memberi lima tahun dukungan lagi, cukup untuk bernapas. Melompat dari 14 langsung ke 19 bisa, tapi melewati versi yang sedang dirapikan minggu ini rasanya kurang perlu.

Untuk yang sudah di 18, PostgreSQL 19 layak dipasang setelah versi 19.1 keluar. Fitur seperti REPACK (CONCURRENTLY) dan pg_plan_advice memang menggoda, tapi tidak ada ruginya memberi rilis baru satu siklus pembaruan untuk membuktikan diri — persis seperti yang dilakukan komunitasnya sendiri bulan ini.

Dan kalau nanti sudah pasang, baca bagian Migration to Version 19 di catatan rilisnya — semua jebakan di atas ditulis di sana dengan tenang, jauh sebelum ia jadi masalah.

Yang paling saya bawa dari kabar bulan ini bukan tanggal 19 November-nya, melainkan keputusan untuk membuang fitur yang belum siap. Di dunia yang sering menilai kemajuan dari panjangnya daftar fitur, memilih “belum sekarang” adalah bentuk keberanian yang langka.

Assalamu’alaikum warrohmatullahi wabarookaatuh..