database.build v2：自带LLM
由 Mux 主办的 DEV 全球展示挑战赛：展示你的项目！
自推出database.build （以前称为 postgres.new）以来，我们一直在努力工作，我们很高兴推出一系列新功能，首先是：自带 LLM。
现在您可以通过任何兼容 OpenAI 的提供商使用您自己的大型语言模型 (LLM)。
如果您错过了，database.build 是一个内置于浏览器的 Postgres 沙箱，并带有 AI 辅助功能。您可以创建无限数量的 Postgres 数据库，并使用自然语言（通过 LLM）与它们进行交互。这得益于PGlite——一个可以直接在浏览器中运行的 Postgres WASM 版本。
使用 database.build，只需描述您想要构建的内容，AI 就会帮助您搭建数据库表。您还可以拖放 CSV 文件，根据其内容自动生成数据库表，然后使用常规 SQL 查询这些表。
自带法学硕士学位
从一开始，我们的目标就是让所有人都能免费访问 database.build。为了实现这一目标，同时减少滥用（以及高昂的 OpenAI 费用），我们要求用户使用 GitHub 帐户登录。此外，我们还引入了适度的速率限制，以减少过度使用 AI 的行为，确保每个人都能公平访问。
虽然这种配置对大多数用户来说运行良好，但高级用户反映经常遇到速率限制。还有一些用户表示有兴趣尝试其他模型，甚至完全在本地运行 database.build。这些都是合理的用例，我们很乐意提供支持。因此，今天我们推出一个新选项：通过任何兼容 OpenAI 的提供商连接您自己的大型语言模型 (LLM)。
自带法学硕士学位，您将获得：
- 无需登录：无需 GitHub 帐户即可构建 AI 辅助数据库。
- 无流量限制：您的使用量仅受您选择的服务提供商的限制。
- 更多控制权：确保您的聊天消息仅发送给您信任的服务提供商。
- 更大的灵活性：选择您的模型并自定义提示以满足您的需求。
对于有严格 AI 策略或防火墙限制的组织而言，BYO-LLM 可以轻松地通过公司批准的 API 端点（例如 Azure 的 OpenAI 服务）路由 AI 消息。
OpenAI兼容性
如果你使用过大型语言模型，你可能已经注意到 OpenAI 的 API 结构已经成为一种非官方标准。许多大型语言模型提供商现在都提供与 OpenAI 兼容的 API，这使得使用基于 OpenAI API 构建的现有工具和库来操作其他模型变得更加容易。
这对 BYO-LLM 来说是个好消息，因为这意味着连接到 OpenAI 以外的其他 LLM 提供商（例如xAI）非常简单——只要它们提供与 OpenAI 兼容的 API。
你可能会想：这是否意味着你需要将 database.build 本地连接到Ollama，因为它也有一个与 OpenAI 兼容的 API？答案是肯定的！但有一些限制，请继续阅读！
如何使用它
在 database.build 标题栏的左侧，您会找到一个名为“自带 LLM”的新按钮。点击此按钮将打开一个侧边栏，您可以在其中连接您自己的 LLM 提供商。
在这里，传入您的 LLM 提供商的基本 URL、关联的 API 密钥以及您希望使用的模型。
请注意，所有设置和密钥都存储在本地，绝不会离开您的浏览器。甚至 API 请求本身也是直接从浏览器发送的，无需后端代理——请继续阅读！
需要注意的是，您选择的模型将极大地影响您使用 database.build 的体验。为了正常工作，database.build 需要模型具备以下几个关键特性：
- 工具调用：为了能够代表您执行 SQL、生成图表以及执行其他所有现有功能，模型需要支持工具（函数）调用。目前最先进的模型都支持此功能，但许多其他模型仍然不支持，因此无法与 database.build 配合使用。
- SQL 理解：这听起来很明显，但如果没有经过中等到高度 SQL 知识训练的模型，database.build 将很难构建任何有用的数据。
- Chart.js 知识：如果您计划生成图表，这一点很重要，因为模型负责生成传递给 Chart.js 的图表配置。
因此，如果您希望获得与以往相同的体验，我们建议您继续使用 OpenAI 的 gpt-4o。为了节省 API 费用，您可以尝试 gpt-4o-mini，但请注意，它有时可能会遗漏重要信息或无法构建更复杂的模式。如果您有兴趣尝试其他模型提供商，我们非常希望了解您使用 database.build 尝试的其他模型和模型，以及您使用它们的体验。
最后，我们允许您自定义传递给模型的系统提示。目前，此功能仅适用于与 gpt-4o 的交互，如果您使用的是其他模型，则可能需要进行相应的调整。
引擎盖下
为了以隐私为先，所有 LLM API 请求均直接从浏览器发送。这意味着您的所有消息、架构、数据和 API 密钥都将直接发送到您的服务提供商的 API，而无需通过后端代理。
这主要归功于两个重要因素：
- 支持 CORS 的 API
- 服务人员
支持 CORS 的 API
如果您开发过任何连接到后端 API 的浏览器应用，您很可能遇到过 CORS。CORS 代表跨域资源共享，是浏览器内置的一种安全机制，用于防止网站连接到来自不同域的 API。然而，很多时候连接到不同域是有正当理由的，为了支持这种情况，服务器只需发送明确允许您的应用连接的 HTTP 响应头即可。
对于 database.build，我们需要直接连接到 API，例如 OpenAI 的https://api.openai.com/v1或您选择的任何其他提供商——由于请求来自浏览器，因此始终存在跨域访问问题。好消息是：大多数 LLM 提供商默认会添加 CORS 标头，这意味着我们可以直接从浏览器连接到它们的 API，无需额外操作。否则，我们唯一的选择是将所有请求路由到后端代理（后端代理不受 CORS 限制）。
服务人员
如果你曾经深入研究过 database.build 的源代码，就会发现我们大量使用了 Vercel 的AI SDKuseChat()来简化 LLM 流式传输和客户端工具调用。Vercel 通过提供便捷的钩子（例如在 React 中管理 AI 聊天消息），围绕推理构建了出色的用户体验。
Vercel 的 AI SDK for BYO-LLM 面临的挑战在于，该 SDK 需要客户端-服务器 API 架构。useChat()它会连接到服务器端/api/chat路由，该路由负责将这些消息向下游发送给相应的提供商。通常情况下，这是保护 API 密钥和服务器端自定义逻辑的最佳架构。然而，在我们的案例中，用户会动态提供自己的 API 密钥，因此我们更倾向于直接从浏览器发送下游请求。如果我们希望继续使用现有的useChat()基础架构，则需要一种方法来拦截这些请求/api/chat并在浏览器中自行处理它们。
Service Worker来帮忙啦！Service Worker 的核心功能之一就是能够拦截 fetch 请求并在客户端进行处理——这正是我们需要的。有了这种方法，我们可以保留现有的useChat()逻辑，然后创建一个轻量级的 Service Worker 来实现以下功能：
- 通过从IndexedDB读取本地状态来检测您是否正在使用自己的模型（服务工作线程无法访问本地存储，因此我们选择 IndexedDB）。
- 如果检测到，它会在本地运行一个 HTTP 处理程序
/api/chat，将请求直接发送到您的提供商 API。 - 否则，它会像以前一样将请求转发到我们的后端。
值得一提的是，我们后来了解到，这种方法useChat()允许直接向钩子函数传递自定义fetch函数，我们可以用同样的方法拦截 API 请求。未来我们可能会采用这种方法，以简化解决方案，减少组件数量。
奥拉玛
能否将 database.build 连接到Ollama以实现完全本地化的 AI 体验？从技术上讲，可以——但有一些注意事项：
- 本地模型在工具调用方面（目前）表现并不出色。虽然像 Llama 3.1/3.2 和 Qwen 2.5 Coder 这样最新的先进模型在技术上支持工具调用，但可以在消费级硬件上运行的版本（例如量化模型或低参数版本）的性能不如其大型版本稳定。这些小型模型经常在需要时无法调用工具、调用不存在的工具或传递无效参数。
- 工具流式传输的挑战。database.build 的运行依赖于工具调用和流式传输。Ollama 最近增加了对工具流式传输的支持（感谢@thanosthinking），只要模型能够正确处理工具调用，就可以将其与 database.build 结合使用。然而，尽管 Ollama 提供了工具流式传输 API，但目前的行为是将整个响应缓存起来，直到处理完成才通过单个增量消息发送。这导致前端性能看起来较慢，即使后端处理正常。Ollama 团队正在积极改进这一点。
即便面临这些挑战，我们仍然非常希望看到有人成功搭建本地模型。欢迎大家进行实验，调整系统提示以更好地引导模型运行，如果成功了，请告诉我们！
开源模型正在迅速改进，随着消费级硬件的不断进步，本地部署可能会成为更广泛用例的更实用选择——包括（希望）数据库构建。
实时共享
Live Share 允许您从浏览器外部（使用任何 PostgreSQL 客户端）连接到浏览器内的 PGlite 数据库。
例如，您可以将提供的连接字符串复制粘贴到psql. 连接成功后，您就可以像操作任何常规 Postgres 数据库一样，与浏览器中的 PGlite 实例进行实时交互。
您可能还想连接以下其他工具：
- pg_dump：将浏览器中的数据库导出到其他平台！
- ORM：直接在应用程序中测试数据库
- IDE：使用您喜欢的数据库IDE浏览您的数据。
想了解背后的工程技术细节，请查看我们的专题博客文章。
部署
用户呼声最高的功能之一就是能够一键轻松地将数据库部署到云端。
简单提醒一下——所有 database.build 数据库都使用 PGlite 直接在浏览器中运行。这种客户端方式使得创建几乎无限数量的数据库用于设计和实验变得非常容易。但是，当需要在生产环境中使用数据库时，操作起来就有些繁琐了：
- 手动复制粘贴生成的迁移脚本，并将其应用于真实数据库。
- 使用 Live Share 将浏览器数据库备份
pg_dump和pg_restore恢复到可用于生产环境的数据库。
现在有了部署功能，您可以将 database.build 创建的内容直接部署到云数据库提供商，首先是 Supabase（AWS 也即将推出）。
部署到 Supabase
构建好数据库架构后，点击应用标题栏中的“部署”按钮。
首次部署到 Supabase 时，您需要将 database.build 帐户与 Supabase 帐户关联。如果您还没有 Supabase 帐户，可以在这里创建一个新帐户。Supabase 提供免费套餐，因此如果您是第一次部署项目，则无需支付任何费用。请按照对话框中的步骤将您的帐户与 Supabase 组织关联。
账户连接成功后，您将看到即将创建的组织和项目名称预览。如果您满意，请点击“部署”。请务必保持浏览器标签页打开，以确保部署成功。
最后，您将看到用于连接到新数据库的连接字符串和密码。
幕后花絮
要让部署顺利进行，实际所需的工程量远比乍看之下要大得多。为了准确地将浏览器数据库复制到云端，我们需要一种方法来进行数据导出和恢复。
我们决定利用现有的 Live Share 功能，该功能会在您的浏览器数据库和外部 PostgreSQL 客户端之间建立反向连接。启用 Live Share 后，我们会将服务器端pg_dump程序直接连接到您的浏览器数据库。然后pg_restore，生成的转储数据会通过管道传输到您的新云数据库。
是的，这其中涉及的环节很多！值得一提的是，Electric SQL刚刚发布了WASM版本，pg_dump我们非常期待未来能将其集成到系统中。直接在浏览器中生成转储文件可能会更快、更可靠，而且环节更少。
那么，无服务器 PGlite 怎么样？
在数据库构建项目最初发布时，我们曾计划探索无服务器的 PGlite 部署方案。然而，随着项目的推进，我们遇到了一些虽小但影响深远的挑战。PGlite 在多租户环境中的内存使用量超出预期——ElectricSQL 团队正在积极解决这个问题。鉴于 PGlite 的单连接限制，在无服务器环境中，超过几兆字节的内存使用量是不切实际的。此外，我们最初对s3fs存储的依赖也未能达到预期，导致难以满足无缝无服务器体验的要求。
虽然这些挑战迫使我们目前专注于其他部署方案，但随着这些问题的解决和生态系统的不断发展，我们仍然致力于重新审视无服务器方案。
拖放 SQL 文件
您一直都可以将 CSV 文件拖放到聊天窗口中，但 SQL 文件呢？在这个新版本中，只需将 SQL 文件拖放到聊天窗口中，即可自动将其内容加载到浏览器数据库中。
如果您有在其他地方设计的现有架构或迁移需要扩展或提出相关问题，这将非常有用。
通过以下方式下载 PGlite 数据库pg_dump
现在您可以使用 WASM 版本的pg_dump.
之前下载数据库时，我们会将 PGlite 的内部pgdata目录导出为一个.tar.gz文件。这种格式使用起来比较麻烦，而且只能与其他 PGlite 实例兼容。现在，点击“下载”后，您将获得一个.sql可以导入到任何 Postgres 数据库的文件。
ElectricSQL 团队不断在嵌入式 Postgres 领域取得突破，值得称赞。WASMpg_dump是该项目的一大进步，我们非常期待他们未来为浏览器带来更多工具。
重新设计
我们很高兴地宣布 database.build 进行了全面重新设计，带来了简洁的新外观和增强的功能。
此次更新全面支持桌面和移动平台，确保在所有设备上都能获得流畅直观的使用体验。随时随地，轻松构建您的数据库！
移动支持
无论你是在火车上、开会时还是躺在沙发上，只需轻点几下，即可启动数据库并调整架构。
有了移动端支持，你就再也没有理由拖延发布那个你一直想做却迟迟不做的功能了。我们非常期待看到你的作品！
总结
我们今天发布的所有功能——BYO-LLM、Live Share、部署、拖放式 SQL 和移动支持——都基于开源基础构建。我们秉持透明、社区协作的理念，并致力于让每个人都能使用 database.build 等工具。
如果您对底层工作原理感到好奇或想要做出贡献，您可以在 GitHub 上找到整个项目：https://github.com/supabase-community/database-build。
和以往一样，我们非常乐意听取您的反馈、想法，或者看看您正在制作什么！
关于LW13的更多信息
第一天 - Supabase AI 助手 V2
第二天 - Supabase 函数：后台任务和 WebSocket
第三天 -
Supabase Cron：在 Postgres 中安排周期性作业