database.build：把 Postgres 沙箱塞进浏览器，但别急着扔掉你的服务器
In-browser Postgres sandbox with AI assistance (formerly postgres.new)
秒懂
- 它是什么？
- database.build 是一个在浏览器里运行 Postgres 的沙箱项目，每个数据库实例都配了一个 LLM。它用 PGlite 和 IndexedDB 实现本地运行，但部署、扩展和运维方式与传统 Postgres 完全不同。本文拆解它的架构、启动步骤和适用边界。
- 适合谁用？
- database.build 适合需要快速演示、教学或原型验证的开发者，尤其是那些想在浏览器里直接操作 Postgres 并借助 AI 生成表结构或查询的人。它不适合作为生产数据库的替代品，因为所有数据都存储在本地 IndexedDB，没有内置的多用户并发控制，也没有服务端持久化。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 104 天前。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
一个运行在浏览器里的 Postgres，和它旁边的 AI
database.build 解决的是一个很具体的问题：你想快速试一个 Postgres 查询或设计一个表结构，但不想安装数据库、不想配置连接串、不想维护任何服务。这个项目把 Postgres 整个搬进了浏览器标签页。根据 README 的描述，每次创建的数据库都是一个全新的 PGlite 实例，而 PGlite 是 Postgres 的 WASM 版本。数据落在 IndexedDB 里，刷新页面后依然存在。这听起来像玩具，但它的目标用户不是生产环境的 DBA，而是那些需要临时沙箱的人：写教程的、做原型验证的、在会议上做演示的。每个数据库旁边还配了一个 LLM，能根据拖入的 CSV 自动生成表，或者根据自然语言生成图表和报表。这个组合让数据库操作从敲命令变成了和助手对话。
PGlite 加 IndexedDB：没有服务器，也没有网络请求
项目的核心机制是 PGlite。它是一个编译成 WebAssembly 的 Postgres，能在浏览器里直接执行 SQL。database.build 没有使用远程 Postgres 容器，也没有 WebSocket 代理来转发查询。所有查询都在本地运行。每个数据库实例都独立，互不干扰。数据持久化靠 IndexedDB，这是浏览器提供的键值存储，适合存结构化数据。文档强调，这种设计意味着没有网络延迟，查询响应速度取决于浏览器的 JavaScript 引擎和 WASM 执行效率。但这也带来一个直接后果：数据库的生存周期和浏览器标签页绑定。关掉标签页，实例就没了，只有 IndexedDB 里的数据还在。下次打开时，需要重新创建实例并加载数据。这种架构对离线工作很友好，但如果你指望多个用户同时访问同一个数据库，那是不可能的。
Monorepo 里的三个角色：Web、代理和部署器
仓库是一个 monorepo，包含三个应用。apps/web 是主要的 Next.js 前端，用户在这里创建数据库和与 AI 交互。apps/browser-proxy 的角色有点意思，它用 pg-gateway 和 WebSocket 把 Postgres 的 TCP 连接代理回浏览器。这意味着你可以在浏览器外使用标准的 Postgres 客户端工具连接到一个在浏览器里运行的数据库。这打破了浏览器沙箱的孤立感。apps/deploy-worker 负责把浏览器里的数据库部署到外部平台，目前只支持 Supabase。README 说这是将数据库部署到 S3 的过渡方案。这三个应用的分工很清晰：Web 是门面，代理是桥，部署器是出口。但要注意，代理和部署器都需要单独的配置，环境变量分别写在各自的 .env.example 里。
从零启动：需要本地 Supabase、Redis 和一个 OpenAI 密钥
想自己跑起来这个项目，步骤不算少。先克隆仓库，在根目录执行 npm i 安装依赖。然后需要启动本地的 Supabase 栈，命令是 npx supabase start。接着把本地 Supabase 的 URL 和匿名密钥写入 apps/web/.env.local，README 给出了用 npx supabase status -o env 配合 grep 的提取方法。之后要创建 OpenAI API 密钥，也写入同一个文件。还需要本地 Redis，用于速率限制，README 要求设置 KV_REST_API_URL 为 http://localhost:8080，KV_REST_API_TOKEN 为 local_token，并用 docker compose -f ./apps/web/docker-compose.yml up -d 启动容器。最后，每个应用还要根据各自的 .env.example 补齐剩余变量。开发时用 npm run dev，它会借助 turbo 自动处理 monorepo 内包之间的依赖构建。如果你绕过 turbo 直接跑某个应用，就得手动先构建 packages 下的依赖。这个启动流程对只想试试数据库沙箱的人来说偏重，它更像是为二次开发准备的。
重命名的背后：不是官方的 Postgres，也不想误导人
项目原名 postgres.new，后来改成了 database.build。README 里专门有一节解释原因：这个项目不是官方 Postgres 项目，不想误导任何人。这个改名决定透露出一个信号，项目方意识到名字可能让人误以为它是 Postgres 官方工具。保留 postgres.new 这个域名会带来权威感，但实际功能只是浏览器里的沙箱。改名后，项目依然 100% 关注 Postgres，只是换了 URL。这种自我定位的调整值得注意，它承认了项目的边界，不是要替代任何现有的 Postgres 服务，而是提供一个实验场。对用户来说，这意味着你在这里学到的东西可以迁移到真实 Postgres，但数据库本身不能直接搬到生产环境。
局限与失败模式：数据在本地，也在牢笼里
最明显的限制是数据持久性。IndexedDB 虽然能跨刷新保留数据，但它受浏览器存储配额限制，而且用户随时可以清除站点数据。一旦清理，所有数据库都没了。另一个问题是并发。浏览器里的 PGlite 实例是单用户的，没有多用户同时写同一份数据的能力。数据库.build 的 AI 功能依赖 OpenAI API，这意味着你需要一个 API 密钥，并且每次 AI 辅助操作都会产生网络请求和费用。如果 OpenAI 服务不可用，AI 功能就瘫痪，但纯 SQL 查询还能用。还有一个隐患：browser-proxy 通过 WebSocket 暴露 TCP 代理，这涉及安全边界，如果代理服务部署不当，可能会让外部连接访问到本应私密的浏览器内数据。仓库里没有发布版本记录，说明项目还处于快速迭代期，API 和配置可能随时变化。
替代方案：本地 Docker 或托管 Postgres，思路完全不同
如果你想要一个接近真实环境的 Postgres 沙箱，最常见的做法是用 Docker 跑一个 postgres 容器，比如 docker run --name pg-sandbox -e POSTGRES_PASSWORD=pass -p 5432:5432 -d postgres。这个方案的数据在本地磁盘，支持多用户连接，有完整的 Postgres 功能。区别在于，Docker 容器需要你安装 Docker，而且占用的系统资源更多。另一个方向是使用托管服务如 Neon 或 Supabase 的免费层，它们提供云端 Postgres，你可以从任何地方连接，但需要网络，且数据不在你控制之下。database.build 的核心差异是零安装和完全离线，它牺牲了持久性和共享性。如果你的需求只是临时跑几条 SQL，浏览器沙箱更轻量；如果你需要和同事协作或者跑长时间任务，Docker 或托管服务更靠谱。
维护成本与许可证：Apache-2.0 下的开放代码，但升级路径未知
项目采用 Apache-2.0 许可证，这意味着你可以自由使用、修改和分发，甚至用于商业目的，只要保留版权声明。但仓库没有任何 release 标签，最近的提交是 2026 年 6 月，说明项目活跃但尚未形成稳定的版本节奏。维护成本方面，由于是 monorepo，你需要同时跟进三个应用的依赖更新。PGlite 本身也在演进，如果 PGlite 更新了 WASM 版本，database.build 可能需要相应调整。AI 功能依赖 OpenAI，如果 OpenAI 改变 API 或定价，项目的集成代码需要跟着改。部署到 S3 的功能在 README 里标注为“soon”，目前只有 Supabase 支持，这意味着如果你想部署到其他平台，需要自己阅读 deploy-worker 的代码并扩展。没有版本记录意味着没有语义化版本承诺，升级到新 commit 可能引入破坏性变更。
编辑结论
database.build 适合需要快速演示、教学或原型验证的开发者，尤其是那些想在浏览器里直接操作 Postgres 并借助 AI 生成表结构或查询的人。它不适合作为生产数据库的替代品，因为所有数据都存储在本地 IndexedDB，没有内置的多用户并发控制，也没有服务端持久化。若你打算部署到 S3 或 Supabase，需要先验证 deploy-worker 的成熟度，因为仓库中没有发布版本记录。在采用前，你应该检查 PGlite 对你自己常用 Postgres 特性的支持程度，比如某些扩展或高级索引类型，并确认你的数据量不会超过 IndexedDB 的实际存储限制。
社区笔记