Yang Baru di Postgres 19: Analisis Mendalam Rilis Beta

 (snowflake.com)
1 poin oleh GN⁺ 3 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Rilis beta ini menghadirkan REPACK CONCURRENTLY bawaan di core untuk database produksi skala besar, serta berbagai peningkatan luas di area kueri graf properti SQL, replikasi logis, VACUUM, performa, dan lainnya
  • Dukungan penggabungan·pemecahan partisi dan sinkronisasi nilai sequence membuat perubahan desain dan perpindahan data saat sistem berjalan menjadi jauh lebih mudah
  • Autovacuum kini memperkenalkan worker paralel dan sistem skor prioritas, sehingga throughput serta visibilitas pekerjaan pemeliharaan meningkat
  • Dengan hadirnya SQL/PGQ, data yang sudah ada bisa dikueri dalam bentuk graf tanpa harus meninggalkan model relasional
  • Bukan satu fitur headline semata, inti rilisan ini adalah keluasan (breadth), dengan kemajuan serentak di aplikasi, operasi, performa, dan skalabilitas

REPACK bawaan inti

  • Dalam lingkungan operasi jangka panjang, kebutuhan untuk merebut kembali bloat tabel, menulis ulang tabel, atau menata ulang data tanpa lock yang menyertai VACUUM FULL atau CLUSTER terus berulang
    • Sudah ada ekosistem ekstensi yang menangani masalah ini, dan pg_repack adalah salah satu contoh utama yang mengisi celah tersebut
  • Postgres 19 memasukkan perintah REPACK ke core, termasuk dukungan REPACK CONCURRENTLY
    • Fitur ini kemungkinan akan lebih menarik bagi pengguna produksi daripada yang diperkirakan pembaca catatan rilis pada umumnya

Kegunaan partisi makin kuat

  • Postgres 19 menambahkan dukungan penggabungan·pemecahan partisi
  • Strategi partisi sering dipilih berdasarkan informasi yang belum lengkap, dan ketika workload, periode retensi, atau laju pertumbuhan data berubah, sebagian partisi bisa menjadi terlalu besar atau justru terlalu kecil
  • Dengan kemampuan split dan merge, desain bisa berevolusi seiring waktu tanpa harus membangun ulang semuanya dari awal
    • Menggabungkan partisi Q1·Q2 menjadi satu partisi tunggal: ALTER TABLE customer_orders MERGE PARTITIONS (orders_2026_q1, orders_2026_q2) INTO orders_2026_h1;
    • Juga disediakan contoh SPLIT PARTITION untuk memecah partisi Q3 menjadi unit bulanan

Kematangan replikasi logis

  • Replikasi logis berguna untuk migrasi, upgrade, sistem pelaporan, perpindahan data, replikasi selektif, serta workflow high availability dan operasi
  • Peningkatan terbesar adalah sinkronisasi nilai sequence, sehingga subscriber lebih selaras dengan publisher
    • Jika replikasi dilakukan tanpa state sequence, data memang berpindah tetapi ID berikutnya bisa meleset setelah cutover
    • Dukungan ALL SEQUENCES pada publication, pelaporan error sinkronisasi sequence, dan perbaikan perilaku refresh subscription terkait sequence ikut ditambahkan
  • Kini bisa menggunakan klausa EXCEPT untuk memublikasikan semua tabel kecuali sebagian tertentu
  • Jika diperlukan, wal_level = replica akan secara otomatis mengaktifkan replikasi logis, dan penambahan effective_wal_level yang melaporkan perilaku aktual mengurangi kesalahan konfigurasi serta meningkatkan visibilitas

Autovacuum yang lebih cerdas dan lebih terlihat

  • Autovacuum kini bisa memakai worker vacuum paralel, dengan kontrol di tingkat global maupun per tabel
    • Contoh pengaturan global: ALTER SYSTEM SET autovacuum_max_parallel_workers = 4;
  • Diperkenalkan sistem skor baru untuk mengatur urutan tabel yang divacuum, sehingga lebih mudah menentukan tabel mana yang paling mendesak
    • Contoh penyesuaian bobot per tabel: urgensi vacuum berbasis insert 3.0, urgensi vacuum update/delete umum 0.5
  • View pg_stat_autovacuum_scores yang baru memberikan visibilitas ke proses pengambilan keputusan
    • Detail tambahan pada view progres vacuum·analyze, penggunaan memori dan paralelisme pada VACUUM VERBOSE serta log autovacuum, dan penambahan log_autoanalyze_min_duration memperkuat observabilitas pemeliharaan

Hadirnya kueri graf properti SQL

  • Ditambahkan SQL/PGQ (SQL property graph queries)
    • Workload yang cocok untuk model vertex·edge mencakup deteksi fraud, rekomendasi, analisis jaringan, graf izin, rantai pasok, bagan organisasi, dan lain-lain
    • Contoh definisi graf properti: CREATE PROPERTY GRAPH store_graph dengan penentuan VERTEX TABLES dan EDGE TABLES
  • Pendekatannya bukan meninggalkan model relasional, melainkan menambahkan cara lain untuk mengueri data yang sudah dimiliki
    • Ini sejalan dengan bagaimana JSONB, full-text search, dan ekstensi sebelumnya tidak memaksa perubahan arsitektur yang sudah ada
  • Dari sudut pandang developer, kueri graf bisa digunakan tanpa menambah datastore terpisah, jalur sinkronisasi, permukaan operasi, atau target debugging pukul 2 pagi

COPY yang makin berguna

  • COPY FROM kini mendukung melewati beberapa baris header
    • Berguna untuk memproses CSV dari vendor, alat internal, atau ekspor yang memiliki baris metadata tambahan di bagian atas
  • COPY FROM mendapat ON_ERROR SET_NULL, yang mengubah input tidak valid menjadi null, memberi opsi di antara “seluruh load gagal” dan “harus dibersihkan dulu”
    • Disediakan contoh memuat file dengan nilai seperti 'N/A'·'MISSING' yang tercampur di kolom price
  • COPY TO kini dapat menghasilkan output JSON, termasuk satu array JSON tunggal, dan juga bisa langsung mengekspor tabel partisi (sebelumnya perlu COPY (SELECT ...))
    • Contoh mengekspor tabel sebagai array JSON yang valid: WITH (FORMAT JSON, ARRAY true)

Peningkatan kenyamanan SQL

  • Dengan GROUP BY ALL, ekspresi pada daftar target non-agregat dan non-window akan dikelompokkan otomatis, membuat SQL eksploratif dan kueri pelaporan lebih rapi
  • Dukungan IGNORE NULLS·RESPECT NULLS pada fungsi window ditambahkan ke lead, lag, first_value, last_value, dan nth_value
  • Penambahan INSERT ... ON CONFLICT DO SELECT ... RETURNING memungkinkan pengembalian baris konflik secara lebih langsung saat upsert
  • Penambahan UPDATE·DELETE FOR PORTION OF melanjutkan dukungan untuk operasi terkait waktu (temporal), termasuk fungsi waktu RANDOM() yang diperluas

Peningkatan performa di berbagai sisi

  • Banyak perbaikan hadir pada planner dan executor, termasuk anti-join, semi-join, constant folding, incremental sort pada append path, agregasi sebelum join, perhitungan selektivitas join, statistik fungsi, dan lainnya
  • Postgres berkembang ke arah yang lebih baik dalam mengenali bentuk kueri umum dan mengurangi pekerjaan yang tidak perlu
    • Sebagian pemrosesan agregasi kini dilakukan sebelum join untuk mengurangi jumlah baris yang diproses
    • Lebih banyak kasus NOT IN·LEFT JOIN dapat diubah menjadi anti-join yang efisien
    • Visibilitas EXPLAIN untuk Memoize ditingkatkan, performa pengurutan membaik lewat radix sort, pemeriksaan constraint foreign key menjadi lebih cepat, dan SIMD dipakai untuk input teks·CSV pada COPY FROM
  • Dalam banyak kasus, upgrade saja sudah bisa memberi hasil yang lebih baik tanpa perlu mengubah kode aplikasi

Mengapa Postgres 19 penting

  • Yang menonjol bukan satu fitur tunggal, melainkan keluasan (breadth)
    • Untuk developer aplikasi: kueri graf, sintaks SQL yang ditingkatkan, perbaikan fungsi window, dan perilaku upsert yang lebih baik
    • Untuk operator: REPACK CONCURRENTLY, autovacuum yang ditingkatkan, monitoring yang lebih baik, perubahan checksum online, dan visibilitas replikasi yang lebih luas
    • Untuk pengguna yang fokus pada performa: peningkatan planner, peningkatan SIMD, visibilitas I/O asinkron, pemeriksaan foreign key yang lebih cepat, dan pengurutan yang lebih baik
    • Untuk pengguna yang membangun di atas Postgres: hook baru, modul planner advice, peningkatan ekstensi, pengambilan statistik FDW, dan investasi berkelanjutan pada ekosistem ekstensi
  • Bukan hanya berkembang untuk satu workload atau persona, tetapi sekaligus sebagai database dan platform untuk aplikasi, operasi, analitik, dan ekstensi
  • Ini masih belum GA, jadi sekarang adalah saat yang tepat untuk menguji — jalankan aplikasi, uji migrasi, periksa ekstensi, cek rencana kueri penting, serta tinjau workflow replikasi logis dan pemeliharaan

Bacaan terkait

1 komentar

 
GN⁺ 3 jam lalu
Komentar Hacker News

  • Saya pernah memakai Postgres, Oracle, MS SQL Server, dan MySQL dalam proyek nyata, dan meski belum memakai SQLite secara mendalam, saya tahu itu pilihan yang bagus
    Belakangan ini, untuk diri saya sendiri, saya selalu menghindari Oracle dan MySQL/MariaDB
    Postgres itu hebat, tetapi saya berharap ada koneksi yang ringan dan materialized view yang diperbarui secara sinkron. Connection pooler memang memperbaiki keadaan, tetapi penggunaan memori per koneksi serentak masih sangat tidak wajar besar, dan fitur seperti indexed view di SQL Server memungkinkan implementasi yang elegan, sepele, dan selalu benar dalam situasi data yang kompleks
    SQL Server bisa mahal, tetapi dalam banyak kasus sepadan dengan biayanya, dan memilih penyimpanan data dengan cermat dapat mengurangi banyak sakit kepala di masa depan

    • Untuk masalah penyimpanan relasional, saya terutama memakai SQLite dan MSSQL
      Kalau akan memakai penyedia gratis, sulit mengalahkan SQLite, dan saat ini ia menangani sebagian besar use case. Namun, untuk backup, replikasi, dan tooling, ia mulai kewalahan. Jika saya bertanggung jawab atas ketersediaan sistem dan disaster recovery, saya tidak keberatan mengeluarkan uang untuk mengurangi risiko
      Kalau akan membayar meski sedikit, saya akan sekalian total. Developer experience di sekitar MSSQL tidak ada tandingannya, dan menurut saya SQL Project di SSMS dan Visual Studio jauh lebih baik daripada hal-hal sejenis Entity Framework saat ini. Ditambah tool pihak ketiga seperti RedGate, itu bisa menggantikan paket konsultasi bernilai jutaan dolar
      Saya tidak akan mengusulkan membuat server Oracle atau DB2 baru, tetapi kalau sudah ada, saya mungkin akan menentang habis-habisan upaya refactoring untuk menghapusnya. Database seperti ini biasanya disertai segunung cerita horor, dan bila tidak ada pilihan lain selain mereproduksi efek samping aneh itu di engine baru, bisnisnya sendiri bisa rusak
    • Oracle adalah kombinasi rasa sakit, penderitaan, biaya tinggi, gugatan hukum, dan kesengsaraan manusia. Kalau bukan karena manajer menengah nonteknis yang suka mendapat fasilitas seperti pesta mewah saat membeli software mahal, rasanya Oracle sudah bangkrut
    • Bahkan Microsoft pun tampaknya pada dasarnya sudah menyerah pada SQL Server dan lebih banyak menghabiskan waktu memperbaiki berbagai produk Postgres di Azure. Versi mayor terakhir setelah 2022 kurang lebih hanya menambahkan beberapa fitur AI
      Sebagai DBA, kalau Anda banyak melakukan pekerjaan DBA yang berat, Postgres berada di kelas berbeda dari SQL Server. Postgres native di Linux dan open source, sehingga fleksibilitas, observabilitas internal, dan operabilitasnya tidak bisa dibandingkan dengan SQL Server
      Dalam lanskap teknologi saat ini, menurut saya SQL Server praktis sudah mati. Perusahaan yang memakainya hanya organisasi legacy yang berpusat pada Windows, dan jumlahnya pun makin berkurang
    • Saya benar-benar berharap ada materialized view dengan pembaruan sinkron. Dalam istilah Oracle, sepertinya yang dimaksud adalah semacam “refresh on commit”
      Akan bagus juga jika ada opsi pembaruan tertunda. Caranya memproses banyak update sekaligus dengan hanya mempertimbangkan record yang berubah sejak refresh terakhir, meski saya tidak begitu tahu bagaimana Oracle melakukannya secara teknis. Fitur ini rasanya akan menjadi tambahan fantastis dibanding hampir semua database OLTP open source
      Saya juga sangat penasaran dengan proyek OrioleDB: https://github.com/orioledb/orioledb/releases
      Beberapa tahun lalu saya cukup menderita karena vacuum, akibat banyak insert dan delete acak terus-menerus di tempat yang mirip tabel temporer. Saya mengatasinya dengan mengumpulkan lebih banyak perubahan di RAM lalu melakukan flush ke tabel agar jumlah baris yang berubah per halaman meningkat, tetapi mencari keseimbangan yang tepat sangat menyulitkan
    • PostgreSQL memang produk yang lebih baik, tetapi tidak memiliki skalabilitas horizontal MySQL/MariaDB. Jadi jika butuh cluster yang mudah dikonfigurasi dan kasus seperti toko ritel online berskala besar, MySQL masih berguna

  • Sebagai orang yang sudah memakai Postgres di bidang sains selama lebih dari 15 tahun, saya mulai khawatir karena PostgreSQL tidak memiliki penyimpanan berorientasi kolom
    Seiring dataset makin besar, batasan storage PG makin terasa. Berbagai extension seperti cetus bisa menyediakan fitur itu, tetapi berarti kita bergantung pada apakah extension tersebut tetap didukung ke depannya, dan kompleksitasnya juga bertambah

    • Ini agak promosi tanpa malu-malu, tetapi selama beberapa bulan saya mengerjakan masalah ini dalam bentuk extension: https://github.com/xataio/deltax
      Awalnya saya mengira jika memakai tabel Postgres sebagai storage dan memakai executor Postgres, overhead bawaannya akan terlalu besar, jadi kalau bisa menyamai performa Timescale saja sudah cukup keren. Saya tidak menyangka bisa mendekati database analitik khusus
      Namun seiring proyek berjalan, performanya terus membaik, dan sekarang saya jelas mendukung pendekatan melakukan pekerjaan analitik dengan Postgres + extension
    • Jika itu yang Anda harapkan, mungkin Anda memilih database yang salah. Database berorientasi kolom adalah kategori tersendiri
      Ini mirip khawatir karena Apple tidak menjual mesin cuci
    • Dari sudut pandang ilmu komputer, saya tidak begitu tahu bagaimana database transaksional akan mengimplementasikan format kolumnar. Jika skalanya membesar, kombinasi seperti Postgres + CDC + ClickHouse dengan database analitik sungguhan tampaknya menjadi pilihan paling kuat
    • Jika dataset makin membesar, sepertinya lebih baik menyimpan data baru di PostgreSQL dan secara berkala mengarsipkan data lama ke database bergaya data warehouse agar Postgres tetap kecil
      Saat ini banyak perusahaan juga memakai database key-value atau document store bersama database relasional di aplikasi utama mereka
    • Sebagai pengguna selama 25 tahun, menurut saya kondisi saat ini juga baik-baik saja. Lebih banyak tidak selalu berarti lebih baik; lihat saja Redis

  • Saya tidak tahu mengapa tidak ada pembahasan bahwa PostgreSQL 19 memperkenalkan dukungan native application-time temporal data berbasis standar SQL:2011: https://www.depesz.com/2026/04/02/waiting-for-postgresql-19-...

    • Mengejutkan bahwa artikel aslinya tidak menyebut ini. Dulu ini diimplementasikan dengan menambahkan trigger tcn dan tabel bayangan _archive secara manual: https://www.postgresql.org/docs/current/tcn.html
      Kalau ini menjadi native, sepertinya akan benar-benar bagus, seperti kebanyakan implementasi PostgreSQL
    • Query Hints juga hanya disinggung sekilas, cukup disayangkan. Ada diskusi menarik di bawah artikel sebelumnya dengan judul serupa
      https://news.ycombinator.com/item?id=48413655
    • Fitur yang keren, tapi sejujurnya menurut saya agak sulit dipakai dengan baik. Dan kita harus berhati-hati agar PII tidak tertinggal lama di suatu tempat dalam temporal void

  • Saya tidak bisa memastikan apakah artikel ini memakai gaya bahasa yang terlalu banyak tersampling dalam data pelatihan LLM, atau apakah penulis banyak memakai AI untuk memoles tulisannya. Saya condong ke yang kedua

    • Menyebutnya “dipoles” terlalu murah hati. Yang lebih mengganggu adalah informasi penulisnya menyesatkan. craig-kerstiens tidak bisa ditemukan di Hugging Face, dan tidak ada satu pun kalimat dalam artikel ini yang terlihat seperti diketik langsung dengan keyboard
      Menurut saya, ketika Claude menulis kalimat seperti “sebagai seseorang yang sudah lama berkecimpung di X”, itu semacam kegagalan alignment. LLM tidak seharusnya menulis seolah-olah punya pengalaman pribadi. Bisa saja dalam data pelatihan ada manusia yang berbicara seperti itu, tetapi meskipun secara statistik itu rangkaian token yang masuk akal, menurut saya LLM tidak boleh mengklaim pengalaman hidup yang tidak dimilikinya
    • Tidak perlu terlalu murah hati. Snowflake memecat para technical writer dengan alasan akan menggantinya dengan AI: https://snowflake.help/snowflake-layoffs-2026-technical-writ...
    • Komentar semacam ini yang menyerang gaya dan format dengan usaha rendah bertentangan dengan pedoman diskusi Hacker News, dan perlu ada tindakan untuk merapikan kolom komentar. Ini sudah sampai taraf konyol
    • Pangram menilai seluruh teks ini dihasilkan AI, tapi saya tidak tahu seberapa bisa dipercaya Pangram. Saya juga ingin mendengar pendapat orang lain
    • Saya paham bahwa menebak apakah AI dipakai sedang jadi tren. Namun kalau ada yang perlu dikritik, menurut saya lebih berguna mengkritik hasil akhirnya

  • Saya suka perbaikan COPY dan replikasi logis. Saat ini saya mencadangkan database PG ke instance sidecar Databasus, dan itu lebih berat daripada seluruh backend + DB + Caddy
    Berikut ini keluhan tentang gaya bahasa LLM
    Daripada membaca kalimat seperti “Itu saja sudah memberi tahu kita: pengguna punya kebutuhan nyata, dan ekosistem mengisi celah itu”, “Terlihat sederhana, tetapi menyelesaikan masalah operasional nyata”, dan “Ini tidak mengubah dunia, tetapi membuat workflow data harian menjadi lebih baik”, kalau Orwell masih hidup sekarang mungkin ia sudah menyatakan dirinya buta huruf bahasa Inggris dan belajar Klingon

  • Fitur graph database terlihat menarik, tetapi sintaks GRAPH_TABLE terlalu mengerikan
    SELECT customer_name FROM GRAPH_TABLE (myshop MATCH (c IS customers)-[IS customer_orders]->(o IS orders WHERE o.ordered_when = current_date) COLUMNS (c.name AS customer_name));
    Ini mengingatkan pada neo4j, yang menurut saya bukan sesuatu yang pantas disalin mentah-mentah oleh tool serius pada 2026
    Pada akhirnya yang membuat penasaran adalah kecepatannya. Keamanan tingkat baris adalah fitur yang sangat berguna, tetapi mencoba membangun sesuatu yang serius dengan implementasi Postgres itu nekat. Karena planner menjadi kacau dan mencocokkan per baris sehingga menghancurkan performa

    • Itu bukan sintaks arbitrer yang dibuat sendiri oleh Postgres
      Itu adalah SQL/PGQ, yang diturunkan dari bahasa Cypher milik Neo4J dan sekarang menjadi bagian dari standar SQL
    • Katanya planner memeriksa per baris pada keamanan tingkat baris? Ya memang itulah Row-level security. Bagaimana lagi memverifikasi apakah sebuah baris lolos kebijakan?

  • Saya berharap PostgreSQL tidak hanya mendapat kompresi baris, tetapi juga kompresi blok. Kompresi baris saja efeknya terlalu terbatas
    Memang bisa menaruh data di pool ZFS dan mengaktifkan kompresi blok, tetapi dukungan native akan mengurangi beban konfigurasi dan mungkin memberikan performa lebih baik

  • GROUP BY ALL benar-benar masuk akal kalau dipikirkan, jadi menarik karena sebelumnya saya sama sekali tidak pernah terpikirkan

  • Dari sudut pandang yang lebih dekat ke DevOps, saya berharap PostgreSQL akhirnya mendukung upgrade in-place di antara versi mayor yang berurutan
    Sebagian besar distro bisa menangani kerepotan menjalankan versi lama dan baru bersamaan untuk pg_upgrade, tetapi kalau memakai Docker, upgrade ke versi mayor baru benar-benar menyakitkan

  • Senang GROUP BY ALL diperkenalkan. Sejauh yang saya tahu, ini konsep yang diperkenalkan oleh DuckDB
    Dokumentasi DuckDB juga menyebutkan bahwa beberapa fitur pertama kali diperkenalkan di DuckDB, dan fitur seperti GROUP BY ALL kemudian diadopsi oleh sistem lain
    https://duckdb.org/docs/lts/sql/dialect/friendly_sql