自database.build(原名postgres.new)发布以来，我们一直在辛勤工作，现在我们非常激动地向大家展示一系列全新的功能，首先是：自带的LLM功能。
现在你可以通过任何与OpenAI兼容的服务提供商使用你自己的大模型（如LLM）。
如果你错过了，database.build（或直接保留英文名称，避免误译）是一个带有 AI 辅助的浏览器内的 Postgres 砂箱。你可以创建任意数量的 Postgres 数据库，并通过自然语言与它们互动（借助大语言模型）。这要归功于 PGlite — 一个可以在浏览器中直接运行的 Postgres 的 WASM 版本。
使用 database.build，只需描述你想要构建的数据库结构，AI 就会帮你搭建表框架。你也可以通过拖放 CSV 文件来自动根据其内容生成表结构，然后用标准 SQL 查询这些表。
从第一天起，我们的目标就是让database.build对所有人免费且开放。为了达到这一目标并同时减少滥用行为（以及高昂的OpenAI账单），我们要求用户用他们的GitHub账号登录。我们还引入了适度的限制，以限制过度使用AI，并确保每个人都能公平访问。
虽然这种设置对大多数用户来说运行良好，但高级用户经常报告他们频繁触及这些速率限制。其他人则对实验替代模型甚至完全本地运行 database.build 表达了兴趣。这些都是我们非常乐意支持的合理用例。这就是为什么今天我们推出一个新选项，通过任何与 OpenAI 兼容的提供商连接您自己的大型语言模型（LLM）。
如果你有自己的大型语言模型，你将获得：
- 无需登录：无需 GitHub 账户即可创建 AI 辅助的数据库。
- 无使用限制：您的使用量仅受限于您选择的服务提供商。
- 更大的控制权：确保您的聊天消息仅发送给您信任的供应商。
- 更高的灵活性：选择您的模型，并根据需求定制提示。
对于拥有严格AI政策要求和防火墙限制的组织，自带LLM使其变得轻松，可以将AI消息通过公司批准的API端口路由，例如Azure的OpenAI服务端点。
AI开放性兼容如果你曾使用过大规模语言模型，你可能已经注意到，OpenAI的API结构已经成为一种非正式的标准。许多LLM提供商提供与OpenAI兼容的API，使得使用现有工具和库（这些工具和库是围绕OpenAI的API构建的）来使用替代模型变得更加容易。
对于BYO-LLM来说，这真是个好消息，因为它意味着连接到其他LLM供应商变得非常简单——只要他们提供一个与OpenAI兼容的API就行了。
你可能在想这个问题：这是否意味着你需要将 database.build 本地连接到 Ollama，因为它也有一个与 OpenAI 兼容的 API？答案是肯定的，确实可以！不过有几点需要注意的地方，往下看更多详情！
如何使用这个在 database.build 标题的左侧，你会看到一个新按钮，标记为 自带 LLM。点击这个按钮就可以打开一个侧边栏，在那里你可以连接自己的 LLM 提供商。
在这里，输入你的模型提供商的URL地址、你的API密钥以及你想要使用的模型。
请注意，所有设置和密钥都存储在本地，永远不会离开您的浏览器。甚至API请求也是直接从浏览器发出的，不需要经过后端代理——继续往下看！
值得注意的是，你选择的模型将显著影响你在使用database.build时的体验。为了正常运行，database.build需要模型具备几个关键特性。
- 工具调用：为了帮你执行SQL、生成图表以及其他所有当前可用的功能，模型需要支持工具（功能）调用。最近的先进模型支持这一点，但许多其他模型不支持这些功能，因此无法与database.build配合工作。
- SQL理解：这听起来显而易见，但如果没有具备中等到大量SQL知识训练的模型，database.build将难以生成任何有用的东西。
- Chart.js知识：如果你计划生成图表，这一点相当重要，因为模型负责生成用于Chart.js的图表配置。
因此，我们建议继续使用 gpt-4o，以便您能保持熟悉的使用体验。为了节省API费用，您可以尝试使用 gpt-4o-mini，但请注意，它有时可能会错过重要信息或无法构建更复杂的结构。如果您想尝试一些新事物，我们非常想了解您尝试其他提供商和模型与 database.build 结合后的体验。
最后，我们给你自由来自定义传递给模型的系统提示内容。到目前为止，这仅是为了与比如gpt-4交互而设计的，因此，如果你使用的是其他模型，你可能得调整一下。
内部运作为了优先考虑隐私，所有LLM API请求都直接从浏览器发出。这意味着您的消息、数据结构、数据和API密钥将仅直接发送到服务方的API，而不通过后端代理进行中转，从而让这成为可能。
这要归功于两个关键要素。
- 支持CORS的API
- Service Worker
如果你开发过任何连接到后端 API 的浏览器应用，你很可能遇到过 CORS。CORS 代表跨源资源共享（CORS），这是一种内置在浏览器中的安全机制，用于防止网站跨域连接 API。然而，很多时候确实有正当理由需要访问不同域名的 API，例如，服务器只需在响应头中包含允许你的应用连接的特定标志即可。
在构建数据库的情况下，我们需要直接连接到类似 OpenAI 的 API（https://api.openai.com/v1）或其他你选择的提供商的 API。这将始终是跨源请求，因为浏览器发出的请求不受同源策略的限制。好消息是：大多数大型语言模型提供商默认支持 CORS，这意味着我们可以直接从浏览器连接到他们的 API，而无需额外的工作。如果没有 CORS 支持，我们唯一的选择就是通过后端代理来转发每个请求，而后端代理不会受到 CORS 的限制。
服务人员如果你曾经研究过 database.build 的源代码，你就会知道我们大量使用了 Vercel 的AI SDK来简化客户端工具调用过程和大语言模型的流式处理。Vercel 通过提供如 useChat() 这样的便捷钩子来管理 React 应用中的 AI 聊天消息，提供了很好的开发者体验。
Vercel 的 AI SDK 在使用 BYO-LLM 时面临的挑战是，SDK 期望一个客户端-服务器的 API 结构。useChat() 会连接到服务器端的 /api/chat 路由，该路由负责将消息发送到相应的提供商。但是，在我们这种情况下，用户会动态提供自己的 API 密钥，因此我们更希望直接从浏览器发送这些请求。如果我们希望继续使用现有的 useChat() 基础设施，我们需要一种方法来拦截对 /api/chat 的请求，并在浏览器中直接处理这些请求。
救星来了！服务工作者的一个核心功能就是能够拦截 fetch 请求并在客户端进行处理——这正是我们需要的。这样我们就可以保留 useChat() 的原有逻辑，然后创建一个轻量级的服务工作者来完成以下任务：
- 通过从 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，当前的行为是将整个响应缓冲直到完成，然后一次性发送为一个delta消息。这在前端造成了较慢的性能感觉，即使后端处理正常。Ollama团队正在积极改进这一点。
即使有这些挑战，我们也非常希望能看到有人成功运行本地模型。随意试试，通过调整系统提示来更好地指导模型，如果你成功了，记得告诉我们哦！
开放权重的模型正在迅速改进，而随着消费硬件的持续进步，本地部署有望成为更广泛的使用场景（包括我们希望的数据库构建在内）的更实用选项。
实时协作实时共享允许你使用任何 PostgreSQL 客户端从浏览器之外连接到浏览器内的 PGLite 数据库。
你可以直接复制并粘贴提供的连接字符串到 psql。连接上之后，你就可以实时与你浏览器内的 PGlite 实例进行交互，就像操作任何普通的 PostgreSQL 数据库一样。
您可能还想连接到这里的其他工具：
- pg_dump: 导出你在浏览器中的数据库到其他平台吧！
- ORM: 在你的应用内直接试一下你的数据库
- IDE: 使用你最喜欢的数据库 IDE 查看你自己的数据
要了解更多背后的工程细节，请查看我们的相关博客文章。(https://supabase.com/blog/database-build-live-share)
部署其中一个最受欢迎的功能就是一键轻松将你的数据库部署到云上。
作为一个快速提醒——所有通过 database.build（数据库构建工具）创建的数据库都在您的浏览器中使用 PGlite 运行。这种客户端的方法使你可以在浏览器中轻松地启动数据库，用于设计和实验。几乎可以无限创建这些数据库。但是，当需要将数据库用于实际生产环境时，选择起来就变得有些麻烦了：
- 手动复制生成的迁移并将其粘贴到实际数据库中运行
- 使用 Live Share 和命令
pg_dump和pg_restore将浏览器数据库备份并通过恢复到生产就绪的数据库
现在，你可以直接通过部署过程，将你通过数据库.build 创建的应用程序部署到云数据库提供商，例如 Supabase，（AWS 将很快推出）。
部署到 Supabase在构建数据库模式之后，然后点击顶部的部署按钮。
当你第一次部署到 Supabase 时，你需要将你的数据库.build 账户和 Supabase 账户关联起来。如果你还没有 Supabase 账户，你可以在那里创建一个新账户。Supabase 包含一个免费计划，所以如果你这是你的第一个项目，部署是免费的。请按照对话框中的步骤来关联你的账户与 Supabase 组织。
一旦您的账户连接完毕，您将会看到即将创建的组织和项目名称的预览页面。如果您对这些信息满意，请点击部署。请保持浏览器标签页打开，确保部署顺利进行。
最后，会给你连接串和密码，用来连接到新数据库并访问。
幕后部署工作起来比初看上去需要的技术工程要多得多。为了准确地将浏览器数据库复制到云上，我们需要一种导出和导入的方法。
我们决定基于现有的Live Share功能，该功能在你的浏览器内的数据库和外部的PostgreSQL客户端之间创建一个逆向连接。启用Live Share后，我们直接将服务器端的pg_dump程序连接到你的浏览器中的数据库。然后生成的转储文件会通过管道传递给pg_restore，将其传输到你的新云数据库中。
是的，这确实涉及很多组件！值得一提的是，Electric SQL 刚刚发布了 pg_dump 的 WASM 版本，我们期待将来将其整合进来。直接在浏览器中生成转储文件可能会更快、更可靠，并且涉及的组件更少，因此更简洁可靠。
当初我们刚推出 database.build 时，我们探索了一种无服务器的 PGlite 部署方式。然而，随着我们继续前进，遇到了一些小但重要的挑战，这些问题逐渐累积。PGlite 在多租户环境中的内存使用超出预期——对此，ElectricSQL 团队正在积极解决。由于 PGlite 的单连接限制，超过几兆字节内存的使用在无服务器环境中将变得不切实际。此外，我们最初使用 s3fs 进行存储，其表现不如预期可靠，使得达到无缝的无服务器体验变得困难。
尽管这些挑战使我们暂时专注于替代部署选项，我们仍然会持续关注无服务器选项，并在这些问题解决且生态系统进一步发展时重新考虑。
拖拽 SQL 文件来操作你一直以来都可以将 CSV 文件拖放进入聊天，但是 SQL 文件呢？在这个新版本里，只需将 SQL 文件拖放到聊天里，其内容会在你的浏览器中的数据库中自动加载。
当你希望扩展或询问之前在其他地方设计的现有模式或架构时，这会很有用。
通过pg_dump 下载 pglite
你现在可以利用 WASM 版本的 pg_dump 将浏览器中的数据库导出到 SQL 文件。
之前当你下载你的数据库时，我们曾导出过 PGlite 内部的 pgdata 目录作为一个 .tar.gz 文件。这种格式有点麻烦，而且只适用于其他 PGlite 实例。现在当你下载时，你会得到一个 .sql 文件，你可以在任何 Postgres 数据库中导入它。
向ElectricSQL团队致敬，他们在嵌入式Postgres领域不断取得新进展。WASM pg_dump 是项目的一大进步，我们期待他们在未来为浏览器提供更多工具。
我们非常激动地宣布 database.build 的全新设计，它不仅带来了全新的外观，还增强了功能。
这次更新确保了对桌面和移动平台的无缝兼容，让所有设备上的体验流畅而直观。准备随时随地搭建您的数据库吧！
无论你是在火车上、被卡在会议里，还是躺在沙发上，只需轻轻几下，你就可以运行数据库并优化你的数据库设置。
随着移动支持的加入，你现在再没有借口不推出你一直在推迟的特性了，对吧？我们非常期待看到你接下来的作品！
今天我们发布的所有功能——包括BYO-LLM、Live Share、Deployments、拖放SQL和移动支持——都是基于开源基础构建的。我们相信透明度、社区合作，并致力于让像database.build这样的工具为每个人所用变得容易。
如果你对背后的运作方式感到好奇，或者想要参与，你可以在 GitHub 上找到这个项目：https://github.com/supabase-community/database-build。
像往常一样，我们很想听听你的想法和反馈，或者看看你正在做什么！
关于LW13更多内容第一天 - Supabase AI助手V2
第二天：Supabase 函数：后台处理和 WebSocket
第三天：Supabase Cron：在 Postgres 中安排定时任务
第四天 - Supabase 排队系统 (https://supabase.com/blog/supabase-queues)
构建步骤：OrioleDB 公开Alpha版发布
Supabase CLI v2: 配置即代码 (https://supabase.com/blog/cli-v2-config-as-code)
随时随地看视频
