PgDog menutup pendanaan dan hadir di database terdekat Anda

 (pgdog.dev)
1 poin oleh GN⁺ 4 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • PgDog adalah proxy yang ditempatkan di depan PostgreSQL, memungkinkan Postgres diskalakan secara horizontal melalui connection pooling, load balancing, dan sharding tanpa perlu menulis ulang aplikasi
  • Keberadaan database seperti Mongo atau Dynamo dipandang berasal dari masalah skalabilitas Postgres, dan jika Postgres bisa menangani tabel di atas 100TB serta 1 juta kueri per detik, maka database lain tidak akan dibutuhkan
  • PgDog menangani lebih dari 2 juta kueri per detik di production, telah melakukan sharding lebih dari 20TB dalam cakupan yang terverifikasi, dan Docker pull di GitHub telah melampaui 1,4 juta kali
  • Tim beranggotakan tiga orang ini menangani masalah sharding Postgres di RDS, Aurora, dan EC2 berdasarkan pengalaman membangun aplikasi skala besar berbasis Postgres dan pengalaman penskalaan 5x Instacart pada 5 April 2020
  • Mereka menggalang US$5,5 juta dari Basis Set, YC, Pioneer Fund, dan lainnya, serta sedang membangun PgDog sebagai produk open source yang membuat Postgres bekerja di semua skala

Pendanaan dan arah produk

  • Pengembangan Postgres dimulai dari pandangan bahwa ini adalah satu-satunya database yang dibutuhkan
  • Keberadaan database seperti Mongo atau Dynamo dipandang sebagai akibat dari masalah skalabilitas Postgres
  • Jika Postgres dapat menangani tabel di atas 100TB dan 1 juta kueri per detik dengan baik, maka tidak perlu memakai database lain
  • PgDog memungkinkan penskalaan horizontal dengan menempatkan proxy di depan Postgres yang sudah ada
  • PgDog dapat di-deploy di mana saja, termasuk on-premise dan di akun cloud pengguna
  • Cukup pull image Docker dan ubah DATABASE_URL, lalu PgDog yang akan menangani sisanya

Kondisi saat ini dan latar belakang eksekusi

  • Status saat ini

    • PgDog saat ini memproses lebih dari 2 juta kueri per detik di puluhan deployment production
    • Dalam cakupan yang terverifikasi, PgDog telah melakukan sharding lebih dari 20TB
    • PgDog bersifat open source dan siapa pun bisa men-deploy-nya
    • Docker pull di GitHub telah melampaui 1,4 juta kali
    • Versi baru dirilis setiap hari Kamis
    • Komunitas Discord terus berkembang, dengan tanya jawab dan dukungan setiap hari

  • Tim dan dasar kepercayaan

    • PgDog adalah startup kecil dengan tim beranggotakan tiga orang
    • Tim terdiri dari infrastructure engineer, application engineer, dan generalist
    • Tim ini telah membangun aplikasi berbasis Postgres dan menjalankannya dalam skala besar bahkan sebelum Postgres mendapat sorotan luas
    • Mereka memperoleh pengalaman operasional Postgres saat Instacart tumbuh 5x pada April 2020
    • Saat itu, masalah terbesarnya adalah membuat Postgres mampu memproses ratusan ribu pesanan pengiriman bahan makanan per menit
    • Mereka melakukan sharding Postgres di RDS, Aurora, dan EC2, lalu menyelesaikan masalah nyata dengan prinsip dasar dan banyak kode
    • Teknologi yang sama kini tersedia sebagai produk open source

  • Metode deployment dan pendanaan

    • Pengembangan PgDog bukan pivot; tujuan satu-satunya tetap memperluas skala Postgres
    • PgDog dibuat untuk berjalan di cloud pengguna, rak colocation, on-premise, maupun laptop
    • PgDog bekerja di tempat yang dibutuhkan tanpa dependensi atau biaya serverless tersembunyi
    • Jika Anda bisa menyediakan CPU, kode multithreaded PgDog akan memakai seluruh CPU tersebut
    • Adopsi Postgres diperkirakan akan terus meningkat
    • Mereka menggalang US$5,5 juta dari Basis Set, YC, Pioneer Fund, dan investor lainnya, sehingga memiliki runway untuk beberapa tahun
    • Tujuannya adalah membuat Postgres benar-benar bekerja untuk semua orang dan di semua skala

  • Enterprise edition

    • Enterprise edition dari PgDog sedang dikembangkan agar lebih mudah dijalankan di AWS
    • Enterprise edition menyediakan dukungan berbasis SLA dari tim

Bacaan terkait

1 komentar

 
GN⁺ 4 jam lalu
Pendapat Hacker News

  • Alasan database seperti Mongo atau Dynamo ada memang sering dikaitkan dengan masalah scaling Postgres, tetapi dari pengalaman memakai Postgres di beberapa tempat, masalah nomor satu selalu high availability dan bukan scaling
    Dengan satu klaster Postgres, kami bisa dengan mudah menangani 100 ribu transaksi per menit, tetapi ketika node utama mati, kami harus menerima panggilan, melakukan failover manual ke node cadangan, lalu mengganti node cadangan itu juga secara manual
    Alat manual sangat merepotkan, tetapi setidaknya bekerja, sedangkan solusi otomatis bahkan tidak mendekati harapan
    Karena kurangnya cerita HA yang bagus, kami sebisa mungkin menghindari Postgres self-hosted

    • Kami juga mendukung HA: https://docs.pgdog.dev/features/load-balancer/
      Load balancer dengan health check dan failover berjalan secara bawaan, dan sekarang sudah cukup teruji di dunia nyata sehingga layak dilihat
    • Patroni 1.0 dirilis pada 2016, jadi itu hampir 10 tahun lalu
      https://github.com/patroni/patroni
    • Penasaran apakah kamu sudah mencoba cnpg
      Untuk kebutuhan saya, itu benar-benar bekerja dengan baik
    • Sekarang Patroni cukup bagus dalam menangani area ini
    • Penasaran apakah kamu juga sudah melihat sesuatu seperti CloudNativePG: https://cloudnative-pg.io/

  • Jika di bagian “Why Us” tertulis “Kami mengoperasikan Postgres di Instacart, dan ketika perusahaan tumbuh 5x pada April 2020, masalah terbesar adalah membuat Postgres mampu memproses ratusan ribu pesanan pengiriman bahan makanan per menit”, rasanya sulit membayangkan alasan memilih kami yang lebih baik dari itu

    • Apakah 100 ribu pesanan per menit itu banyak?
      Rasanya satu instance Postgres pun bisa menanganinya
    • Saya penasaran kenapa patokannya diubah menjadi per menit
      SSD enterprise modern berkualitas tinggi bisa menangani sekitar 35 ribu fsync nyata per detik
    • Saya selalu merasa Instacart sangat lambat dan latensinya tinggi
      Tentu saya tidak tahu apakah itu karena Postgres atau cacat desain lain

  • Saya pada dasarnya ingin memahami ini, karena saat ini saya punya DB 4TB di satu server besar
    Jika memakai alat proksi seperti PGDog, apakah strukturnya menjadi 8 server kecil yang masing-masing menangani sekitar 500GB, ditambah 1 server kelas menengah untuk proksi?
    Proyek saat ini punya trafik tulis yang sangat tinggi dari banyak layanan, dan aplikasi web membaca dari sana
    Sekarang kami mulai mendekati titik ketika indexing, optimasi query, caching, dan upgrade server sudah tidak banyak membantu
    Kami juga sedang melihat kemungkinan memindahkan sebagian besar data statis ke ClickHouse untuk mengurangi ukuran DB, tetapi ingin tahu apakah PgDog atau sharding lain berguna untuk kebutuhan seperti ini

    • “8 server kecil yang masing-masing menangani sekitar 500GB dan 1 server kelas menengah untuk proksi” memang tepat seperti itu
      Akan bagus kalau Anda menghubungi kami (lev@pgdog.dev)
      Kami bisa membantu, atau setidaknya memberi tahu apa yang saat ini berhasil dan apa yang tidak, supaya Anda bisa memahami opsinya
    • Itulah konsep sharding
      Jika membaca dokumentasi pgdog, Anda akan melihat bahwa Anda harus memberi tahu ke server shard mana permintaan harus dirutekan, jadi ini tidak bekerja begitu saja secara ajaib
      Meski begitu, tetap bernilai karena ia juga mendaur ulang koneksi yang sangat mahal di Postgres
      Ini bukan sihir, jadi Anda perlu memahami apa yang terjadi di dalamnya; misalnya, tidak ada transaksi lintas-shard
      Sharding itu sulit jika Anda peduli pada konsistensi data, jadi saya akan lebih dulu melihat apakah aplikasi bisa mendapat manfaat dari read replica
      Setiap replika memiliki salinan penuh data, penulisan hanya terjadi ke master, dan Anda sendiri harus menentukan transaksi mana yang aman dijalankan di replika yang mungkin sedikit tertinggal dari kondisi hampir real-time
      Misalnya, pembacaan untuk membangun halaman web umumnya aman dilakukan di replika, tetapi pola baca-modifikasi-tulis tidak demikian

  • Saya penasaran bagaimana ini akan membantu untuk upgrade versi mayor, penyebab downtime terbesar di Postgres
    Pooler sangat bagus untuk failover dan load balancing, tetapi karena upgrade, tetap dibutuhkan downtime sekitar 10–20 menit secara konsisten sekali atau dua kali setahun
    Replikasi logis dari versi lama ke versi baru mungkin bisa membantu, tetapi sepertinya tetap perlu memindahkan semuanya ke klaster baru tanpa penulisan parsial atau keadaan aneh
    Penasaran apakah ada yang punya pengalaman seperti ini

    • Kami menggunakan replikasi logis dan pause/switchover pgbouncer agar write tidak gagal dan hanya berhenti sekitar 5 detik
      Ukuran DB sekitar 1–1,5TB, tetapi volume perubahan maupun jumlah query per detik tidak terlalu besar
      Pada dasarnya seperti yang dijelaskan di sini: https://www.pgedge.com/blog/always-online-or-bust-zero-downt...
    • Biasanya ditangani dengan replikasi logis
      Jika Anda punya konfigurasi infrastructure-as-code, buat klaster baru yang konfigurasinya sama kecuali versi mayor, impor skema, mulai penyalinan data dari read replica versi lama, hentikan penerimaan write di versi lama (downtime mulai), sinkronkan nomor sequence, lalu arahkan layanan ke klaster baru (downtime selesai)
      Jika memakai sesuatu seperti CloudNativePG, sebagian proses ini bisa diotomatisasi dengan tool CLI dan sintaks deklaratif
      Kalau tidak, ya perlu meluangkan waktu untuk memahaminya sendiri
      Kedengarannya mungkin rumit, tetapi setelah latihan di staging DB dan berhasil, Anda tinggal menjalankan prosedur yang sama di produksi
      Tambahan lagi, tampaknya Postgres 19 punya patch untuk replikasi logis satu kali pada sequence: https://www.depesz.com/2025/11/11/waiting-for-postgresql-19-...
    • Replikasi logis menyelesaikan ini
      Jika klaster dijalankan secara bergiliran, downtime-nya sangat kecil, kira-kira sekitar 60 detik
    • Aneh rasanya PostgreSQL masih belum punya implementasi multi-master open source umum yang benar-benar layak
      Pada titik ini saya ragu apakah saya akan sempat melihatnya suatu hari nanti
    • Kalau datang dari MySQL, ini kemunduran besar dan membuat Postgres terlihat seperti barang dari tahun 80-an
      Saya masih heran kenapa ini tidak dianggap sebagai prioritas mutlak tertinggi

  • Selamat atas pendanaannya, Lev
    Di sini kami memakai PgDog dengan puas
    Salah satu fungsi proxy yang sangat saya suka adalah kemampuannya menangani pengaturan koneksi yang berbeda per koneksi, misalnya statement_timeout
    Saat dulu saya meneliti RDS Proxy, seingat saya itu tidak didukung, begitu juga pgbouncer, jadi perlu banyak perubahan aplikasi
    Di PgDog, semuanya bekerja begitu saja secara transparan

  • Saya penasaran apakah ini sebanding dengan multigres dari Supabase yang baru diumumkan

  • Saya melihat ada Enterprise Edition, jadi saya ingin tahu apakah bisa dijelaskan dengan jelas fitur mana yang bukan open source
    Saya juga penasaran apakah Anda memperkirakan fitur-fitur baru yang ditambahkan akan memakai lisensi EE demi memberi imbal hasil kepada investor VC

    • Ada dua fitur besar
      Pertama, control plane yang mengelola deployment multi-node, sehingga memberi pengalaman “langsung jalan” agar PgDog mudah dideploy dan digunakan
      Kedua, quality-of-service (QoS), yang secara otomatis memblokir query buruk agar tidak menjatuhkan database
      Terakhir, Anda juga bisa mendapatkan dukungan dengan SLA yang dijamin hingga P0
      Fitur baru terbagi ke dalam dua kategori
      Sharding dan operasi Postgres skala besar akan selalu open source, sedangkan manajemen infrastruktur dan fitur yang membuat PgDog mudah dijalankan dalam skala besar adalah enterprise

  • Senang melihat PgDog, Neki, dan multigres bermunculan
    Memang ini masalah inti Postgres, dan tidak adanya index hints juga jadi masalah, jadi saya menantikan Postgres 19

    • Jangan lupa PgBouncer sebagai pelopornya
      Konfigurasinya memang sulit, tetapi sekarang lebih mudah menyusunnya dengan bantuan AI
    • Ekstensi pg_hint_plan memang tidak masuk ke core, tetapi cukup andal ketika Anda perlu menimpa planner

  • “Kami tahu sudah melakukan sharding lebih dari 20TB” mungkin salah ketik
    20TB tidak sebesar itu
    Saya kira jumlah yang di-shard pasti jauh lebih besar

    • Kalau Anda menganggap 20TB itu “tidak sebesar itu”, saya jadi ingin tahu ukuran DB seperti apa yang Anda tangani
    • Jika working set-nya 20TB, itu cukup besar
      Setiap database punya rasio data panas dan data dingin yang berbeda, jadi tanpa informasi tambahan mustahil membandingkannya
      Metrik yang lebih baik mungkin IOPS
      RDS punya IOPS maksimum yang cukup rendah kecuali Anda menghabiskan jauh lebih banyak biaya untuk provisioned IOPS atau memakai Aurora
    • Betul
      Sebagai perbandingan, hampir 10 tahun lalu di Segment kami menjalankan satu instance Aurora PostgreSQL dengan sekitar 50TB data, dan itu dipakai untuk mengindeks data pengenal potensial dalam korpus file yang jauh lebih besar yang disimpan di S3
    • Untuk sebagian besar use case, 20TB jelas sangat besar

  • PgDog bagus
    Sejujurnya saya tidak membutuhkannya, tetapi saat hiking di hutan saya tidak punya apa pun untuk didengarkan, lalu kebetulan mendengar podcast Postgres FM, jadi tertarik dan sekarang memakainya di Kubernetes on-prem saya
    https://open.spotify.com/episode/6qgpfiW68KcvRASs6649Fb