PgDog - alat untuk melakukan sharding Postgres tanpa ekstensi terpisah

 (github.com/pgdogdev)
4 poin oleh GN⁺ 2025-05-29 | 1 komentar | Bagikan ke WhatsApp
  • Transaction pooler dan manajer replikasi logis untuk PostgreSQL yang dikembangkan dengan Rust, menyediakan skalabilitas horizontal dan otomatisasi sharding
  • Memungkinkan sharding database PostgreSQL dengan mudah tanpa ekstensi, serta dioptimalkan untuk mengelola ratusan database dan ratusan ribu koneksi
  • Load balancer DB yang berjalan di lapisan aplikasi (OSI 7), dapat merutekan SELECT ke replika dan kueri lainnya ke primary secara otomatis
  • Mendukung transaction/session pooling seperti PgBouncer, sekaligus mem-parsing kueri untuk perutean otomatis ke shard dan menggabungkan hasilnya
  • Menggunakan COPY dan replikasi logis untuk mendistribusikan data ke shard secara otomatis atau melakukan sharding DB yang sudah ada tanpa downtime
  • Konfigurasinya dapat didefinisikan secara sederhana melalui file TOML, dan mendukung rekonfigurasi saat runtime
  • Berbeda dengan Citus yang menggunakan ekstensi Postgres, ini adalah proxy eksternal DB sehingga bisa digunakan juga di RDS, Cloud SQL, dan lainnya

Pengenalan proyek dan nilai utamanya

  • PgDog adalah solusi open source yang mendukung perluasan horizontal PostgreSQL secara menyeluruh, termasuk sharding yang mudah, replikasi logis, transaction pooling, dan load balancing L7
  • Dikembangkan dengan bahasa Rust untuk menghadirkan kinerja tinggi dan keamanan
  • Tanpa perlu memasang ekstensi, PgDog memungkinkan sharding, distribusi data, pemulihan kegagalan, dan load balancing yang fleksibel hanya dengan deployment satu proxy
  • Berbeda dari produk pesaing (misalnya PgBouncer, PgCat, dll.), keunggulannya adalah mendukung sharding otomatis dan replikasi logis sekaligus, serta memungkinkan perubahan konfigurasi saat sistem berjalan dan pemantauan real-time

Fitur utama

Load balancing

  • PgDog adalah proxy level aplikasi di lapisan OSI 7 yang membagi kueri ke beberapa replika dan node utama PostgreSQL untuk mencegah kegagalan dan kelebihan beban
  • Menyediakan berbagai strategi distribusi seperti round robin, acak, dan least connections
  • Mengidentifikasi jenis kueri sehingga SELECT dikirim ke replika, sedangkan kueri tulis lainnya otomatis diteruskan ke node utama
  • Melakukan health check dan failover otomatis saat terjadi gangguan, sehingga ketersediaan tetap terjaga meskipun ada error jaringan atau kegagalan perangkat keras

Transaction pooling

  • Seperti PgBouncer, PgDog mendukung transaction dan session pooling untuk pengelolaan sumber daya koneksi yang efisien, sehingga ratusan ribu klien dapat ditangani dengan sedikit koneksi backend

Sharding

  • Mem-parsing sintaks kueri secara langsung untuk mengekstrak sharding key dan menerapkan algoritme perutean yang optimal
  • Mendukung kueri lintas shard antar database multi-shard, lalu menggabungkan hasilnya di memori dan mengirimkannya ke klien secara transparan
  • Saat menjalankan perintah COPY, mendukung distribusi data multi-shard melalui parsing CSV, sehingga praktis untuk pemuatan data skala besar
  • Berdasarkan protokol replikasi logis PostgreSQL untuk sinkronisasi latar belakang tanpa downtime, serta memungkinkan penambahan dan ekspansi shard secara real-time saat sistem beroperasi

Monitoring

  • Mendukung database administrasi bergaya PgBouncer dan endpoint OpenMetrics
  • Menyediakan contoh dashboard dan integrasi monitoring eksternal seperti Datadog

Konfigurasi dan runtime

  • Lingkungan utama: Kubernetes (menyediakan Helm chart), Docker, dan lingkungan lokal (build Rust) untuk deployment dan pengujian dengan mudah
  • Umumnya cukup menulis 2 file konfigurasi (pgdog.toml, users.toml) untuk menyiapkan lingkungan operasional minimum berbasis sharding dan pengguna
  • Sebagian besar nilai konfigurasi dapat diubah secara real-time dan diterapkan secara dinamis tanpa restart proses

Performa dan lisensi

  • PgDog adalah proxy jaringan asinkron berperforma tinggi berbasis Rust dan Tokio, dengan fokus meminimalkan perpindahan data dan menekan penurunan performa
  • Hasil benchmark tersedia di dokumentasi resmi sehingga dapat dijadikan acuan performa
  • Menggunakan lisensi open source AGPL v3, terbuka sepenuhnya untuk penggunaan internal perusahaan dan kustomisasi privat
  • Namun, perusahaan yang menyediakan layanan public cloud harus membagikan detail perubahan kode jika melakukan modifikasi

Status proyek dan kontribusi

  • Saat ini masih tahap awal, sehingga adopsi mandiri oleh early adopter lebih disarankan, sementara stabilisasi tiap fitur terus diperbarui
  • Pengujian dan benchmark per fitur juga terus dilakukan
  • Kontribusi dari komunitas open source disambut, detail lebih lanjut dapat dilihat di Contribution Guidelines

Kesimpulan

  • PgDog menawarkan solusi unggul bagi tim pengembang dan perusahaan yang membutuhkan skalabilitas horizontal, high availability, dan sharding otomatis PostgreSQL di lingkungan operasional
  • Keunggulan besarnya adalah dapat diterapkan dengan cepat dan dikustomisasi tanpa perlu ekstensi terpisah atau infrastruktur yang rumit

Bacaan terkait

1 komentar

 
GN⁺ 2025-05-29
Komentar Hacker News

  • Menyapa Lev sambil menjelaskan bahwa saat ini sedang membandingkan PgDog dengan solusi buatan sendiri untuk sharding database Postgres berukuran 40TB, dan menyebut bahwa mereka membutuhkan solusi yang bekerja seperti Vitess for PostgreSQL. Ia menekankan bahwa selain fitur scatter-gather, juga diperlukan manajemen konfigurasi berbasis sesuatu seperti etcd, pemecahan shard, serta transaksi best-effort untuk menerapkan perubahan skema ke seluruh shard. Ia juga menanyakan pengalaman menulis ulang kueri dengan pg_query.rs, berbagi bahwa ia merasa kesulitan karena tipe AST yang immutable dan kurangnya deep clone, dan akhirnya sedang menggunakan crate sqlparser yang mendukung pola Visitor. Ia juga menceritakan bahwa sedang mengembangkan perubahan skema online untuk PG sebagai proyek sampingan berbasis shadow tables dan replikasi logis

    • Menyambut senang usulan kolaborasi dan membagikan kontak, sambil menjelaskan bahwa manajemen konfigurasi sebenarnya sudah bisa ditangani dengan K8s atau berbagai alat CD, dan sinkronisasi reload konfigurasi PgDog juga dimungkinkan. Ia menyebut bahwa perubahan skema lintas semua shard dengan transaksi best-effort sudah berjalan, dan walau perubahan skema yang idempoten adalah yang paling baik, two-phase commit juga sedang dipertimbangkan untuk kasus gagal. Untuk pemecahan shard, ia memberi contoh bahwa hal itu bisa dilakukan dengan replikasi logis dan menyebut pengalaman 10TB+ di Instacart. Ia membagikan prosedur membuka replication slot, memulihkan ke N instance, menghapus data yang nomor shard-nya tidak cocok, lalu menyinkronkan ulang melalui replikasi logis. Ia juga mengungkap ide pemecahan paralel dengan memakai replikasi logis Pg 17 dari streaming replica, serta sedang memikirkan cara menyalin data langsung lewat COPY ke foreign table. Ia menekankan bahwa pg_query.rs kini tampaknya bekerja secara mutable sehingga belakangan ini benar-benar aktif dipakai untuk penulisan ulang dan pembangkitan kueri, dan keunggulan pentingnya adalah 100% berbasis parser Postgres. Fitur "deparse" tersebar di berbagai tempat sehingga kemungkinan untuk pekerjaan kompleks cukup besar

  • Pertanyaan apakah jika ada Vitess for Postgres, bukankah Yugabyte sudah menjalankan peran itu

  • Dari sisi fitur inti memang terlihat kecil, tetapi menurutnya keunggulan besar PgDog adalah bisa memisahkan baca ke read replica dan tulis ke primary tanpa perlu mengubah kode. Karena banyak aplikasi tidak mendukung pemisahan R/W secara langsung, pengalaman masa lalu menunjukkan bahwa menanganinya di level proxy pernah memberi peningkatan kecepatan yang besar, sambil memuji proyek ini

    • Dijelaskan bahwa fitur ini juga sudah bisa digunakan di pgcat, sambil membagikan tautan pgcat

    • Berbagi pengalaman bahwa di Instacart mereka dulu memakai Makara untuk pemisahan R/W, tetapi menerapkan hal yang sama berulang kali di berbagai lingkungan bahasa seperti Python atau Go cukup merepotkan

  • Menilai proyek ini mengesankan, tetapi merasa sedikit menjaga jarak dari sharding yang sepenuhnya otomatis. Ia menjelaskan bahwa umumnya sharding dilakukan pada batas tenancy, dan ia ingin ada friksi ketika melintasi batas itu. Join lintas shard berbeda dari join dalam shard dari sisi performa, memori, dan CPU, sehingga menurutnya hal ini sebaiknya ditampilkan dengan jelas. Meski begitu, ia tidak meragukan proyeknya dan yakin akan ada sangat banyak kasus penggunaan

    • Bertanya mengapa justru menginginkan friksi, lalu menambahkan bahwa isu performa join lintas shard pada umumnya sudah cukup dipahami dan bisa dilacak lewat metrik real-time. Pada akhirnya kedua pendekatan sama-sama dibutuhkan, dan alternatif melakukan join di kode aplikasi bukanlah pilihan yang terlalu baik

  • Mengatakan sedang memantau PgDog dan menilainya sangat mengesankan, sambil menyampaikan selamat atas peluncurannya dan harapan agar terus berkembang

    • Menyebut bahwa perjalanan 15 tahun ini baru saja dimulai

  • Menilai daya tarik utamanya adalah kemampuan menangani kueri terdistribusi sambil menjaga transparansi dan kompatibilitas di lapisan jaringan. Keterbatasan yang saat ini ada di dokumentasi dianggap wajar, dan ia memperkirakan pasti ada trade-off yang diperlukan. Ia penasaran bagaimana hal itu akan diselesaikan dan mengusulkan untuk ikut berdiskusi lebih lanjut bila ada kesempatan

  • Menyebut bahwa kesulitan terbesar dalam solusi seperti PgDog adalah menangani 1% terakhir dari kueri kompleks yang di-shard dengan benar (atau mendeteksi kueri yang tidak normal), serta menjamin isolasi dan konsistensi secara penuh

  • Begitu melihat dokumentasinya, hal pertama yang dicek adalah dukungan Unique Index, tetapi ia memberi masukan bahwa sayangnya fitur itu belum didukung karena masih membutuhkan penulisan ulang kueri dan execution engine terpisah. Meski begitu, potensinya terlihat menjanjikan

    • Menjelaskan bahwa sebagai kompensasi kecil, pembuatan primary key unik di semua shard sudah didukung, sambil membagikan tautan dokumentasi terkait. Implementasi unique index lintas shard dibuka sebagai ide karena mahal biayanya, mengingat harus diperiksa pada semua kueri

  • Menekankan bahwa ini adalah proyek Postgres paling menarik yang ia lihat dalam beberapa tahun. Menurutnya benchmark yang diberikan tampaknya hanya membahas connection pooling dasar, sehingga ia penasaran bagaimana hasilnya saat parsing kueri atau join lintas shard benar-benar berjalan

    • Dijelaskan bahwa parser kueri di-cache, sehingga saat memakai prepared query atau placeholder, biaya tambahannya nyaris tidak ada selain lock dan hash lookup. Untuk join lintas shard, diperkirakan biaya pemrosesan kueri bisa tinggi ketika filter tidak optimal, dan mungkin perlu paging ke disk saat himpunan hasil besar. Fokus utama saat ini adalah OLTP dengan upaya mendorong join sedekat mungkin ke bawah, tetapi diperkirakan kebutuhan join lintas shard juga akan segera meningkat

  • Menilai ini sebagai inovasi yang benar-benar dibutuhkan untuk skalabilitas Postgres, sambil mengucapkan selamat atas peluncurannya

  • Mengatakan proyek ini terlihat sangat bagus dan selamat atas peluncurannya

    • Menekankan bahwa ini adalah hasil dari upaya bertahun-tahun