ब्राउज़र के अंदर चलने वाला WASM Postgres, PGlite

 (pglite.dev)
2 पॉइंट द्वारा GN⁺ 2024-08-13 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • लोकल-फर्स्ट ऐप्स और ब्राउज़र-आधारित डेवलपमेंट environments में पूरा Postgres सीधे WASM में चला सकते हैं, जिससे server dependency घट सकती है
  • Gzip के हिसाब से 3MB से कम build के रूप में उपलब्ध है, इसलिए इसे ब्राउज़र और लोकल environments में embed करना आसान है
  • dynamic extension loading के जरिए pgvector और PostGIS जैसे Postgres extensions इस्तेमाल किए जा सकते हैं
  • data loading, sync और live query primitives built-in हैं, जिससे यह responsive apps और real-time use cases के लिए उपयुक्त है
  • Supabase का database.build, PGlite पर आधारित होकर AI की मदद से Postgres database बनाने और publish करने का अनुभव देता है

ब्राउज़र और लोकल में इस्तेमाल होने वाला Postgres

  • PGlite WASM में पूरा Postgres database लोकल रूप से चलाने वाला embedded Postgres है
  • यह पूरा Postgres WASM build है और Gzip compression के हिसाब से 3MB से कम में उपलब्ध है
  • data loading, sync और live query primitives built-in हैं, जिससे client-centric responsive data flows बनाए जा सकते हैं

Extensions और experimentation environment

  • dynamic extension loading mechanism को support करता है
    • pgvector शामिल है
    • PostGIS भी इस्तेमाल किया जा सकता है
  • Playground में और extensions आज़माए जा सकते हैं
  • मौजूदा page पर ब्राउज़र के अंदर चलने वाला पूरा PGlite Postgres तुरंत आज़माया जा सकता है, और इसमें pgvector भी शामिल है

Documentation और distribution channels

  • Get Started में शुरुआती documentation देख सकते हैं
  • GitHub पर 15.5K stars दिखते हैं
  • NPM पर weekly downloads 10.1M दिखते हैं

Supabase का database.build

  • database.build Supabase द्वारा PGlite के आधार पर बनाई गई service है
  • AI से Postgres database generate और publish करने वाला flow प्रदान करता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-08-13
Hacker News टिप्पणियां

  • पहले इसे ब्राउज़र में चलते देखा था और यह बात प्रभावशाली लगी थी कि यह लगभग 3MB डाउनलोड से ही संभव है, लेकिन यह बात छूट गई थी कि यह Node.js और Bun के server-side पर भी चलता है: https://pglite.dev/docs/
    यह असली network server नहीं चलाता, इसलिए यह SQLite के विकल्प जैसा लगता है, और यह दिलचस्प है कि मौजूदा Node.js/Bun ऐप के अंदर डिस्क पर persist होने वाला in-process PostgreSQL implementation सीधे शुरू किया जा सकता है
    Python में भी https://github.com/wasmerio/wasmer-python या https://github.com/bytecodealliance/wasmtime-py जैसे wrappers के साथ इसे आज़माना चाहूंगा, लेकिन जिज्ञासा है कि क्या किसी ने PGlite को पहले से इस तरह चलाकर देखा है

    • PGlite को दूसरी languages में अच्छी तरह काम कराने को बहुत ऊंची प्राथमिकता दी गई है
      दो approaches पर काम चल रहा है: एक low-level API का WASI build, जिसे users high-level API से wrap कर सकें, और दूसरा libpglite, जिसे native languages में link किया जा सके
      ज्यादातर languages में पहले से Postgres wire protocol implementations मौजूद हैं, इसलिए इसे पढ़ने और emit करने वाले low-level API को wrap करना अपेक्षाकृत आसान है, और PGlite का JS side भी इसी तरह काम करता है
    • अस्थायी उपाय के तौर पर Python से subprocess के जरिए Node.js script call करके @electric-sql/pglite के exec और query चलाना, और results को JSON के रूप में भेजना-लेना संभव लगता है
      Structure ऐसा होगा कि db.js में PGlite instance बनाया जाए, command-line arguments के रूप में SQL और parameters लेकर process किया जाए, और फिर main.py से node db.js exec ... या node db.js query ... call किया जाए
    • Python में भी PGlite आज़माना चाहता था, और यह thread पढ़ते हुए समझ आया कि Pyodide में यह पहले से accessible है
      Pyodide, CPython का Wasm port है और proxy के जरिए JavaScript objects के साथ interact कर सकता है
      उदाहरण में globalThis.db = new PGlite() बनाकर Python code से js.db.query() को await किया गया और SELECT 'Hello, world!' AS "greeting"; चलाया गया; फिलहाल यह Node.js 18, Deno 1, Bun 1 में काम कर चुका है
    • अगर licensing से ज्यादा परिचित कोई व्यक्ति यह समझा सके कि इसका commercial projects या solutions पर क्या असर होगा, और embedded FirebirdSQL जैसी चीज़ों से इसकी तुलना कैसी है, तो अच्छा होगा
      उदाहरण के लिए, क्या इसे source खोले बिना commercial project में इस्तेमाल किया जा सकता है, और embed करने पर क्या license को pg/fb के हिसाब से बदलना होगा—यह जानना चाहता हूं
      तुरंत जरूरत पड़ी तो खुद review कर लूंगा, लेकिन SQLite की simplicity में जो बातें पसंद नहीं आतीं, वे MySQL/MariaDB में नापसंद बातों से काफी मिलती-जुलती हैं, इसलिए जिज्ञासा हुई
    • यह असल में कितना अच्छा काम करेगा, यह देखना दिलचस्प होगा
      PostgreSQL की persistence layer को कैसे modify किया गया है, यह नहीं पता, लेकिन Docker container में PostgreSQL चलाने की तुलना में इसमें कुछ limitations हो सकती हैं
      SQLite में ऐसी limitations नहीं हैं

  • PGlite सच में पसंद है
    Docker के बिना Postgres पाने का यह perfect solution है, और सिर्फ npm install से local computer पर Postgres instance बनाया जा सकता है, जिससे नए developers को team में onboard करना बहुत आसान हो जाता है
    Next.js के साथ भी यह अच्छी तरह काम करता है, और local तथा development environment में Next.js Boilerplate के साथ इसका इस्तेमाल कर रहा हूं: https://github.com/ixartz/Next-js-Boilerplate
    एक बार npm install करने पर database समेत full-stack application—यानी चलता हुआ Postgres—तैयार हो जाता है और कोई external tool install करने की जरूरत नहीं रहती

    • आम तौर पर development dependencies को docker compose से handle करता हूं, लेकिन यह निश्चित रूप से शानदार alternative दिखता है

  • ताकि अगले व्यक्ति को खुद खोजने या पूछने की जरूरत न पड़े, browser-side persistence IndexedDB और OPFS को support करता है: <https://pglite.dev/docs/filesystems>

    • WASM SQLite VFS पर आपके और Roy के काम ने इस काम को सीधे प्रभावित किया है

  • Title देखते ही सोचा था, “यह ElectricSQL के साथ वाकई खूब जमेगा,” और यह देखकर अच्छा लगा कि यह सच में ElectricSQL की तरफ से आया है
    Instant developer experience शानदार है, और production project में PGlite और ElectricSQL आज़माना चाहता हूं
    लगता है यह अभी झेली जा रही कई परेशानियां कम कर देगा, और व्यक्तिगत रूप से मुझे CRDT के साथ काम करना भी पसंद है

  • Show HN के लिए बधाई
    मैं ElectricSQL Discord सर्वर देख रहा था, और खास तौर पर TypeScript के अलावा दूसरी भाषाओं में इस्तेमाल को लेकर दिलचस्पी थी, इसलिए यह जानकर अच्छा लगा कि भाषा-स्वतंत्रता को प्राथमिकता दी जा रही है
    मैंने देखा था कि आर्किटेक्चर बदलावों की वजह से ElectricSQL को फिर से लिखा जा रहा है; सोच रहा हूँ कि क्या इसका PGlite पर असर पड़ेगा, या अब यह एक अलग प्रोजेक्ट है
    साथ ही SQLite असल में SQL-ite है, यानी urbanite जैसे -ite परिवार का, लेकिन reanalysis और libfixing की वजह से अब लोग इसे -lite suffix की तरह इस्तेमाल करते दिखते हैं
    शायद इसलिए कि lite का अर्थ ज़्यादा साफ है, जबकि ite का नहीं; यह कुछ-कुछ वैसा ही है जैसे helicopter मूल रूप से helic + opter था, लेकिन लोगों ने उसे heli + copter समझा और helipad या quadcopter जैसे शब्द बने
    [0] https://en.wikipedia.org/wiki/Rebracketing
    [1] https://en.wikipedia.org/wiki/Libfix

    • PGlite और Electric sync अलग-अलग प्रोजेक्ट हैं, लेकिन हम PGlite को Electric का sync target बना रहे हैं
      Electric में बदलाव पुराने, बहुत कसकर integrated stack से ज़्यादा loosely coupled stack की दिशा में हैं
      PGlite, Electric sync के संभावित client stores में से एक है, और यह उस use case को पूरा करता है जिसमें client पर पूरी SQL database होती है और client व server पर वही schema भी इस्तेमाल किया जा सकता है
      नाम जाहिर तौर पर SQLite को homage है, और lowercase l थोड़ा अंतर दिखाने और “light” की ओर इशारा करने के लिए रखा गया है; इसमें हल्के Postgres का अर्थ भी शामिल है

  • पहले मैं कहता कि PostgreSQL और SQLite के बीच मुख्य अंतर यह है कि SQLite in-process है, लेकिन अब अगर दोनों in-process हो सकते हैं, तो सोच रहा हूँ कि क्या दोनों की और विस्तृत तुलना करने वाला कोई material है
    किन हालात में एक को दूसरे पर तरजीह देनी चाहिए?

    • SQLite सच में बहुत लंबे समय से battle-tested है, लेकिन PGlite को 3 मिनट भी न छूने पर मुझे memory access out of bounds मिल गया
      भले ही इसका बड़ा भाई PostgreSQL सबसे मजबूत databases में से एक है, इसे अभी production-ready मानना मुश्किल हो सकता है
      बेशक मैंने SQLite में भी समस्याएँ देखी और झेली हैं, इसलिए bug-free software जैसी कोई चीज़ नहीं होती
    • यह comparison मैं सच में जानना चाहता हूँ

  • हाल के एक side project में मैंने API integration tests के लिए pglite इस्तेमाल किया, और यह काफी अच्छा चला
    Docker में postgres चलाने के लिए testcontainers[0] जैसी चीज़ इस्तेमाल करने की तुलना में developer experience कहीं बेहतर था
    [0]: https://testcontainers.com

    • Unit tests और integration tests PGlite के लिए बहुत बड़ा अवसर लगते हैं
      Drizzle ORM जैसे projects पहले से इसका अच्छा इस्तेमाल कर रहे हैं
      Supabase टीम ने pg-gateway(https://github.com/supabase-community/pg-gateway) बनाया है, जिससे किसी भी Postgres client से PGlite से connect किया जा सकता है; यह CI में इस्तेमाल का तरीका हो सकता है
      जिसे मैं explore करना चाहता हूँ, वह PGlite के लिए copy-on-write page-level VFS है
      अगर dataset लोड किए हुए PGlite को start करने के बाद हर test के लिए database को तुरंत fork किया जा सके, तो devcontainers या Postgres template databases की complexity के बिना हर test के लिए sub-millisecond fork संभव लगते हैं
    • Go में भी इसे इसी तरह इस्तेमाल करना चाहूँगा
      अभी production में postgres इस्तेमाल करते हैं, लेकिन SQLite-based integration tests के लिए SQLite-compatible schema dump कर रहे हैं
      इसकी वजह से असली database इस्तेमाल करते हुए भी dependency-free sub-1-second integration tests मिल जाते हैं
      अगर सीधे Postgres इस्तेमाल कर सकें, तो full text search जैसे PG-only features की जरूरत वाले features भी test कर पाएँगे, जो और बेहतर होगा

  • PGlite / ElectricSQL ऐसी technologies हैं जिन्हें मैं भविष्य की job में जरूर आज़माना चाहूँगा
    browser के अंदर changes को replicate और subscribe कर पाने की क्षमता बहुत powerful लगती है
    पहले मैंने 20 लाख से ज़्यादा मरीजों के workload को संभालने वाला healthcare software बनाया था, जिसमें chemotherapy/HIV/immune-related दवाओं के refills किए जाते थे; insurance processing या patient calls के दौरान एक-दूसरे का काम overwrite हो जाना आम बात थी
    IE7 की वजह से हमें interval functions और websockets पर निर्भर अपना locking system बनाना पड़ा था, और जब कोई patient को call कर रहा होता था, तो financial assistance specialist उसी profile पर काम नहीं कर सकता था
    large scale पर बहुत महंगे full text search या vector search को भी शायद locally इस्तेमाल किया जा सकता है

    • इसका मतलब है कि 20 लाख मरीजों का data हर device पर रखा जाएगा
      healthcare software के लिए यह बहुत खराब choice है

  • सोच रहा हूँ कि क्या इसका कोई मिलता-जुलता native version है
    अगर बाद में native app बनाना चाहूँ, तो ऐसा हो कि पूरा architecture फेंककर फिर से शुरू न करना पड़े
    website और docs में सिर्फ WASM version दिखता है

    • planning में है
      हम Postgres में करने पड़े core changes को extract करके libpglite नाम की C library बनाना चाहते हैं, जिसे किसी भी भाषा/platform से link किया जा सके
      React Native में WASM support नहीं है, इसलिए यह support महत्वपूर्ण है

  • reactive live query API होना बहुत शानदार है
    reactive query examples ज़्यादातर single table जैसी बहुत basic चीज़ें हैं, इसलिए सोच रहा हूँ कि क्या live query joins या aggregates भी support करती है

    • सब काम करना चाहिए
      query को view के रूप में store करते हैं, फिर अंदर देखकर पता लगाते हैं कि यह किन tables पर depend करती है
      इसके बाद changes पर नज़र रखने के लिए pg_notify इस्तेमाल करते हैं
      इसे ज़्यादा efficient बनाने के लिए pg_ivm(https://github.com/sraoss/pg_ivm) को integrate करने की योजना है