PostgreSQL 18: Fitur Baru yang Perlu Diketahui

PostgreSQL 18 mengubah cara database membaca data dari disk lewat asynchronous I/O, sekaligus menambah beberapa fitur kecil yang langsung terasa bagi developer.

Kenapa perlu tahu sekarang? Per 4 November 2026, PostgreSQL 18 sudah berumur lebih dari setahun (dirilis 25 September 2025) dan rilis minor terbarunya adalah 18.6. Artinya, versi ini sudah matang untuk produksi. Di sisi lain, PostgreSQL 14 akan berhenti didukung pada 12 November 2026. Kalau servermu masih di versi itu, rencana upgrade bukan lagi pilihan santai.

Status versi PostgreSQL per November 2026

Data dari halaman kebijakan versi resmi PostgreSQL, per 4 November 2026:

PostgreSQL 19 belum rilis final. Situs resmi baru mengumumkan PostgreSQL 19 RC 1 pada 15 Oktober 2026, dengan rilis final dijadwalkan 19 November 2026 bila tidak ada kendala. Release candidate bukan untuk produksi, jadi untuk upgrade hari ini, target yang masuk akal adalah 18.

Asynchronous I/O: perubahan terbesar di balik layar

Sebelum versi 18, PostgreSQL membaca data dari disk satu permintaan demi satu permintaan dan mengandalkan sistem operasi untuk membaca di muka. PostgreSQL 18 menambahkan subsistem asynchronous I/O (AIO) yang bisa mengirim beberapa permintaan baca sekaligus.

Menurut pengumuman rilis, AIO dipakai untuk sequential scan, bitmap heap scan, dan vacuum, dengan hasil benchmark hingga 3 kali lebih cepat pada skenario tertentu. Kata kuncinya "skenario tertentu": manfaat paling besar terasa pada storage dengan latensi tinggi, seperti disk jaringan di cloud. Query yang datanya sudah ada di memori tidak banyak berubah.

Pengaturannya lewat parameter io_method:

• worker (default): I/O asinkron dijalankan oleh proses worker.
• io_uring: memakai io_uring di Linux, hanya tersedia bila PostgreSQL dibangun dengan dukungan liburing.
• sync: perilaku lama sebelum versi 18.

Parameter ini hanya bisa diubah saat server start. Biarkan default dulu, ukur, baru coba io_uring bila paket distribusimu mendukungnya.

Fitur baru apa yang paling berguna untuk developer?

uuidv7()

Fungsi bawaan baru uuidv7() menghasilkan UUID yang berurutan menurut waktu. UUID acak (versi 4) membuat index B-tree tersebar ke mana-mana setiap kali baris baru masuk. UUID v7 masuk berurutan, sehingga index lebih rapi dan insert lebih ramah cache. Ada juga uuidv4() sebagai nama lain dari gen_random_uuid().

Kalau selama ini kamu membuat UUID v7 di sisi aplikasi atau lewat ekstensi, sekarang cukup DEFAULT uuidv7() di definisi kolom.

Kolom generated virtual, sekarang default

Kolom generated kini bisa bersifat virtual: nilainya dihitung saat dibaca, tidak memakan tempat. Yang perlu diingat, virtual sekarang menjadi default. Tanpa kata STORED, kolom generated baru akan virtual.

Dokumentasi menyebut beberapa batasan. Ekspresi kolom virtual hanya boleh memakai fungsi dan tipe bawaan, bukan buatan sendiri, dan replikasi logis kolom generated hanya didukung untuk jenis stored. Jika skrip migrasi lama mengandalkan perilaku stored, tulis STORED secara eksplisit.

OLD dan NEW di RETURNING

INSERT, UPDATE, DELETE, dan MERGE kini bisa mengembalikan nilai sebelum dan sesudah perubahan dalam satu query:

UPDATE accounts SET balance = balance + 10
WHERE id = 1
RETURNING old.balance AS sebelum, new.balance AS sesudah;

Berguna untuk log audit tanpa query tambahan.

Temporal constraint

WITHOUT OVERLAPS pada primary key atau unique constraint mencegah rentang waktu yang tumpang tindih, misalnya dua reservasi kamar yang sama di tanggal yang bentrok. Pasangannya, PERIOD pada foreign key.

Apa yang berubah untuk performa query?

Dua perbaikan planner yang sering terasa tanpa mengubah kode:

• Skip scan. Index B-tree multikolom kini bisa dipakai walau query tidak menyaring kolom terdepan dengan kondisi sama dengan. Index (status, created_at) misalnya bisa membantu query yang hanya menyaring created_at.
• Kondisi OR. Query dengan OR di WHERE kini bisa memakai index.

Selain itu, pembuatan index GIN kini bisa paralel, menyusul B-tree dan BRIN.

Apa artinya untuk rencana upgrade?

Di sinilah PostgreSQL 18 paling menolong admin. pg_upgrade kini mempertahankan statistik planner. Dulu, setelah upgrade mayor, database berjalan dengan statistik kosong sampai ANALYZE selesai, dan pada database besar masa itu bisa terasa lambat. Sekarang performa wajar tercapai lebih cepat.

Ada juga opsi --jobs untuk menjalankan pengecekan secara paralel, opsi --swap yang menukar direktori alih-alih menyalin file, dan proses yang lebih cepat untuk database dengan banyak objek.

Urutan yang aman untuk upgrade mayor tetap sama: backup lengkap yang sudah diuji pulih, coba upgrade di salinan server, cek ekstensi yang terpasang punya versi untuk PostgreSQL 18, lalu ukur query terpenting sebelum dan sesudah. Bila kamu masih menimbang engine database, perbandingannya ada di PostgreSQL vs MySQL vs MariaDB. Pilihan antara menjalankan sendiri di server atau memakai layanan terkelola dibahas di apa itu cloud database.

Fitur keamanan dan autentikasi

PostgreSQL 18 menambahkan metode autentikasi oauth untuk OAuth 2.0 lewat ekstensi, sehingga integrasi single sign-on lebih mudah. Ada pula pengaturan ssl_tls13_ciphers untuk cipher TLS 1.3, validasi mode FIPS, dan hashing password SHA-2 di pgcrypto. Untuk postgres_fdw dan dblink, SCRAM passthrough kini didukung.

Ringkasnya, PostgreSQL 18 layak menjadi target upgrade saat ini: AIO dan skip scan memberi performa tambahan tanpa ubah kode, uuidv7 dan RETURNING OLD/NEW memudahkan developer, dan pg_upgrade yang menyimpan statistik membuat upgrade mayor tidak semenegangkan dulu.