Postgres แบบ WASM ที่รันในเบราว์เซอร์: PGlite

 (pglite.dev)
2 คะแนน โดย GN⁺ 2024-08-13 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในแอปแบบ local-first และสภาพแวดล้อมการพัฒนาบนเบราว์เซอร์ สามารถรัน Postgres ทั้งชุด เป็น WASM ได้โดยตรง ช่วยลดการพึ่งพาเซิร์ฟเวอร์
  • มาพร้อมบิลด์ขนาด ต่ำกว่า 3MB เมื่อบีบอัดแบบ Gzip จึงฝังลงในเบราว์เซอร์และสภาพแวดล้อมโลคัลได้ง่าย
  • รองรับ การโหลดส่วนขยายแบบไดนามิก ทำให้ใช้ส่วนขยายของ Postgres อย่าง pgvector และ PostGIS ได้
  • มี primitive สำหรับการโหลดข้อมูล, การซิงก์, และ live query ในตัว จึงเหมาะกับแอปแบบ reactive และกรณีใช้งานแบบเรียลไทม์
  • database.build ของ Supabase สร้างบน PGlite และมอบประสบการณ์การสร้างและเผยแพร่ฐานข้อมูล Postgres ด้วย AI

Postgres สำหรับใช้ในเบราว์เซอร์และบนเครื่องโลคัล

  • PGlite คือ Postgres แบบฝังตัวที่รันฐานข้อมูล Postgres เต็มรูปแบบบนโลคัลด้วย WASM
  • เป็นบิลด์ Postgres แบบ WASM เต็มรูปแบบ และมีขนาด ต่ำกว่า 3MB หลังบีบอัดด้วย Gzip
  • มี primitive สำหรับการโหลดข้อมูล, การซิงก์, และ live query ในตัว ทำให้สร้าง data flow แบบ reactive ที่เน้นฝั่งไคลเอนต์ได้

ส่วนขยายและสภาพแวดล้อมทดลอง

  • รองรับกลไก การโหลดส่วนขยายแบบไดนามิก
    • รวม pgvector
    • และสามารถใช้ PostGIS ได้ด้วย
  • สามารถทดลองส่วนขยายเพิ่มเติมได้ใน Playground
  • ในหน้านี้สามารถลองใช้ PGlite Postgres แบบเต็มที่รันในเบราว์เซอร์ได้ทันที และมี pgvector รวมอยู่ด้วย

เอกสารและช่องทางการเผยแพร่

  • ดูเอกสารเริ่มต้นใช้งานได้ที่ Get Started
  • GitHub แสดงดาว 15.5K
  • NPM แสดงยอดดาวน์โหลดรายสัปดาห์ 10.1M

database.build ของ Supabase

  • database.build คือบริการที่ Supabase สร้างขึ้นบน PGlite
  • มอบ workflow สำหรับ สร้างและเผยแพร่ฐานข้อมูล Postgres ด้วย AI

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-08-13
ความคิดเห็นจาก Hacker News

  • ก่อนหน้านี้เคยเห็นว่ามันรันในเบราว์เซอร์ได้ และประทับใจที่ใช้การดาวน์โหลดแค่ ประมาณ 3MB แต่ไม่ทันสังเกตว่ามันรันฝั่งเซิร์ฟเวอร์บน Node.js และ Bun ได้ด้วย: https://pglite.dev/docs/
    เพราะมันไม่ได้เปิดเน็ตเวิร์กเซิร์ฟเวอร์จริง ๆ เลยให้ความรู้สึกเหมือนเป็นทางเลือกแทน SQLite และก็น่าสนใจที่สามารถเปิดใช้ PostgreSQL แบบ in-process ที่พersist ลงดิสก์ได้ทันทีภายในแอป Node.js/Bun เดิม
    อยากลองใช้จาก Python ผ่านแรปเปอร์อย่าง https://github.com/wasmerio/wasmer-python หรือ https://github.com/bytecodealliance/wasmtime-py เช่นกัน เลยสงสัยว่ามีใครเคยรัน PGlite ด้วยวิธีแบบนี้แล้วบ้างไหม

    • การทำให้ PGlite ใช้งานได้ดีจากภาษาอื่นเป็นเรื่องที่มีลำดับความสำคัญสูงมาก
      ตอนนี้กำลังทำอยู่สองแนวทาง: แบบแรกคือ WASI build ของ low-level API ที่ผู้ใช้สามารถเอาไปครอบเป็น high-level API ได้ และอีกแบบคือ libpglite ที่ลิงก์จากภาษาเนทีฟได้
      ภาษาส่วนใหญ่มี implementation ของ Postgres wire protocol อยู่แล้ว จึงค่อนข้างง่ายที่จะครอบ low-level API ที่อ่านและส่งออกข้อมูลนี้ได้ และฝั่ง JS ของ PGlite ก็ทำงานแบบเดียวกัน
    • วิธีแก้ขัดชั่วคราวคือ ใน Python อาจเรียกสคริปต์ Node.js ผ่าน subprocess เพื่อรัน exec และ query ของ @electric-sql/pglite แล้วส่งผลลัพธ์ไปมาด้วย JSON
      โครงสร้างคือสร้างอินสแตนซ์ PGlite ใน db.js แล้วรับ SQL กับพารามิเตอร์จากอาร์กิวเมนต์บรรทัดคำสั่งเพื่อประมวลผล จากนั้น main.py ก็เรียก node db.js exec ... หรือ node db.js query ...
    • อยากลองใช้ PGlite จาก Python เหมือนกัน และพออ่านเธรดนี้ก็เพิ่งนึกได้ว่าใน Pyodide เข้าถึงได้อยู่แล้ว
      Pyodide คือพอร์ต Wasm ของ CPython และสามารถโต้ตอบกับอ็อบเจ็กต์ JavaScript ผ่านพร็อกซีได้
      ตัวอย่างคือสร้าง globalThis.db = new PGlite() แล้วจากโค้ด Python ใช้ await กับ js.db.query() เพื่อรัน SELECT 'Hello, world!' AS "greeting"; ซึ่งตอนนี้ใช้งานได้บน Node.js 18, Deno 1 และ Bun 1
    • อยากให้คนที่คุ้นกับเรื่องไลเซนส์มากกว่าช่วยอธิบายผลกระทบต่อ โปรเจกต์เชิงพาณิชย์ หรือโซลูชันต่าง ๆ และเทียบกับ embedded FirebirdSQL ว่าเป็นอย่างไร
      เช่น ใช้ในโปรเจกต์เชิงพาณิชย์โดยไม่เปิดซอร์สได้ไหม หรือถ้า embed แล้วต้องเปลี่ยนไลเซนส์ให้สอดคล้องกับ pg/fb หรือเปล่า
      ถ้าจำเป็นเดี๋ยวจะไปอ่านเอง แต่จุดที่ไม่ชอบความเรียบง่ายของ SQLite หลายอย่างก็ดันคล้ายกับสิ่งที่ไม่ชอบใน MySQL/MariaDB เลยทำให้อยากรู้ขึ้นมา
    • น่าสนใจว่ามันจะทำงานได้ดีแค่ไหนในโลกจริง
      ไม่แน่ใจว่าเขาปรับ ชั้น persistence ของ PostgreSQL อย่างไร แต่เมื่อเทียบกับการรัน PostgreSQL ใน Docker container ก็ดูเหมือนอาจมีข้อจำกัดอยู่บ้าง
      ส่วน SQLite ไม่มีข้อจำกัดแบบนั้น

  • ชอบ PGlite มากจริง ๆ
    มันเป็นทางออกที่สมบูรณ์แบบสำหรับการมี Postgres โดยไม่ต้องใช้ Docker และเพียง npm install ก็สร้าง Postgres instance บนเครื่องโลคัลได้ ทำให้การ onboard นักพัฒนาใหม่เข้าทีมง่ายมาก
    มันทำงานกับ Next.js ได้ดีด้วย และตอนนี้กำลังใช้ร่วมกับ Next.js Boilerplate ในสภาพแวดล้อมโลคัลและสำหรับพัฒนาอยู่: https://github.com/ixartz/Next-js-Boilerplate
    แค่ npm install ครั้งเดียวก็ได้แอปพลิเคชันฟูลสแตกที่รวมฐานข้อมูลมาด้วย กล่าวคือมี Postgres ที่ใช้งานได้เลย และไม่ต้องติดตั้งเครื่องมือภายนอก

    • ปกติผมจัดการ dependency สำหรับการพัฒนาด้วย docker compose แต่สิ่งนี้ก็ดูเป็นทางเลือกที่เจ๋งมากจริง ๆ

  • เผื่อคนถัดไปไม่ต้องไปค้นเองหรือถามเพิ่ม ฝั่ง persistence บนเบราว์เซอร์รองรับทั้ง IndexedDB และ OPFS: <https://pglite.dev/docs/filesystems>

    • งานของคุณกับ Roy เรื่อง WASM SQLite VFS มีอิทธิพลโดยตรงกับงานนี้

  • พอเห็นชื่อก็คิดทันทีว่า “อันนี้น่าจะเข้ากับ ElectricSQL มาก” และก็ดีที่เห็นว่ามาจากฝั่ง ElectricSQL จริง ๆ
    ประสบการณ์สำหรับนักพัฒนานั้นยอดเยี่ยมในทันที และอยากลองใช้ทั้ง PGlite และ ElectricSQL ในโปรเจกต์โปรดักชัน
    ดูเหมือนมันจะช่วยลดความยุ่งยากหลายอย่างที่กำลังเจออยู่ และส่วนตัวก็ชอบทำงานกับ CRDT ด้วย

  • ยินดีกับ Show HN
    ผมกำลังดูในเซิร์ฟเวอร์ Discord ของ ElectricSQL อยู่ และสนใจเป็นพิเศษกับการใช้งานจากภาษาอื่นที่ไม่ใช่ TypeScript เลยดีใจที่ให้ความสำคัญกับความเป็นอิสระจากภาษา
    เคยเห็นว่า ElectricSQL กำลังเขียนใหม่เพราะมีการเปลี่ยนสถาปัตยกรรม เลยสงสัยว่านั่นส่งผลกับ PGlite ด้วยไหม หรือว่าตอนนี้เป็นโปรเจกต์แยกกันแล้ว
    อีกอย่าง SQLite จริง ๆ แล้วคือ SQL-ite หรือกลุ่มคำลงท้ายแบบ -ite อย่างเช่น urbanite แต่เพราะการวิเคราะห์ใหม่และ libfixing ตอนนี้คนเลยดูเหมือนจะใช้มันเหมือนเป็นคำลงท้าย -lite
    อาจเป็นเพราะ 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
      การเปลี่ยนฝั่ง Electric กำลังมุ่งจากสแตกที่รวมแน่นมากในอดีต ไปสู่สแตกที่เชื่อมกันแบบหลวมขึ้น
      PGlite เป็นหนึ่งในตัวเลือกของ client storage สำหรับ Electric sync และตอบโจทย์กรณีใช้งานที่ต้องการฐานข้อมูล SQL เต็มรูปแบบบนไคลเอนต์ รวมถึงอาจใช้สคีมาเดียวกันทั้งฝั่งไคลเอนต์และเซิร์ฟเวอร์
      ชื่อนี้แน่นอนว่าเป็นการคารวะต่อ SQLite และใช้ l ตัวพิมพ์เล็กเพื่อสร้างความแตกต่างเล็กน้อยพร้อมสื่อถึง “light” ด้วย จึงมีความหมายประมาณว่าเป็น Postgres แบบเบา

  • ถ้าเป็นเมื่อก่อน ผมคงบอกว่าความต่างหลักระหว่าง PostgreSQL กับ SQLite คือ SQLite เป็นแบบ in-process แต่ถ้าตอนนี้ทั้งคู่ทำงานแบบ in-process ได้แล้ว ก็สงสัยว่ามีข้อมูลเปรียบเทียบเชิงลึกกว่านี้ไหม
    ในสถานการณ์แบบไหนควรเลือกอันหนึ่งมากกว่าอีกอัน?

    • SQLite ผ่านการพิสูจน์ตัวเองมานานมาก แต่ผมลอง PGlite ยังไม่ถึง 3 นาทีก็เจอ memory access out of bounds
      ถึงแม้ PostgreSQL รุ่นพี่จะเป็นหนึ่งในฐานข้อมูลที่แข็งแกร่งที่สุด แต่ก็คงยังยากจะบอกว่าพร้อมสำหรับ production แล้ว
      แน่นอนว่าผมก็เคยเห็นและเคยเจอปัญหาใน SQLite เหมือนกัน ดังนั้นซอฟต์แวร์ที่ไม่มีบั๊กไม่มีอยู่จริง
    • อยากรู้การเปรียบเทียบนี้จริง ๆ

  • ช่วงหลังผมลองใช้ pglite กับ การทดสอบ integration ของ API ใน side project แล้วพบว่ามันทำงานได้ค่อนข้างดี
    ประสบการณ์นักพัฒนาดีกว่าการใช้ testcontainers[0] หรืออะไรทำนองนั้นเพื่อยก postgres ขึ้นมาบน Docker มาก
    [0]: https://testcontainers.com

    • ผมมองว่าการทดสอบ unit และ integration เป็นโอกาสใหญ่มากของ PGlite
      โปรเจกต์อย่าง Drizzle ORM ก็ใช้งานมันได้ดีอยู่แล้ว
      ทีม Supabase สร้าง pg-gateway(https://github.com/supabase-community/pg-gateway) ซึ่งทำให้เชื่อมต่อกับ PGlite ได้จาก Postgres client ใด ๆ และอาจเป็นแนวทางสำหรับใช้ใน CI
      สิ่งที่อยากลองสำรวจคือ page-level VFS แบบ copy-on-write สำหรับ PGlite
      ถ้าสามารถเริ่ม PGlite พร้อมชุดข้อมูล แล้ว fork ฐานข้อมูลได้ทันทีสำหรับแต่ละเทสต์ ก็น่าจะทำให้ fork ต่อเทสต์ได้ในระดับต่ำกว่ามิลลิวินาที โดยไม่ต้องเจอกับความซับซ้อนของ devcontainers หรือ template database ของ Postgres
    • ผมก็อยากใช้แนวนี้ใน Go เหมือนกัน
      ตอนนี้ใน production ใช้ postgres แต่สำหรับ integration test ที่อิง SQLite ผม dump สคีมาที่เข้ากันได้กับ SQLite อยู่
      ด้วยวิธีนี้จึงทำ integration test แบบใช้ฐานข้อมูลจริงได้โดยไม่มี dependency และใช้เวลาไม่ถึง 1 วินาที
      ถ้าใช้ Postgres เดิมได้ตรง ๆ ก็คงยิ่งดี เพราะจะทดสอบฟีเจอร์ที่ต้องใช้ ความสามารถเฉพาะของ PG อย่าง full-text search ได้ด้วย

  • PGlite / ElectricSQL เป็นเทคโนโลยีที่ผมอยากใช้มากในที่ทำงานถัดไป
    ความสามารถในการ replicate และ subscribe การเปลี่ยนแปลงภายในเบราว์เซอร์ดูทรงพลังมาก
    ก่อนหน้านี้ผมเคยทำ ซอฟต์แวร์ทางการแพทย์ ที่รองรับเวิร์กโหลดของผู้ป่วยมากกว่า 2 ล้านคน พร้อมงาน refill ยาเคมีบำบัด/HIV/ภูมิคุ้มกัน และการเขียนทับงานกันระหว่างขั้นตอนประกันหรือระหว่างคุยกับผู้ป่วยเกิดขึ้นบ่อยมาก
    เพราะ IE7 เราต้องสร้างระบบล็อกของตัวเองที่พึ่งพา interval function และ WebSocket และระหว่างที่มีคนโทรหาผู้ป่วย เจ้าหน้าที่ฝ่ายช่วยเหลือการเงินก็ไม่สามารถทำงานในโปรไฟล์เดียวกันได้
    ดูเหมือนว่าฟีเจอร์อย่าง full-text search หรือ vector search ซึ่งมีต้นทุนสูงมากเมื่อทำในสเกลใหญ่ ก็อาจนำมาใช้แบบโลคัลได้เช่นกัน

    • นั่นหมายถึงจะเอาข้อมูลผู้ป่วย 2 ล้านคนไปไว้บนทุกอุปกรณ์
      สำหรับซอฟต์แวร์ทางการแพทย์ นี่เป็นตัวเลือกที่แย่มาก

  • สงสัยว่ามี เวอร์ชันเนทีฟ ที่คล้ายกันไหม
    เผื่อภายหลังอยากทำแอปเนทีฟ จะได้ไม่ต้องทิ้งสถาปัตยกรรมทั้งหมดแล้วเริ่มใหม่
    ในเว็บไซต์และเอกสารเห็นแต่เวอร์ชัน WASM

    • มีแผนอยู่
      เราอยากดึงการเปลี่ยนแปลงแกนหลักที่ต้องทำกับ Postgres ออกมา แล้วสร้างไลบรารี C ชื่อ libpglite ที่ลิงก์ได้จากทุกภาษา/แพลตฟอร์ม
      React Native ยังไม่รองรับ WASM ดังนั้นการรองรับนี้จึงสำคัญ

  • การมี live query API แบบ reactive นี่เจ๋งมาก
    ตัวอย่าง reactive query ส่วนใหญ่พื้นฐานมากเหมือนมีแค่ตารางเดียว เลยสงสัยว่า live query รองรับ join หรือ aggregate ด้วยไหม

    • ทุกอย่างน่าจะทำงานได้
      เราจะบันทึกคิวรีเป็น view แล้วตรวจดูภายในว่ามันพึ่งพาตารางใดบ้าง
      จากนั้นใช้ pg_notify เพื่อติดตามการเปลี่ยนแปลง
      และมีแผนจะรวม pg_ivm(https://github.com/sraoss/pg_ivm) เพื่อให้มีประสิทธิภาพยิ่งขึ้น