2 điểm bởi GN⁺ 2024-08-13 | 1 bình luận | Chia sẻ qua WhatsApp
  • Trong các ứng dụng ưu tiên cục bộ và môi trường phát triển dựa trên trình duyệt, có thể chạy toàn bộ Postgres trực tiếp bằng WASM để giảm phụ thuộc vào máy chủ
  • Được cung cấp dưới dạng bản dựng dưới 3MB theo chuẩn Gzip nên dễ nhúng vào môi trường trình duyệt và cục bộ
  • Có thể sử dụng các tiện ích mở rộng Postgres như pgvector và PostGIS thông qua tải tiện ích mở rộng động
  • Tích hợp sẵn các primitive cho nạp dữ liệu, đồng bộ hóa và live query, phù hợp với ứng dụng phản ứng và các trường hợp sử dụng thời gian thực
  • database.build của Supabase dựa trên PGlite mang lại trải nghiệm tạo và xuất bản cơ sở dữ liệu Postgres bằng AI

Postgres dùng trong trình duyệt và môi trường cục bộ

  • PGlite là Postgres nhúng chạy toàn bộ cơ sở dữ liệu Postgres cục bộ trên WASM
  • Đây là bản dựng Postgres WASM hoàn chỉnh nhưng có kích thước dưới 3MB sau khi nén Gzip
  • Tích hợp sẵn các primitive cho nạp dữ liệu, đồng bộ hóa và live query để xây dựng luồng dữ liệu phản ứng lấy client làm trung tâm

Tiện ích mở rộng và môi trường thử nghiệm

  • Hỗ trợ cơ chế tải tiện ích mở rộng động
    • Bao gồm pgvector
    • Cũng có thể dùng PostGIS
  • Có thể thử thêm nhiều tiện ích mở rộng trong Playground
  • Ngay trên trang hiện tại, bạn có thể thử trực tiếp PGlite Postgres đầy đủ chạy trong trình duyệt, bao gồm cả pgvector

Tài liệu và kênh phân phối

  • Có thể xem tài liệu bắt đầu tại Get Started
  • GitHub hiển thị 15.5K sao
  • NPM hiển thị 10.1M lượt tải mỗi tuần

database.build của Supabase

  • database.build là dịch vụ do Supabase xây dựng dựa trên PGlite
  • Cung cấp quy trình tạo và xuất bản cơ sở dữ liệu Postgres bằng AI

1 bình luận

 
GN⁺ 2024-08-13
Các ý kiến trên Hacker News
  • Trước đây tôi đã thấy nó chạy trong trình duyệt và rất ấn tượng vì chỉ cần tải xuống khoảng 3MB, nhưng tôi đã bỏ lỡ việc nó cũng chạy được ở phía máy chủ với Node.js và Bun: https://pglite.dev/docs/
    Vì nó không dựng một máy chủ mạng thực sự nên cảm giác giống như một lựa chọn thay thế cho SQLite, và điểm thú vị là có thể khởi chạy ngay một triển khai PostgreSQL in-process được lưu bền vững trên đĩa bên trong ứng dụng Node.js/Bun hiện có
    Tôi cũng muốn thử dùng trong Python thông qua các wrapper như https://github.com/wasmerio/wasmer-python hoặc https://github.com/bytecodealliance/wasmtime-py, và tò mò không biết đã có ai chạy PGlite theo cách này chưa

    • Việc làm cho PGlite hoạt động tốt trong các ngôn ngữ khác là ưu tiên rất cao
      Chúng tôi đang triển khai hai hướng tiếp cận: một là bản build WASI của API cấp thấp để người dùng có thể bọc bằng API cấp cao, và hai là libpglite có thể liên kết từ các ngôn ngữ native
      Hầu hết các ngôn ngữ đã có sẵn triển khai giao thức wire của Postgres, nên việc bọc API cấp thấp đọc và xuất giao thức này là tương đối dễ, và phía JS của PGlite cũng hoạt động theo cùng cách
    • Như một giải pháp tạm thời, có vẻ có thể gọi một script Node.js bằng subprocess trong Python để chạy execquery của @electric-sql/pglite, rồi trao đổi kết quả bằng JSON
      Cấu trúc là tạo một instance PGlite trong db.js, nhận SQL và tham số qua đối số dòng lệnh để xử lý, sau đó trong main.py gọi node db.js exec ... hoặc node db.js query ...
    • Tôi cũng muốn dùng thử PGlite trong Python, và khi đọc thread này mới nhận ra rằng trong Pyodide thì đã có thể truy cập được
      Pyodide là bản port Wasm của CPython và có thể tương tác với các đối tượng JavaScript thông qua proxy
      Trong ví dụ, sau khi tạo globalThis.db = new PGlite(), mã Python await js.db.query() để chạy SELECT 'Hello, world!' AS "greeting";, và hiện đã hoạt động trên Node.js 18, Deno 1, Bun 1
    • Sẽ rất tốt nếu ai đó rành hơn về giấy phép có thể giải thích nó ảnh hưởng thế nào tới dự án thương mại hoặc giải pháp thương mại, và so với những thứ như embedded FirebirdSQL thì ra sao
      Ví dụ, tôi muốn biết liệu có thể dùng trong dự án thương mại mà không công khai mã nguồn hay không, và nếu nhúng vào thì có phải đổi giấy phép cho phù hợp với pg/fb hay không
      Nếu cần ngay thì tôi sẽ tự xem xét, nhưng tôi tò mò vì những điểm tôi không thích ở sự đơn giản của SQLite khá giống với những điểm tôi ghét ở MySQL/MariaDB
    • Rất tò mò thực tế nó sẽ hoạt động tốt đến mức nào
      Tôi không biết họ đã sửa đổi lớp lưu bền vững của PostgreSQL như thế nào, nhưng so với việc chạy PostgreSQL trong container Docker thì có vẻ có thể có hạn chế
      SQLite thì không có những hạn chế như vậy
  • Tôi thực sự thích PGlite
    Đây là giải pháp hoàn hảo để có Postgres mà không cần Docker, và chỉ với npm install là có thể tạo một instance Postgres trên máy local, giúp onboarding lập trình viên mới vào team rất dễ dàng
    Nó cũng hoạt động tốt với Next.js, và tôi đang dùng cùng Next.js Boilerplate trong môi trường local và dev: https://github.com/ixartz/Next-js-Boilerplate
    Chỉ cần một lần npm install là có một ứng dụng full-stack bao gồm cả database, tức là có sẵn Postgres hoạt động, không cần cài công cụ bên ngoài

    • Thông thường tôi xử lý các dependency phát triển bằng docker compose, nhưng đây chắc chắn có vẻ là một lựa chọn thay thế rất hay
  • Ghi lại để người sau không phải tự tìm hoặc hỏi: lưu bền vững phía trình duyệt hỗ trợ IndexedDBOPFS: <https://pglite.dev/docs/filesystems>

    • Công việc của bạn và Roy về WASM SQLite VFS đã ảnh hưởng trực tiếp tới việc này
  • Ngay khi nhìn thấy tiêu đề, tôi đã nghĩ “cái này chắc ElectricSQL sẽ rất hợp”, nên thật vui khi thấy nó thực sự đến từ phía ElectricSQL
    Trải nghiệm lập trình viên tức thì rất tuyệt, và tôi muốn thử dùng PGlite cùng ElectricSQL trong một dự án production
    Có vẻ nó sẽ giảm bớt nhiều bất tiện hiện tại, và cá nhân tôi cũng thích làm việc với CRDT

  • Chúc mừng Show HN
    Tôi đang theo dõi máy chủ Discord của ElectricSQL và đặc biệt quan tâm đến việc dùng nó từ các ngôn ngữ khác ngoài TypeScript, nên rất vui khi nghe nói các bạn đang ưu tiên tính độc lập về ngôn ngữ
    Tôi thấy ElectricSQL đang được viết lại vì thay đổi kiến trúc, nên tò mò không biết điều đó có ảnh hưởng đến PGlite không, hay giờ nó đã là một dự án riêng
    Ngoài ra, SQLite thực ra là SQL-ite, tức cùng họ hậu tố -ite như urbanite, nhưng do tái phân tích và libfixing, có vẻ giờ mọi người dùng nó như hậu tố -lite
    Có thể vì lite có nghĩa rõ ràng hơn còn ite thì không, giống như helicopter vốn là helic + opter nhưng mọi người hiểu thành heli + copter, dẫn đến các từ như helipad hay quadcopter
    [0] https://en.wikipedia.org/wiki/Rebracketing
    [1] https://en.wikipedia.org/wiki/Libfix

    • PGlite và Electric sync là các dự án riêng, nhưng chúng tôi đang biến PGlite thành một mục tiêu đồng bộ của Electric
      Các thay đổi phía Electric đi theo hướng chuyển từ stack tích hợp chặt trước đây sang một stack liên kết lỏng hơn
      PGlite là một trong các kho lưu trữ client khả dĩ của Electric sync, đáp ứng use case đặt một cơ sở dữ liệu SQL đầy đủ ở client và thậm chí có thể dùng cùng schema ở client và server
      Tên gọi tất nhiên là một lời tri ân SQLite; chữ l viết thường được thêm vào để tạo chút khác biệt và gợi đến “light”, đồng thời cũng mang nghĩa một Postgres nhẹ
  • Trước đây tôi sẽ nói khác biệt chính giữa PostgreSQL và SQLite là SQLite chạy trong tiến trình, nhưng nếu giờ cả hai đều có thể chạy trong tiến trình thì tôi tò mò liệu có tài liệu nào so sánh hai bên chi tiết hơn không
    Trong tình huống nào nên ưu tiên cái này hơn cái kia?

    • SQLite đã được kiểm chứng trong thời gian rất dài, còn PGlite thì tôi mới nghịch chưa đến 3 phút đã gặp memory access out of bounds
      Dù người anh lớn PostgreSQL là một trong những cơ sở dữ liệu vững chắc nhất, có thể vẫn khó coi PGlite là đã sẵn sàng cho production
      Tất nhiên tôi cũng từng thấy và gặp vấn đề với SQLite, nên không có phần mềm nào là không có lỗi
    • Tôi thật sự muốn biết so sánh này
  • Gần đây tôi đã dùng pglite cho kiểm thử tích hợp API trong một side project và nó hoạt động khá tốt
    Trải nghiệm phát triển tốt hơn nhiều so với dùng những thứ như testcontainers[0] để chạy postgres trong Docker
    [0]: https://testcontainers.com

    • Tôi nghĩ unit test và integration test là cơ hội rất lớn cho PGlite
      Những dự án như Drizzle ORM đã tận dụng nó tốt
      Nhóm Supabase đã tạo pg-gateway(https://github.com/supabase-community/pg-gateway), nhờ đó bất kỳ client Postgres nào cũng có thể kết nối tới PGlite, và đây có thể là một cách dùng trong CI
      Điều tôi muốn khám phá là VFS cấp trang copy-on-write cho PGlite
      Nếu có thể khởi động PGlite với một dataset đã nạp rồi fork cơ sở dữ liệu tức thì cho mỗi test, ta có thể có fork dưới mili-giây cho từng test mà không cần sự phức tạp của devcontainers hay cơ sở dữ liệu template của Postgres
    • Tôi cũng muốn dùng kiểu này trong Go
      Hiện tại production dùng postgres, nhưng để kiểm thử tích hợp dựa trên SQLite, chúng tôi dump schema tương thích SQLite
      Nhờ vậy có thể kiểm thử tích hợp dưới 1 giây, không cần dependency, trong khi vẫn dùng cơ sở dữ liệu thật
      Nếu có thể dùng nguyên Postgres thì còn tốt hơn, vì có thể test cả các tính năng cần tính năng riêng của PG như tìm kiếm toàn văn bản
  • PGlite / ElectricSQL là công nghệ tôi rất muốn thử ở nơi làm việc trong tương lai
    Khả năng sao chép và subscribe các thay đổi ngay trong trình duyệt trông cực kỳ mạnh mẽ
    Trước đây tôi từng xây dựng phần mềm y tế xử lý workload cho hơn 2 triệu bệnh nhân, thực hiện nạp lại thuốc hóa trị/HIV/miễn dịch; việc trong lúc xử lý bảo hiểm hoặc gọi điện cho bệnh nhân mà người này ghi đè công việc của người kia là chuyện thường gặp
    Vì IE7, chúng tôi phải tự tạo hệ thống khóa dựa vào hàm interval và WebSocket; trong lúc ai đó gọi cho bệnh nhân thì nhân viên hỗ trợ tài chính không thể làm việc trên cùng hồ sơ
    Có vẻ cũng có thể tận dụng cục bộ tìm kiếm toàn văn bản hoặc tìm kiếm vector, vốn rất tốn kém ở quy mô lớn

    • Điều đó nghĩa là đưa dữ liệu của 2 triệu bệnh nhân lên mọi thiết bị
      Với phần mềm y tế thì đây là một lựa chọn rất tệ
  • Tôi tò mò liệu có phiên bản native tương tự không
    Nếu sau này muốn làm ứng dụng native, tôi hy vọng không phải vứt bỏ toàn bộ kiến trúc để bắt đầu lại
    Trên website và tài liệu tôi chỉ thấy bản WASM

    • Đã có trong kế hoạch
      Chúng tôi muốn trích xuất các thay đổi cốt lõi đã phải áp dụng cho Postgres để tạo một thư viện C libpglite có thể link từ bất kỳ ngôn ngữ/nền tảng nào
      React Native không hỗ trợ WASM nên phần hỗ trợ này rất quan trọng
  • Có API live query phản ứng thì rất tuyệt
    Hầu hết ví dụ về truy vấn phản ứng đều rất cơ bản, như một bảng đơn; tôi tò mò live query có hỗ trợ join hay aggregate không

    • Tất cả đều nên hoạt động
      Chúng tôi lưu truy vấn dưới dạng view, rồi nhìn vào bên trong để xem nó phụ thuộc vào những bảng nào
      Sau đó dùng pg_notify để theo dõi thay đổi
      Chúng tôi dự định tích hợp pg_ivm(https://github.com/sraoss/pg_ivm) để làm việc này hiệu quả hơn