Tahun 2026, cukup gunakan Postgres

 (tigerdata.com)
5 poin oleh GN⁺ 2026-02-06 | 1 komentar | Bagikan ke WhatsApp
  • Postgres adalah platform terpadu yang dapat menangani berbagai fungsi seperti pencarian, vektor, deret waktu, antrean, dan lainnya dalam satu database
  • Pendekatan menggunakan banyak database khusus menimbulkan inefisiensi dan risiko dalam pengelolaan, keamanan, backup, dan penanganan gangguan
  • Di era AI, database perlu dapat dengan cepat digandakan, diuji, dan dihapus, sehingga arsitektur satu sistem menjamin kesederhanaan dan kelincahan
  • Extensions Postgres menggunakan algoritme yang sama dengan Elasticsearch, Pinecone, InfluxDB, dan lainnya, serta performanya juga telah terbukti
  • Bagi sebagian besar perusahaan (99%), satu Postgres saja sudah cukup, dan arsitektur terdistribusi yang kompleks hanya diperlukan oleh sangat sedikit perusahaan berskala sangat besar

Kebutuhan akan konsolidasi database

  • Database dianalogikan sebagai rumah, dan Postgres dijelaskan sebagai struktur yang menyatukan banyak fungsi di bawah satu atap
    • Berbagai kebutuhan seperti pencarian, vektor, deret waktu, dan antrean dapat ditangani dalam satu sistem
  • Sebaliknya, nasihat “gunakan alat yang paling tepat untuk tiap kebutuhan” pada akhirnya membuat kita mengoperasikan banyak database secara bersamaan
    • Diberikan contoh 7 sistem: Elasticsearch, Pinecone, Redis, MongoDB, Kafka, InfluxDB, dan PostgreSQL
    • Masing-masing harus mengelola query language, backup, keamanan, pemantauan, dan penanganan gangguan secara terpisah
  • Struktur terdistribusi seperti ini mempersulit penyusunan lingkungan pengujian dan pemecahan masalah, terutama saat menangani insiden dini hari ketika kompleksitas mencapai puncaknya

Kesederhanaan di era AI

  • AI agent perlu membuat, memverifikasi, dan menghapus database pengujian dengan cepat
    • Pada satu database, hal ini bisa dilakukan dengan satu perintah, tetapi pada banyak sistem diperlukan sinkronisasi snapshot dan penyesuaian konfigurasi
  • Mengelola banyak database sekaligus menuntut tingkat kompleksitas setara R&D
  • Di era AI, kesederhanaan ditekankan sebagai elemen yang esensial

Mitos “keunggulan” database khusus

  • Anggapan bahwa database khusus lebih unggul untuk tugas tertentu disebut sebagai efek pemasaran yang dibesar-besarkan
    • Dalam praktiknya, extension Postgres menggunakan algoritme yang sama atau bahkan lebih baik
  • Menurut tabel perbandingan, extension Postgres memiliki korespondensi berikut
    Fungsi DB khusus Extension Postgres Algoritme yang sama
    Pencarian full-text Elasticsearch pg_textsearch BM25
    Pencarian vektor Pinecone pgvector + pgvectorscale HNSW/DiskANN
    Deret waktu InfluxDB TimescaleDB Partisi waktu
    Caching Redis UNLOGGED tables Penyimpanan berbasis memori
    Dokumen MongoDB JSONB Pengindeksan dokumen
    Data spasial GIS PostGIS Standar industri
  • pgvectorscale mencatat latensi 28x lebih rendah dan biaya 75% lebih rendah dibanding Pinecone
  • TimescaleDB memberikan performa setara atau lebih baik daripada InfluxDB, dan pg_textsearch menggunakan peringkat BM25 yang sama dengan Elasticsearch

Biaya tersembunyi dari database yang tersebar

  • Mengoperasikan banyak sistem membuat seluruh biaya pengelolaan seperti backup, pemantauan, patch keamanan, dan penanganan gangguan meningkat 7 kali lipat
  • Beban kognitif: perlu mempelajari berbagai bahasa seperti SQL, Redis, Elasticsearch DSL, MongoDB, Kafka, dan InfluxDB
  • Masalah konsistensi data: kegagalan sinkronisasi antara Postgres dan Elasticsearch menyebabkan data drift
  • Penurunan ketersediaan: SLA dari banyak sistem saling dikalikan sehingga tingkat ketersediaan keseluruhan menurun (contoh: 99.9% × 3 = 99.7%)

Stack Postgres modern

  • Extension Postgres telah terbukti di layanan produksi selama bertahun-tahun
    • PostGIS (2001), Full-text search (2008), JSONB (2014), TimescaleDB (2017), pgvector (2021)
  • Lebih dari 48.000 perusahaan seperti Netflix, Spotify, Uber, Reddit, Instagram, dan Discord menggunakan PostgreSQL
  • Extension untuk era AI
    Extension Pengganti Karakteristik
    pgvectorscale Pinecone, Qdrant Algoritme DiskANN, latensi 28x lebih rendah, penghematan biaya 75%
    pg_textsearch Elasticsearch Implementasi langsung peringkat BM25 di Postgres
    pgai Pipeline AI eksternal Sinkronisasi embedding otomatis saat data berubah
  • Satu Postgres dapat digunakan untuk membangun aplikasi RAG: satu query language, satu backup, satu lingkungan pengujian

Contoh extension utama

  • pg_textsearch: pengganti Elasticsearch, mendukung pencarian berbasis BM25
  • pgvector + pgvectorscale: pengganti Pinecone, pencarian vektor berbasis DiskANN
  • TimescaleDB: pengganti InfluxDB, mendukung kompresi data deret waktu dan SQL
  • UNLOGGED tables: pengganti Redis, implementasi tabel cache
  • pgmq: pengganti Kafka, menyediakan fungsi message queue
  • JSONB: pengganti MongoDB, penyimpanan dan pengindeksan data dokumen
  • PostGIS: mendukung pemrosesan data spasial
  • pg_cron: otomatisasi pekerjaan terjadwal
  • pg_trgm: mendukung pencarian toleran typo
  • Recursive CTEs: implementasi fungsi penelusuran graf

Kesimpulan

  • Postgres adalah struktur seperti satu rumah dengan banyak ruangan, yang menyediakan beragam fungsi pemrosesan data secara terintegrasi
  • Bagi sebagian besar perusahaan (99%), satu Postgres sudah cukup, dan hanya sebagian sangat kecil (1%) yang memerlukan sistem terdistribusi berskala sangat besar
  • Nasihat “alat yang paling tepat untuk tiap kebutuhan” disebut sebagai logika pemasaran untuk menjual database
  • Diajukan prinsip mulai dengan Postgres, lalu tambahkan kompleksitas hanya saat benar-benar diperlukan
  • Ditutup dengan kesimpulan bahwa pada tahun 2026, cukup gunakan Postgres

Bacaan terkait

1 komentar

 
GN⁺ 2026-02-06
Komentar Hacker News

  • Sulit meng-embed Postgres ke aplikasi local-first, dan tidak nyaman karena harus memaksa konfigurasi Docker
    Andai PGlite mendukung beberapa koneksi writer, itu akan sempurna. SQLite juga oke, tetapi saya menginginkan ekstensi PG dan dukungan multi-writer paralel yang sungguh nyata

  • Setelah lama tidak mempelajari database lalu mendalaminya lagi, saya merasa Postgres benar-benar sistem yang seperti sihir
    Masukkan puluhan juta baris ke beberapa tabel dan cukup pasang indeks dengan benar, hampir semua query bisa merespons di bawah 100ms
    Saat menganalisis execution plan, sangat mengejutkan karena langsung terlihat indeks apa yang perlu ditambahkan. DB modern benar-benar ajaib

    • Yang Anda katakan itu sebenarnya bukan ciri khas DB ‘modern’, melainkan sesuatu yang bahkan sudah bisa dilakukan oleh Postgres 20 tahun lalu
      Tentu sekarang jauh lebih baik, tetapi sebagian besar perkembangan ada di fitur query tingkat lanjut atau optimasi operasional
    • DB relasional sudah menunjukkan performa seperti itu sejak puluhan tahun lalu. Itu bukan karakteristik khusus Postgres

  • Saya penggemar Postgres, tetapi tidak setuju dengan saran “pakai saja Postgres”
    Menyederhanakan stack dengan satu Postgres itu bagus, tetapi itu tidak selalu efisien untuk semua workload
    Pada masa Citus Data, saya sering melihat kasus di mana tim ahli Postgres harus terus-menerus melakukan tuning dan operasi
    Seiring bertambahnya use case berbasis AI, tren sekarang adalah mengadopsi teknologi khusus jauh lebih awal
    Rinciannya dirangkum di blog ClickHouse
    Saya pikir pendekatan yang lebih baik adalah memanfaatkan Postgres dan teknologi purpose-built secara terpadu

    • Saya memahaminya bukan sebagai “selalu pakai Postgres saja”, melainkan “pertimbangkan Postgres sebagai default”
    • Saya juga berada di posisi “pakai Postgres dulu, lalu ganti ke yang lain bila perlu”. Stack sederhana menguntungkan untuk pengembangan iteratif yang cepat
    • Sebenarnya, di dalam Postgres sendiri sudah ada banyak fitur sistem khusus. Kalau baca manual dan melakukan tuning, sering kali itu sudah cukup sebagai pengganti
    • Pada akhirnya, inti masalahnya adalah use case berbeda-beda. Lihat perbandingan MySQL dan Postgres
    • Saya rasa masalahnya adalah developer sekarang terlalu terseret hype dan terlalu memercayai teknologi
      Ketika teknologi tertentu menjadi standar, developer berubah menjadi komponen yang mudah diganti. Seperti developer React
      Penyeragaman teknologi, dari sudut pandang perusahaan, adalah strategi untuk mempermudah penggantian tenaga kerja. Kita harus menjaga keragaman alat

  • Saya juga sering memakai Postgres, tetapi kadang kesederhanaan lebih penting
    Untuk eksplorasi data atau pekerjaan GIS, Postgres.app sempurna, tetapi untuk server sederhana kadang SQLite lebih baik

    • Meski mulai sederhana dengan SQLite, tidak butuh waktu lama sampai menemui ketidaknyamanan. Postgres sudah di level “instal lalu lupakan saja”
      Bahkan untuk analisis data kecil, Postgres jauh lebih cepat daripada SQLite. Perbedaan indeks dan fitur sangat besar
    • SQLite adalah yang terbaik untuk pengujian integrasi. Tanpa container, DB bisa dengan mudah dinyalakan dan dimatikan
    • SQLite juga berguna untuk pemrosesan data sementara atau file penyimpanan lokal.
      Tetapi dalam 99% kasus saya memakai Postgres. Stabil, mudah diskalakan, dan terasa lebih baik daripada Oracle atau MySQL
    • Yang tidak nyaman dari Postgres adalah sulitnya mengatur hak akses agar hanya DB tertentu yang bisa diakses.
      GRANT ALL PRIVILEGES tidak selalu berhasil
    • Diskusi “DB apa yang sebaiknya dipakai” punya terlalu banyak variabel yang rumit
      Postgres gratis, cepat, dan bagus untuk aplikasi bersama, tetapi SQLite optimal untuk orang yang mengembangkan sendirian

  • Pada akhirnya, semuanya tergantung use case
    Dulu kami memakai pencarian berbasis MariaDB, lalu pindah ke Elasticsearch, dan hasilnya jauh lebih baik dari sisi kecepatan maupun kesederhanaan
    Tetapi untuk pencarian sederhana, Postgres sudah cukup.
    Sebelum pindah ke alat baru, lebih baik menunggu dulu, dan beralih hanya saat benar-benar perlu itulah yang efisien

  • DB seperti Pinecone atau Redis jauh lebih efisien secara biaya untuk kegunaan tertentu
    Namun tergantung situasinya, kadang lebih baik menyelesaikannya dengan Postgres.
    Pada akhirnya, keputusan harus dibuat berdasarkan skala dan ada tidaknya tim operasi

    • Setelah aplikasi dan data nyata sudah ada, akan lebih mudah memilih alternatif yang tepat
      Postgres cukup untuk sebagian besar tahap awal, dan setelah sistem membesar barulah solusi lain dipertimbangkan

  • Belakangan ini saya justru beralih ke MySQL dan SQLite alih-alih Postgres.
    Vacuum, maintenance, dan footgun di Postgres terasa merepotkan

    • MySQL hampir tidak punya beban operasional. Postgres harus terus dirawat, sedangkan MySQL biasanya jalan begitu saja
    • SQLite juga minim maintenance, tetapi untuk mencegah penumpukan ruang tetap perlu menjalankan VACUUM
    • MySQL mudah dikelola, tetapi harus melepas fitur tingkat lanjut (BRIN, partial index, dll.)
      Namun jika clustering index dirancang dengan baik, range scan bisa sangat cepat
    • Saya juga sempat mempertimbangkan pindah ke MySQL. Upgrade-nya mudah, tetapi laju perkembangannya lebih lambat daripada Postgres
    • Sangat disayangkan proyek Zheap di Postgres dihentikan.
      Kita membutuhkan storage engine tanpa VACUUM. Lihat wiki Zheap

  • Postgres memang hebat, tetapi ada dua masalah mendasar
    Pertama, Postgres bukan alat terpadu melainkan kumpulan alat, jadi beban belajarnya besar
    Kedua, Postgres dirancang berbasis HDD, sehingga bisa tidak efisien di era SSD
    RDBMS khusus SSD kemungkinan bisa lebih sederhana dan lebih cepat

    • Saya penasaran apa dasar pernyataan bahwa Postgres berbasis HDD. Ingin tahu sumbernya

  • Konfigurasi clustering (HA) Postgres terlalu rumit
    Ada alat seperti Patroni, Spilo, timescaledb-ha, tetapi sulit dikelola dan dokumentasinya juga kurang
    CloudNativePG satu-satunya cara yang terasa mudah, tetapi ada ketergantungan pada Kubernetes
    Akan bagus jika kita bisa membangun replica set sesederhana MongoDB

    • Namun Postgres bukan DB CP, dan saat terjadi network partition bisa muncul kehilangan penulisan
      Untuk lolos uji Jepsen, dibutuhkan perubahan struktural (seperti Yugabyte, Neon)

  • Ada pendapat tentang menggunakan Postgres sebagai cache
    Redis memang jauh lebih cepat, tetapi jika skalanya kecil, Postgres pun sudah cukup

    • Jika butuh cache, memcache itu sederhana dan stabil.
      Bahkan saat menangani miliaran request, ia tetap berjalan baik tanpa restart
    • Harus dibuktikan dengan benchmark apakah Redis benar-benar diperlukan. Jika tidak ada perbedaan yang berarti, Postgres sudah cukup
    • Saat membandingkan dengan Redis, sebaiknya gunakan unlogged table. Jika fitur durabilitas dimatikan, kecepatannya jauh meningkat
    • Jika kebutuhan cache aplikasi tidak besar, mulailah dengan Postgres,
      dan bila arsitekturnya server stateless, Redis layak dipertimbangkan. Jika proses jangka panjang berbasis JVM, cache internal juga memungkinkan
    • Materialized view di Postgres juga cukup berguna.
      Namun jika bebannya membesar, cache eksternal akan dibutuhkan, dan konsistensi transaksi harus dikorbankan