PostgreSQL 19 Beta 4: Fitur yang Di-revert dan Cara Mengujinya di Staging

PostgreSQL Global Development Group merilis PostgreSQL 19 Beta 4 pada 24 September 2026. Ini adalah beta keempat untuk versi 19, dan seperti beta sebelumnya, isinya masih berupa pratinjau fitur menjelang ketersediaan umum. Yang membuat beta ini menarik bukan sekadar tambahan fitur baru, melainkan keputusan untuk menarik beberapa fitur yang tadinya direncanakan. Bagi tim yang sedang menyiapkan upgrade, perubahan arah seperti ini penting dicatat.

Menurut pengumuman resmi, rilis PostgreSQL 19 berikutnya yang direncanakan adalah release candidate, yang seharusnya muncul pada awal Oktober. Berdasarkan pengujian dan evaluasi, ketersediaan umum PostgreSQL 19 juga berpotensi terjadi pada Oktober. Artinya, jendela waktu untuk menguji beta ini di staging tidak lama lagi. Kalau kamu berencana naik versi, sekarang adalah saat yang tepat untuk mulai menguji beban kerja nyata terhadap beta terbaru.

Fitur yang Di-revert di Beta 4

Bagian paling penting dari catatan rilis beta ini adalah daftar fitur yang ditarik kembali. PostgreSQL 19 Beta 4 mengembalikan beberapa fitur yang sebelumnya direncanakan untuk versi 19:

• Dukungan SQL/PGQ untuk property graph query ditarik kembali.
• Pengaktifan dan penonaktifan data checksums secara online ditarik kembali.
• Dukungan untuk temporal updates dan deletes lewat klausa FOR PORTION OF ditarik kembali.
• Perintah ALTER TABLE MERGE PARTITIONS dan ALTER TABLE SPLIT PARTITIONS ditarik kembali.

Selain itu, tiga fungsi dihapus: pg_get_role_ddl(), pg_get_tablespace_ddl(), dan pg_get_database_ddl(). Ada juga perubahan yang ditarik kembali terkait pemaksaan LC_COLLATE ke nilai C pada proses postmaster.

Kenapa fitur ditarik? Alasannya tertulis jelas dalam pengumuman: komunitas PostgreSQL sangat percaya bahwa PostgreSQL harus mengutamakan keandalan, dan komunitas berusaha menjaga jadwal rilis yang dapat diprediksi. Karena dua prinsip itu, sebagian fitur dikeluarkan dari rilis 19 agar bisa dipertimbangkan lagi di rilis mayor berikutnya setelah melewati proses pengembangan dan review komunitas yang lebih matang.

Bagi tim yang sudah menyusun rencana migrasi berdasarkan daftar fitur di beta awal, daftar revert ini adalah sinyal untuk meninjau ulang asumsi. Fitur yang tadinya jadi alasan utama upgrade mungkin tidak lagi tersedia di versi 19. Lebih baik mengetahuinya sekarang daripada setelah produksi naik versi.

Perbaikan Sejak Beta 3

Beta 4 juga membawa sejumlah perbaikan dan perubahan sejak beta ketiga. Beberapa yang patut diperhatikan:

• Beberapa perbaikan pada fitur peningkatan performa untuk pemeriksaan foreign key constraint.
• Beberapa perbaikan pada perintah baru REPACK, termasuk crash, perilaku yang salah dengan indeks tidak valid dan materialized view, serta koreksi izin dan pelaporan error.
• Beberapa perbaikan pada perintah baru WAIT FOR, termasuk sebuah deadlock dan pelaporan error tingkat isolasi yang lebih jelas.
• Perbaikan validasi daftar FOREIGN_JOIN yang kosong di pg_plan_advice.
• Beberapa perbaikan untuk CREATE PUBLICATION dengan klausa EXCEPT.
• Perbaikan sinkronisasi awal tabel pada logical replication saat mereplikasi dari versi PostgreSQL lama ke versi 19.
• Beberapa perbaikan pada deteksi konflik logical replication.
• Beberapa perbaikan pada sistem skor autovacuum yang baru, termasuk untuk tabel TOAST.
• Perbaikan untuk optimasi SIMD pada COPY FROM.
• Perbaikan crash saat mengakses partisi yang proses detach bersamanya belum selesai.
• Klarifikasi bahwa transaksi gagal dilaporkan terpisah saat memakai pgbench dengan opsi --continue-on-error.

Pola yang terlihat dari daftar ini: perintah dan fitur baru seperti REPACK, WAIT FOR, dan sistem skor autovacuum sedang aktif diperbaiki. Ini normal untuk fitur yang baru masuk. Kalau kamu berencana mengandalkan salah satunya, uji dengan beban kerja yang mirip produksi, bukan hanya dengan data contoh kecil.

Menguji Beta di Staging

PostgreSQL secara eksplisit mengingatkan bahwa karena ini beta, perubahan minor pada perilaku database, detail fitur, dan API masih mungkin terjadi. Karena itu, pengujian harus dilakukan di lingkungan terpisah, bukan di produksi.

Untuk memindahkan data ke beta 4 dari versi sebelumnya, kamu perlu strategi yang mirip dengan upgrade antar versi mayor. Dua jalur yang didukung adalah pg_upgrade untuk upgrade di tempat dengan downtime minimal, atau pg_dump dan pg_restore untuk pendekatan yang lebih portabel dan aman untuk pengujian. Untuk staging, pendekatan dump dan restore biasanya lebih disukai karena tidak menyentuh instalasi yang ada dan mudah diulang.

Urutan pengujian yang masuk akal:

1. Siapkan instance PostgreSQL 19 Beta 4 terpisah, jangan menimpa instalasi yang sedang melayani produksi.
2. Salin data representatif. Idealnya ukuran dan distribusinya mirip produksi, karena banyak masalah performa hanya muncul pada skala nyata.
3. Jalankan kumpulan tes regresi kamu terhadap instance beta. Fokus pada query yang paling penting, bukan hanya yang paling sering dijalankan.
4. Uji ulang fitur yang kamu andalkan, terutama yang berkaitan dengan partisi, logical replication, autovacuum, dan constraint.
5. Ukur performa pada query kritis dan bandingkan dengan versi saat ini. Catat setiap perbedaan yang tidak terduga.
6. Periksa ekstensi pihak ketiga yang kamu pakai. Ekstensi yang belum diperbarui untuk versi 19 bisa menjadi penghambat utama.
7. Dokumentasikan temuan, termasuk kasus yang gagal, karena laporan itulah yang membantu komunitas menentukan kapan versi final siap.

Karena jadwal menuju release candidate sudah dekat, hasil pengujian yang dilaporkan lebih awal punya peluang lebih besar untuk memengaruhi rilis final. Masalah yang ditemukan pada tahap ini masih bisa diperbaiki sebelum ketersediaan umum.

Hal yang Sering Terlewat Saat Uji Beta

Banyak tim hanya menguji jalur bahagia, yaitu query yang memang mereka harapkan berhasil. Padahal justru kasus tepi yang paling sering menemukan bug di beta. Cobalah memasukkan data yang tidak rapi, menjalankan operasi bersamaan yang saling bertabrakan, dan menguji perilaku saat koneksi terputus di tengah transaksi. Fitur seperti logical replication dan autovacuum baru terlihat karakternya ketika dijalankan dalam waktu lama, bukan dalam sekali tes.

Hal lain yang mudah terlewat adalah memeriksa dampak terhadap alat operasional. Skrip backup, alat monitoring, dan prosedur pemulihan bencana semuanya perlu diuji ulang terhadap versi baru. Kadang masalahnya bukan di database itu sendiri, melainkan di skrip yang mengandalkan format keluaran tertentu yang berubah.

Terakhir, perhatikan kebutuhan kolasi dan pengurutan. Perubahan terkait LC_COLLATE yang ditarik di beta ini menunjukkan bahwa area tersebut sensitif. Kalau aplikasi kamu bergantung pada urutan string tertentu, uji ulang hasil pengurutan setelah naik versi, karena perbedaan kecil di sini bisa mengubah hasil query dan laporan.

Melaporkan Bug

Komunitas menyediakan kanal yang jelas untuk melaporkan temuan. Daftar masalah terbuka tersedia publik di wiki PostgreSQL, dan bug bisa dilaporkan lewat formulir di situs resmi. Untuk pengujian beta, laporan yang berguna biasanya memuat langkah reproduksi yang minimal, versi persis yang dipakai, dan hasil yang diharapkan dibanding hasil yang terjadi.

Stabilitas setiap rilis PostgreSQL sangat bergantung pada komunitas yang menguji versi mendatang dengan beban kerja dan alat pengujian mereka sendiri. Semakin banyak skenario nyata yang diuji sebelum ketersediaan umum, semakin kecil kemungkinan regresi lolos ke produksi. Bagi tim yang serius dengan PostgreSQL, berpartisipasi di fase beta adalah cara murah untuk ikut menentukan kualitas versi yang nantinya mereka pakai sendiri.

Menyusun Strategi Upgrade Sejak Sekarang

Beta adalah waktu yang tepat untuk menyusun rencana, bukan mengeksekusi di produksi. Ada beberapa keputusan yang lebih baik diambil sekarang. Pertama, tentukan target waktu upgrade relatif terhadap ketersediaan umum. Kalau aplikasi kamu sensitif terhadap stabilitas, menunggu rilis minor pertama setelah versi 19 umum dirilis adalah pilihan yang wajar. Kalau kamu ingin memanfaatkan fitur baru lebih cepat, siapkan rencana rollback yang matang.

Kedua, petakan dependensi. Daftar ekstensi, driver, dan alat orkestrasi yang kamu pakai perlu dicocokkan dengan dukungan versi 19. Sering kali penghambat upgrade bukan PostgreSQL-nya, melainkan ekstensi atau library yang belum merilis versi kompatibel. Menemukan ini lebih awal memberi waktu untuk mencari alternatif atau menunda upgrade untuk komponen tertentu.

Ketiga, siapkan lingkungan pengujian yang bisa diulang. Kalau pengujian hanya dilakukan sekali secara manual, temuan sulit direproduksi dan sulit diverifikasi ulang setelah perbaikan. Skrip yang membangun instance beta, memuat data, dan menjalankan rangkaian tes secara otomatis membuat proses ini jauh lebih dapat diandalkan, terutama karena ada kemungkinan beberapa beta lanjutan dirilis sebelum versi final.

Kenapa Keputusan Revert Justru Menguntungkan

Sekilas, menarik fitur terdengar seperti kemunduran. Namun ada alasan kuat di baliknya. Fitur yang ditarik dari rilis 19 tetap bisa masuk di rilis mayor berikutnya setelah proses pengembangan dan review yang lebih matang. Dengan kata lain, fitur itu tidak hilang, hanya ditunda sampai kualitasnya memadai.

Bagi pengguna jangka panjang, ini berarti basis kode yang lebih stabil. Database yang sering menambahkan fitur mentah cenderung menumpuk utang teknis yang kemudian membebani operasional. Pendekatan yang menahan fitur sampai benar-benar siap mengurangi risiko regresi yang harus kamu tangani sendiri di produksi. Biaya jangka pendeknya adalah penundaan, tetapi manfaatnya adalah rilis yang lebih dapat diprediksi.

Konsekuensi praktisnya, jangan menyusun rencana migrasi dengan asumsi fitur beta pasti tersedia di versi final. Periksa kembali daftar revert di setiap beta. Kalau fitur yang kamu butuhkan ada di daftar itu, siapkan rencana alternatif atau tunda kebutuhan tersebut sampai rilis mayor berikutnya.

Checklist Kompatibilitas Aplikasi

Selain menguji database itu sendiri, aplikasi yang memakainya perlu diperiksa. Beberapa hal yang layak masuk checklist:

• Perilaku pengurutan dan perbandingan string, terutama kalau ada logika yang bergantung pada urutan tertentu.
• Format keluaran perintah yang dibaca oleh skrip otomasi, misalnya keluaran pg_dump atau alat monitoring.
• Perilaku transaksi dan pelaporan error, khususnya di sekitar tingkat isolasi dan deadlock.
• Query yang bergantung pada planner. Perubahan estimasi atau strategi eksekusi bisa mengubah performa secara signifikan tanpa mengubah hasil.
• Alur logical replication, kalau kamu memakainya untuk sinkronisasi antar-sistem.

Menguji hal-hal ini di staging memakan waktu, tetapi jauh lebih murah daripada menemukannya setelah upgrade produksi. Catat setiap perbedaan perilaku sebagai temuan, meskipun tampak sepele, karena akumulasi perbedaan kecil adalah sumber masalah yang paling sulit dilacak.

Terakhir, jangan lupa mengukur, bukan hanya mengamati. Perbedaan performa sering tidak terasa secara subjektif. Mencatat waktu eksekusi query kritis sebelum dan sesudah memberi bukti yang bisa dipertanggungjawabkan saat mengambil keputusan naik versi.

Kesimpulan

PostgreSQL 19 Beta 4 bukan sekadar tambahan fitur, melainkan pengingat bahwa proyek ini menempatkan keandalan di atas kecepatan rilis. Keputusan menarik beberapa fitur demi kualitas adalah tanda sehat, meskipun bagi tim yang sudah menyusun rencana berbasis beta awal, ini berarti daftar fitur perlu ditinjau ulang. Karena release candidate dijadwalkan awal Oktober dan ketersediaan umum berpotensi menyusul, jendela pengujian terbuka lebar tetapi tidak lama.

Langkah paling praktis: siapkan instance beta terpisah, salin data yang representatif, jalankan tes regresi dan beban kerja kritis, lalu laporkan temuan selagi masih bisa memengaruhi rilis final. Dokumentasi lengkap fitur dan perubahan bisa dibaca di release notes PostgreSQL 19, sementara informasi proses pengujian beta tersedia di halaman beta resmi proyek.