Postgres WASM yang berjalan di dalam browser, PGlite

 (pglite.dev)
2 poin oleh GN⁺ 2024-08-13 | 1 komentar | Bagikan ke WhatsApp
  • Di aplikasi yang mengutamakan lokal dan lingkungan pengembangan berbasis browser, Postgres lengkap dapat dijalankan langsung sebagai WASM sehingga ketergantungan pada server bisa dikurangi
  • Tersedia sebagai build di bawah 3MB dalam ukuran Gzip, sehingga mudah di-embed ke browser maupun lingkungan lokal
  • Melalui pemuatan ekstensi dinamis, ekstensi Postgres seperti pgvector dan PostGIS dapat digunakan
  • Memiliki primitif bawaan untuk pemuatan data, sinkronisasi, dan live query, sehingga cocok untuk aplikasi reaktif dan use case real-time
  • database.build dari Supabase, berbasis PGlite, menghadirkan pengalaman membuat dan memublikasikan database Postgres dengan bantuan AI

Postgres untuk browser dan lokal

  • PGlite adalah Postgres tertanam yang menjalankan database Postgres lengkap secara lokal di WASM
  • Ini adalah build WASM Postgres yang lengkap, sekaligus tersedia dalam ukuran di bawah 3MB setelah kompresi Gzip
  • Memiliki primitif bawaan untuk pemuatan data, sinkronisasi, dan live query, sehingga dapat membangun alur data reaktif yang berpusat pada klien

Ekstensi dan lingkungan eksperimen

  • Mendukung mekanisme pemuatan ekstensi dinamis
    • Termasuk pgvector
    • PostGIS juga dapat digunakan
  • Lebih banyak ekstensi dapat dicoba di Playground
  • Anda dapat langsung mencoba PGlite Postgres lengkap yang berjalan di dalam browser pada halaman saat ini, termasuk pgvector

Dokumentasi dan kanal distribusi

  • Dokumentasi awal tersedia di Get Started
  • GitHub menampilkan 15.5K bintang
  • NPM menampilkan 10.1M unduhan mingguan

database.build dari Supabase

  • database.build adalah layanan yang dibuat Supabase berbasis PGlite
  • Menyediakan alur untuk membuat dan memublikasikan database Postgres dengan AI

Bacaan terkait

1 komentar

 
GN⁺ 2024-08-13
Opini Hacker News

  • Dulu saya pernah melihat ini berjalan di browser dan terkesan karena bisa dilakukan hanya dengan unduhan sekitar 3MB, tetapi saya melewatkan fakta bahwa ini juga berjalan di sisi server dengan Node.js dan Bun: https://pglite.dev/docs/
    Karena ini tidak menjalankan server jaringan sungguhan, rasanya seperti alternatif untuk SQLite, dan menarik bahwa kita bisa langsung menjalankan implementasi PostgreSQL in-process yang dipersistenkan ke disk di dalam aplikasi Node.js/Bun yang sudah ada
    Saya juga ingin mencobanya di Python dengan wrapper seperti https://github.com/wasmerio/wasmer-python atau https://github.com/bytecodealliance/wasmtime-py, dan penasaran apakah sudah ada yang pernah menjalankan PGlite dengan cara seperti ini

    • Membuat PGlite bekerja dengan baik di bahasa lain adalah prioritas yang sangat tinggi
      Ada dua pendekatan yang sedang dikerjakan: satu adalah build WASI dari API tingkat rendah yang bisa dibungkus pengguna dengan API tingkat tinggi, dan satu lagi adalah libpglite yang bisa ditautkan dari bahasa native
      Sebagian besar bahasa sudah memiliki implementasi wire protocol Postgres, jadi membungkus API tingkat rendah yang membaca dan mengeluarkannya relatif mudah, dan sisi JS PGlite juga bekerja dengan cara yang sama
    • Sebagai solusi sementara, di Python tampaknya memungkinkan untuk memanggil skrip Node.js dengan subprocess untuk menjalankan exec dan query dari @electric-sql/pglite, lalu bertukar hasil dalam JSON
      Strukturnya adalah membuat instance PGlite di db.js, menerima SQL dan parameter dari argumen command line untuk diproses, lalu dari main.py memanggil node db.js exec ... atau node db.js query ...
    • Saya juga ingin mencoba PGlite di Python, dan saat membaca thread ini saya sadar bahwa di Pyodide ini sudah bisa diakses
      Pyodide adalah port Wasm dari CPython dan bisa berinteraksi dengan objek JavaScript melalui proxy
      Sebagai contoh, setelah membuat globalThis.db = new PGlite(), kode Python melakukan await pada js.db.query() untuk menjalankan SELECT 'Hello, world!' AS "greeting";, dan saat ini bekerja di Node.js 18, Deno 1, dan Bun 1
    • Akan bagus jika seseorang yang lebih paham soal lisensi bisa menjelaskan dampaknya pada proyek komersial atau solusi, dan bagaimana perbandingannya dengan embedded FirebirdSQL atau sejenisnya
      Misalnya, saya penasaran apakah ini bisa digunakan dalam proyek komersial tanpa membuka source, dan apakah saat di-embed lisensinya harus diubah agar sesuai dengan pg/fb
      Kalau benar-benar perlu sekarang saya akan meninjaunya sendiri, tetapi beberapa hal yang tidak saya sukai dari kesederhanaan SQLite cukup mirip dengan hal-hal yang tidak saya sukai di MySQL/MariaDB, jadi saya jadi penasaran
    • Menarik untuk melihat seberapa baik ini benar-benar akan berjalan
      Saya tidak tahu bagaimana mereka memodifikasi lapisan persistensi PostgreSQL, tetapi dibandingkan menjalankan PostgreSQL di container Docker, tampaknya mungkin ada batasan
      SQLite tidak memiliki batasan seperti itu

  • Saya sangat menyukai PGlite
    Ini solusi sempurna untuk memiliki Postgres tanpa Docker, dan hanya dengan npm install kita bisa membuat instance Postgres di komputer lokal, sehingga onboarding developer baru ke tim menjadi sangat mudah
    Ini juga bekerja dengan baik bersama Next.js, dan saya menggunakannya dengan Next.js Boilerplate di lingkungan lokal dan pengembangan: https://github.com/ixartz/Next-js-Boilerplate
    Dengan satu kali npm install, aplikasi full-stack termasuk database—yaitu Postgres yang berjalan—sudah siap, tanpa perlu memasang tool eksternal

    • Biasanya dependensi pengembangan ditangani dengan docker compose, tetapi ini jelas terlihat seperti alternatif yang keren

  • Agar orang berikutnya tidak perlu mencari sendiri atau bertanya: persistensi di sisi browser mendukung IndexedDB dan OPFS: <https://pglite.dev/docs/filesystems>

    • Pekerjaan Anda dan Roy pada WASM SQLite VFS berpengaruh langsung pada pekerjaan ini

  • Begitu melihat judulnya, saya langsung berpikir “ini pasti sangat cocok dengan ElectricSQL”, dan senang melihat ternyata ini memang berasal dari pihak ElectricSQL
    Pengalaman developer yang langsung terasa sangat bagus, dan saya ingin mencoba PGlite serta ElectricSQL dalam proyek produksi
    Sepertinya ini akan mengurangi banyak ketidaknyamanan yang saya alami sekarang, dan secara pribadi saya juga suka bekerja dengan CRDT

  • Selamat untuk Show HN
    Saya mengikuti server Discord ElectricSQL, dan terutama tertarik untuk memakainya dari bahasa selain TypeScript, jadi senang mendengar independensi bahasa dijadikan prioritas
    Saya melihat ElectricSQL sedang ditulis ulang karena perubahan arsitektur, jadi penasaran apakah itu memengaruhi PGlite, atau sekarang menjadi proyek terpisah
    Selain itu, SQLite sebenarnya adalah SQL-ite, yaitu termasuk keluarga -ite seperti urbanite, tetapi karena reanalisis dan libfixing, tampaknya sekarang orang-orang memakainya seperti sufiks -lite
    Mungkin karena makna lite lebih jelas, sedangkan ite tidak, mirip seperti helicopter yang awalnya helic + opter tetapi orang-orang memahaminya sebagai heli + copter, sehingga muncul kata seperti helipad atau quadcopter
    [0] https://en.wikipedia.org/wiki/Rebracketing
    [1] https://en.wikipedia.org/wiki/Libfix

    • PGlite dan Electric sync adalah proyek terpisah, tetapi kami sedang menjadikan PGlite sebagai target sinkronisasi Electric
      Perubahan di sisi Electric mengarah dari stack yang sebelumnya sangat terintegrasi ke stack yang lebih longgar keterkaitannya
      PGlite adalah salah satu penyimpanan klien yang memungkinkan untuk Electric sync, dan memenuhi use case yang menempatkan database SQL lengkap di klien serta memungkinkan skema yang sama dipakai di klien dan server
      Namanya tentu saja penghormatan untuk SQLite, dan huruf kecil l dimasukkan sebagai sedikit pembeda sekaligus isyarat ke “light”, serta mengandung makna Postgres yang ringan

  • Biasanya saya akan bilang perbedaan utama PostgreSQL dan SQLite adalah SQLite bersifat in-process, tetapi jika sekarang keduanya bisa in-process, saya penasaran apakah ada materi yang membandingkan keduanya lebih rinci
    Dalam situasi apa sebaiknya memilih yang satu dibanding yang lain?

    • SQLite sudah benar-benar lama teruji, tetapi setelah mencoba PGlite bahkan belum sampai 3 menit, saya menemui memory access out of bounds
      Sekalipun kakaknya, PostgreSQL, adalah salah satu database paling tangguh, mungkin ini belum bisa dianggap siap produksi
      Tentu saja saya juga pernah melihat dan mengalami masalah di SQLite, jadi tidak ada software yang bebas bug
    • Saya benar-benar ingin tahu perbandingan ini

  • Di side project terbaru, saya mencoba pglite untuk pengujian integrasi API, dan hasilnya cukup baik
    Pengalaman developernya jauh lebih baik dibanding memakai sesuatu seperti testcontainers[0] untuk menjalankan postgres di Docker
    [0]: https://testcontainers.com

    • Menurut saya unit test dan integration test adalah peluang yang sangat besar bagi PGlite
      Proyek seperti Drizzle ORM sudah memanfaatkannya dengan baik
      Tim Supabase membuat pg-gateway(https://github.com/supabase-community/pg-gateway), yang memungkinkan klien Postgres apa pun terhubung ke PGlite, sehingga bisa menjadi cara untuk dipakai di CI
      Yang ingin saya eksplorasi adalah VFS tingkat halaman dengan copy-on-write untuk PGlite
      Jika bisa memulai PGlite dengan dataset yang sudah dimasukkan lalu langsung mem-fork database untuk tiap test, tampaknya fork per test dalam waktu di bawah milidetik bisa dilakukan tanpa kerumitan devcontainers atau database template Postgres
    • Saya juga ingin memakainya seperti ini di Go
      Saat ini di layanan produksi kami memakai postgres, tetapi untuk integration test berbasis SQLite kami men-dump skema yang kompatibel dengan SQLite
      Berkat itu, kami bisa menjalankan integration test di bawah 1 detik tanpa dependensi, sambil tetap memakai database nyata
      Jika bisa memakai Postgres apa adanya, itu akan lebih baik karena fitur yang membutuhkan fitur khusus PG seperti full-text search juga bisa diuji

  • PGlite / ElectricSQL adalah teknologi yang benar-benar ingin saya coba di tempat kerja pada masa depan
    Kemampuan untuk mereplikasi dan berlangganan perubahan di dalam browser terlihat sangat kuat
    Dulu saya membuat software medis yang menangani workload lebih dari 2 juta pasien serta refill obat kemoterapi/HIV/imunologi, dan kasus orang saling menimpa pekerjaan satu sama lain saat memproses asuransi atau menelepon pasien itu umum terjadi
    Karena IE7, kami harus membuat sistem locking sendiri yang bergantung pada fungsi interval dan websocket, dan saat seseorang menelepon pasien, petugas bantuan finansial tidak bisa bekerja pada profil yang sama
    Full-text search atau vector search yang sangat mahal biayanya dalam skala besar juga tampaknya bisa dimanfaatkan secara lokal

    • Itu berarti menaruh data 2 juta pasien di semua perangkat
      Untuk software medis, itu pilihan yang sangat buruk

  • Saya penasaran apakah ada versi native yang mirip dengan ini
    Kalau nanti ingin membuat aplikasi native, saya berharap tidak perlu membuang seluruh arsitektur dan mulai lagi dari awal
    Di situs web dan dokumentasi, yang terlihat hanya versi WASM

    • Sudah direncanakan
      Kami ingin mengekstrak perubahan inti yang harus diterapkan pada Postgres dan membuat library C libpglite yang bisa ditautkan dari bahasa/platform apa pun
      React Native tidak memiliki dukungan WASM, jadi dukungan ini penting

  • Keren sekali ada live query API yang reaktif
    Sebagian besar contoh query reaktif sangat dasar, seperti satu tabel saja, jadi saya penasaran apakah live query juga mendukung join atau agregasi

    • Semuanya seharusnya berfungsi
      Query disimpan sebagai view, lalu bagian dalamnya diperiksa untuk melihat bergantung pada tabel mana saja
      Setelah itu pg_notify digunakan untuk memantau perubahan
      Untuk membuatnya lebih efisien, ada rencana mengintegrasikan pg_ivm(https://github.com/sraoss/pg_ivm)