为什么每个 Mythex 应用都有自己的数据库

当你在 Mythex 上构建的应用需要保存数据——注册信息、预约、订单——Mythex 会为该项目提供它自己的 Postgres 数据库。不是共享数据库中的一张表，也不是与别人并排的一个 schema：而是一个独立的数据库，按需创建，无人使用时休眠。下面说明我们为什么这样设计，以及它的代价。

你会得到什么

当你要求保存数据（「保存等候名单邮箱」「存储预约」）或使用 /database 命令时，Mythex 会：

• 为项目创建一个专用的 Postgres 数据库（目前为 Postgres 17），
• 将连接信息作为环境变量注入到你的工作区和已发布的应用中，因此它们从不出现在代码里，并且
• 让智能体为你创建表，并读写数据。

实时预览和已发布的应用使用的是同一个数据库。它空闲 5 分钟后休眠，并在下一次查询时唤醒。新数据库起始规模较小，可以在负载下扩容，并设有上限，因此失控的查询不会无限制地增长。更多内容请参阅数据库文档。

为什么不用一个大的共享数据库？

一个共享数据库，用一列标明每行属于哪个应用，运行成本更低，操作也更简单。我们选择不这样做，原因有四：

1. 无需信任的隔离

AI 编写的代码会犯错。在共享数据库中，某个应用的查询里少写一个 WHERE app_id = …，就可能读取或覆盖另一位客户的数据。而每个应用一个数据库，就不存在任何其他客户的数据可以被触及——一个 bug 只会停留在它自己的应用之内。

2. 它是真正的 Postgres，而不是专有的封装层

你的应用使用标准的 Postgres 连接字符串与数据库通信。任何适用于 Postgres 的库、ORM 或工具，在这里都能工作。如果你导出项目到其他地方运行，它需要的是一个 Postgres 数据库——每家托管服务商都提供的东西——而不是某个 Mythex 专有的 API。

3. 每个应用可以按需要设计结构

一个应用需要一张 bookings 表，并在时间段上设置唯一约束；另一个应用则需要对商品进行全文搜索。有了各自独立的数据库，每个应用的 schema 和迁移都由它自己负责。没有什么需要去迁就一个最低公约数式的设计。

4. 成本随使用量而定

由于每个数据库各自休眠，无人使用的应用几乎没有成本，而繁忙应用的成本则体现为它自己的一项。已发布应用的数据库用量，是根据数据库实际测量的用量计费的——计费方式见此。

权衡

这种设计并非没有代价：

• 冷启动。 休眠的数据库在一段安静时间后的第一次查询时，需要一点时间唤醒。对大多数应用来说，这几乎察觉不到；但对于必须在任何时间都即时响应的应用来说，这是需要考虑的因素。
• 醒着时的成本。 只要有东西在查询，数据库就保持唤醒。一个每隔几秒就轮询数据库的应用，会让它全天候保持唤醒，成本也比按需查询的应用更高。如果你的用量比预期高，通常就是这个原因——可以让 AI 停止轮询，改为在需要时再加载数据。
• 我们这边的运维工作更多。 创建、跟踪和清理成千上万个数据库，比管理一个数据库要费力得多。这是我们需要承担的问题，而不是你的。

如果你是数据库新手

数据库是应用保存其需要「记住」的内容的地方。如果这个概念对你来说还很陌生，可以先阅读什么是数据库和什么是 Postgres。当你准备好构建一个需要存储数据的应用时，如何用 AI 构建应用会讲解如何添加数据库。