database.build：把 Postgres 塞進瀏覽器分頁的沙盒，以及它換來的那組代價
In-browser Postgres sandbox with AI assistance (formerly postgres.new)
秒懂
- 它是什麼？
- 這個專案用 PGlite 在瀏覽器裡跑 WASM 版 Postgres，資料落在 IndexedDB，每個資料庫再配一個 LLM。判斷重點不在它跑得多快，而在無伺服器架構帶來的三個具體限制：沒有 pg_stat_statements、沒有 pgvector、沒有 pg_cron。
- 適合誰用？
- database.build 適合兩種人：一是需要可拋棄 Postgres 環境做 schema 草稿、CSV 匯入與關聯圖的開發者，二是想替 LLM 提供安全 SQL 執行環境的團隊，因為查詢不出瀏覽器。不適合需要 pgvector、pg_cron 或 pg_stat_statements 的工作，也不適合把資料庫當長期唯一副本的人：資料在 IndexedDB，清掉瀏覽器資料就沒了。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 104 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的不是「跑 Postgres」，而是「開一個用完就丟的 Postgres」
在一般流程裡，取得一個可寫的 Postgres 需要容器、連線字串、清理步驟。用完之後那個執行個體還留在雲端帳號裡，佔著配額。database.build 把這件事壓縮成開一個分頁：README 寫著可以「instantly spin up an unlimited number of Postgres databases that run directly in your browser」，每個資料庫都是一個獨立的 PGlite 實例。
目標使用者因此分成兩類。第一類是需要臨時環境驗證 DDL 或資料形狀的人，例如要確認某個 JOIN 寫法、要先看 CSV 匯入後的欄位型別。第二類是想讓 LLM 直接操作資料庫的人：README 列出的用例包括拖放 CSV 匯入並即時生成資料表、產生並匯出報表、產生圖表、建資料庫關聯圖。這些用例的共同點是「資料留在本機」，查詢不需要送到遠端 Postgres。
專案原本叫 postgres.new，README 特別解釋改名原因：這不是官方 Postgres 專案，不想誤導使用者，而 database.build 描述的就是它實際做的事。這個說明本身也劃出了邊界，它不是 Postgres 的替代發行版，而是一個以 Postgres 為核心的瀏覽器沙盒。
PGlite 加 IndexedDB：資料流從頭到尾沒有離開分頁
README 對機制的描述很直接：所有查詢都在瀏覽器執行，沒有遠端 Postgres 容器，也沒有 WebSocket 代理。底層是 PGlite，一個編譯成 WASM 的 Postgres，每個新建資料庫都會啟動一個新的 PGlite 實例，並對外提供功能完整的 Postgres。持久化靠 IndexedDB，重新整理頁面後變更仍在。
這條資料流值得拆開看。SQL 在瀏覽器的 WASM 執行環境裡被解析與執行，結果直接回到頁面，中間沒有網路往返。IndexedDB 扮演的是儲存層，不是快取層，所以「重新整理後資料還在」和「資料只存在這台機器上」是同一件事的兩面。README 沒有承諾任何跨裝置同步。
repo 是 monorepo，切成三個應用。apps/web 是 Next.js 主應用。apps/browser-proxy 用 pg-gateway 加 WebSocket，把 Postgres 的 TCP 連線代理回瀏覽器，這是讓外部工具以為自己在連一台普通 Postgres 的關鍵一層。apps/deploy-worker 負責把瀏覽器內的資料庫部署到資料庫平台，README 註明目前支援 Supabase。
這裡有一個容易誤讀的地方：README 說「no remote Postgres container or WebSocket proxy」，指的是查詢路徑，但 browser-proxy 確實存在，只是它的用途是把外部連線導回瀏覽器，而不是把查詢送出去。兩者不矛盾，但只看標語會以為整個 repo 沒有伺服器端元件。
從 npm i 到 npm run dev：啟動順序不能顛倒
README 給的步驟是在 monorepo 根目錄執行，順序有依賴關係。先安裝依賴：
npm i
接著啟動本機 Supabase stack：npx supabase start。然後把本機的 URL 與 anon key 寫進 apps/web/.env.local，指令是 npx supabase status -o env 搭配 --override-name api.url=NEXT_PUBLIC_SUPABASE_URL 與 --override-name auth.anon_key=NEXT_PUBLIC_SUPABASE_ANON_KEY，再 grep NEXT_PUBLIC 附加到檔案。
AI 功能需要 OpenAI API key，寫進同一個檔案：echo 'OPENAI_API_KEY="<openai-api-key>"' >> ./apps/web/.env.local。速率限制用的 KV 變數有固定值，KV_REST_API_URL 是 http://localhost:8080，KV_REST_API_TOKEN 是 local_token。對應的 Redis 容器用 docker compose -f ./apps/web/docker-compose.yml up -d 啟動，API 開在 8080 埠。
剩下每個應用各自的變數要照 .env.example 補齊，位置分別是 apps/web、apps/browser-proxy、apps/deploy-worker 三個目錄。開發時從根目錄跑 npm run dev。
README 對這個指令加了一段警告：npm run dev 底層用 turbo，turbo 知道 monorepo 裡套件之間的依賴關係，會自動先建置 packages/*。如果繞過 turbo 直接跑某個 app，就必須自己先把每個 packages/* 建好，否則 app 會找不到依賴。這是實際會踩到的坑，不是形式提醒。
WASM 版 Postgres 拿不到的東西，比它拿到的更值得注意
PGlite 是 Postgres 的 WASM 版本，這句話的份量在於它同時是承諾也是限制。開發者可以預期 SQL 語法、型別系統、大部分內建函式都在，但不能預期所有擴充套件與系統檢視表都在。README 沒有列出支援清單，也沒有討論這個問題，這是文件明顯偏薄的地方。
實務上要先自己驗證的至少有三項。pg_stat_statements 這類依賴共享記憶體與檔案系統的擴充，在瀏覽器執行環境裡不是理所當然可用。pg_cron 需要常駐排程程序，瀏覽器分頁關掉就沒有常駐可言。pgvector 這類需要原生擴充的元件，能不能載入取決於 PGlite 是否預先編進 WASM 建置，而這件事必須查 PGlite 的說明，不能從 database.build 的 README 推論。
第二個限制是持久化的範圍。資料在 IndexedDB，這代表它跟著瀏覽器設定檔走。換一台機器、換一個瀏覽器、清掉網站資料，資料庫就不在了。README 提到「soon, deploy them to S3」，用的是 soon，所以目前不能把 S3 當成既有的備份路徑。deploy-worker 支援的是部署到 Supabase，這是把資料搬出瀏覽器的主要出口，但 README 寫明目前只支援這一個平台。
第三個限制是它不適合當協作環境。沒有遠端容器意味著沒有共享的連線端點，除非透過 browser-proxy 把連線導回某個人的分頁，而那個分頁必須開著。這種架構天生是單人工具，不是團隊資料庫。
跟直接在瀏覽器裡跑 SQLite 的差別，在於你保留了哪些 Postgres 語意
最接近的替代方案是把 SQLite 編譯成 WASM 在瀏覽器跑，這條路成熟得多，體積也小。兩者的差別不是效能，而是語意。如果專案最終要部署到真正的 Postgres，用 SQLite 起草 schema 會在型別、約束、函式與 DDL 語法上累積落差，之後要人工搬移。database.build 的價值就在這裡：草稿階段用的引擎和目標引擎同名，deploy-worker 也能直接接到 Supabase。
另一個方向是開一個遠端 Postgres 容器，用 Docker 或雲端免費方案。這換來完整的擴充套件與真正的多人連線，代價是要管理生命週期、連線字串與清理。如果工作內容需要 pgvector 或需要排程，遠端容器是唯一合理的選擇，瀏覽器沙盒不是。
還有一個容易被忽略的替代路徑：Supabase 本身就提供分支或臨時專案。如果團隊已經在用 Supabase，額外開一個臨時專案在管理上可能比自己跑 monorepo 更省事。database.build 的優勢場景是「我現在就要一個 Postgres，而且不想等任何雲端資源配置」。這個優勢在離線或網路不穩時尤其明顯，因為查詢根本不需要連線。
維護成本與授權：monorepo 三個應用，外部依賴不只 Postgres
這個 repo 的維護面比表面看起來寬。要讓它完整跑起來，本機需要 Supabase stack、Redis 容器、OpenAI API key，以及三個應用各自的環境變數。缺一項就會有功能不能用，而 README 沒有逐一說明哪個變數對應哪個功能，只指向 .env.example。
外部依賴的變動風險集中在兩處。一是 PGlite，瀏覽器內的 Postgres 能力邊界由它決定，database.build 本身無法補足缺少的擴充。二是 LLM 供應商，README 的設定步驟只示範 OpenAI API key，沒有提到其他供應者的設定方式，所以更換模型供應商需要自己讀程式碼。
授權是 Apache-2.0，這是寬鬆授權，允許商用與修改，通常只需要保留著作權聲明與授權條款。這裡不構成法律意見，實際條款義務要由法務確認，尤其是你要把它包進自有產品再散布時。README 沒有提到商標使用政策，而專案剛從 postgres.new 改名，若打算沿用名稱或網址品牌，這一點值得先確認。
repo 沒有檢索到任何 release，也就是說沒有版本化的發行可供鎖定，採用時只能依 commit 或分支狀態。對內部工具這通常可以接受，對要長期維護的產品則是一個要納入考量的變數。
誰該採用，以及採用前先驗證什麼
適合採用的情況很明確。需要快速得到可拋棄 Postgres 做 schema 草稿、CSV 匯入、關聯圖與報表的人，會直接受益，因為整個流程不需要配置任何雲端資源。想讓 LLM 產生並執行 SQL 但又不想把正式資料庫暴露出去的團隊，也會喜歡這個架構，因為查詢在瀏覽器內執行，資料不經過遠端容器。
不適合的情況同樣明確。工作內容依賴 pgvector、pg_cron 或 pg_stat_statements 的人，應該先確認 PGlite 是否支援，而這件事在 database.build 的 README 裡找不到答案。需要多人共用同一個資料庫、或需要資料跨裝置存在的人，也不該選它，因為資料在 IndexedDB，且 deploy-worker 目前只支援部署到 Supabase。
採用前要驗證的第一件事是環境能否完整啟動：npm i、npx supabase start、docker compose -f ./apps/web/docker-compose.yml up -d，然後照三個 .env.example 補齊變數。第二件事是確認 npm run dev 走的是 turbo，因為繞過它就得手動建置 packages/*。第三件事是列出你打算用的擴充套件，逐一在 PGlite 上實測，而不是假設 WASM 版 Postgres 等同完整 Postgres。這三項驗證做完，這個專案能不能進你的工具箱就有答案了。
編輯結論
database.build 適合兩種人：一是需要可拋棄 Postgres 環境做 schema 草稿、CSV 匯入與關聯圖的開發者，二是想替 LLM 提供安全 SQL 執行環境的團隊，因為查詢不出瀏覽器。不適合需要 pgvector、pg_cron 或 pg_stat_statements 的工作，也不適合把資料庫當長期唯一副本的人：資料在 IndexedDB，清掉瀏覽器資料就沒了。採用前先確認三件事：apps/browser-proxy 與 apps/deploy-worker 的 .env.example 是否齊備、npm run dev 是否經由 turbo 建置 packages/*、以及你的部署目標是否只有 Supabase。
社群筆記