--- layout: post.njk source: https://yage.ai/share/supabase-compute-docker-baas-20261102.html web_feed: articleId: cmvzw58l4001e9eyexvaomy0a feedSourceId: webfeed_yage_ai guid: https://yage.ai/share/supabase-compute-docker-baas-20261102.html sourceUrl: https://yage.ai/share/supabase-compute-docker-baas-20261102.html speaker: yage.ai title: |- 做 Postgres 起家的 Supabase，为什么非要自己卖 Docker 容器？ date: '2026-11-02' summary: Supabase 宣布进入 Compute 私有内测，旨在为用户提供在数据库项目上直接运行 AI Agent、后台任务和自定义接口的能力，包括通过 Dockerfile 部署任意语言的 API 服务和 WebSocket 长连接服务。Supabase 官方推出容器部署是为了在客户自建外部业务层服务器前，将预算留在自家平台内。Compute 容器支持完整的 Linux 环境和任意语言运行时，解决了无服务函数在单次运行时间限制和环境受限的问题。通过在同机房内网运行容器，可以实现高频读写数据库和数据分析智能体（如使用 DuckDB）的低延迟查询，将查询延迟从近五秒降低到2.9毫秒，并实现内存快照，从而简化查询流程并隔离生产主库风险。 area: tech-engineering category: architecture tags: - supabase - docker - compute - ai-agent - data-engineering people: [] companies_orgs: - Supabase - Cloudflare products_models: - Postgres - Docker - Deno - Claude Opus 5.5 - DuckDB media_books: [] draft: true status: evergreen --- 2026 年 10 月 27 日，以托管 Postgres 数据库起家的 Supabase 宣布进入 Supabase Compute 私有内测，宣称可以在数据库项目上直接运行 AI Agent、后台任务和自定义接口。翻开官方推荐的场景，在 Agent 和数据批处理以外，甚至还包含了通过 Dockerfile 部署任意语言的 API 服务，以及面向实时语音应用的 WebSocket 长连接服务。如果你平时自己养过服务器，看到这里一定觉得奇怪：实时语音通话和数据库有什么关系？先给个剧透：Supabase 没有在数据库引擎里加入大模型，而是在紧靠你数据库的同一个机房内网里面，开了一个简配版的容器托管行。一个做数据库的公司为什么手伸这么长，是因为它走过的路与众不同。 ## 网站本来就有后端服务器，数据库公司为什么要抢着跑容器？ 传统软件工程里，一个网站往往有三层：浏览器或手机里的前端界面，跑在云主机或容器平台上的业务层服务器，以及只管存数据的纯数据库。用这个架构的团队本来就有常驻的后端服务器，写个 Python 接口、跑个后台队列、维护一条语音长连接，直接往自家服务器上一放就完事，完全不用数据库厂商操心代码怎么跑。 但 Supabase 重点培养的用户群体却不一样。Supabase 一开始以开源 Firebase 的面貌出现，提供一站式后端服务，比如用 Postgres 做数据库、负责用户登录认证、文件存储，甚至自动生成读写接口，再加上数据库自带的行级权限控制，根据当前登录用户决定他能看见哪些行。这使前端应用可以在浏览器或手机上直接安全地查表，让很多独立开发者和快速原型搭建者不用再自己养一台业务层服务器。今年十月的年度大会上，他们又推出了一个工具，让编程助手直接在你的代码仓库里管理表结构和配置，进一步支持纯前端直连数据库的免后端模式。 省掉业务服务器在产品早期确实省心省力，但一旦业务加入 AI 功能，这种靠免后端起家的路径就把隐患集中暴露出来了。这群免后端团队只有前端页面和 Supabase 账号，并没有一台常驻的 Linux 机器。以前发邮件、接支付回调这些小事，用项目自带的无服务函数就能搞定。但无服务函数有三道铁栅栏：单次运行到四百秒强制终止，内存和处理器受限且没有完整的 Linux 环境，开发语言也绑在 Deno 上跑不了 Python。 一旦开发团队想要跑个十分钟的智能体，或者调用一个现有的 Python 库，就会撞到这四百秒超时的墙。为了绕过这些限制，那些原本零后端运维的团队只好去注册第二个云平台，租下人生第一台外部容器，分别维护两套部署、两套密钥和两边的日志。这个决策在商业上触及了 Supabase 的底线：一旦客户在外头自建了自己的业务层服务器，Supabase 就会从一个包揽一切的后端平台，退化成普通 Postgres 数据库。官方现在亲自下场卖容器，就是想在客户去外部开户前，把原本要流向外部容器平台的预算留在自家账单里。 传统三层架构本来就有后端服务器，而纯前端直连 Supabase 的团队撞上超时限制后只能靠项目内计算容器防止业务外溢。 ## 连自动扩缩容都还没做完，为什么偏偏赶在十月底端出来？ 这个私有内测文档透露的信息表明，这还是个相当粗糙的半成品。内测功能目前只在美西 us-west-2 区域提供免费的候补名单，仅用于内部评估，不支持生产环境使用，也没有明确的上线时间和定价。从功能上看，它不支持自动扩缩容，没有 GPU，没有本地持久磁盘，连产品主页重点宣传的智能体代码执行沙箱，在这次内测里也还没有上线。 但为什么要在十月底发布一个没有自动扩缩容和智能体沙箱的功能呢？这背后其实有一个重要背景，就是 Supabase 当前唯一的服务端计算平台遇到了一个问题。之前开发者们写的无服务函数，是运行在开源的 Deno 上的。但在内测发布前十八天，Deno 的创始人发布了一份 Deno 团队并入 Cloudflare 的官方声明，整个团队随之并入边缘计算厂商 Cloudflare，后续的开发重点也会放在 Cloudflare Workers 和 Durable Objects 上。 该声明同时给出了 Deno 生态系统的停更倒计时：官方托管服务将在六个月后关停，开源的 Deno 运行时只再维持一年的漏洞修补与安全更新，一年期满后原团队将终止开发。自己的底层依赖突然归入竞争对手麾下，还挂上了一年停更的牌子，开发者社区立刻在 Hacker News 上追问 Supabase 接下来怎么办。 十月十日，一名 Supabase 员工在 Hacker News 上给出了公开回应。他表示，虽然 Supabase 的无服务函数是在公司自有的基础设施上运行的，并不依赖 Deno 的托管服务，但随着 Deno 在未来一年内不再进行活跃的维护和发展，他们正在加速开发一个名为 Compute 的下一代计算产品。Compute 不仅支持 Deno，还原生支持其他运行时环境，如 Node 和 Bun 等。官方计划在这一年的维护窗口关闭之前，为现有的无服务函数提供一个无缝迁移的路径，并将 Compute 作为未来所有新任务的首选方案。AI 长任务的兴起已经开始将客户推向其他平台，再加上底层依赖的停更，双重压力促成了此次十月底的抢跑。 ## 官方列的五类场景里，哪些是真刚需，哪些只是防流失的补丁？ 如果撇开商业防御不谈，这套工具用起来确实顺手。开发者升级命令行工具后，只需在配置文件 config.toml 里加一行 compute = true，选好 2GB 或 4GB 的内存规格，几秒钟就能把 Node、Deno 或带 Dockerfile 的任意语言目录推上线。每个服务跑在独立微虚拟机里，拥有完整 Linux 环境且无单次时长上限，自动拿到项目密钥与数据库地址，日志直接显示在控制台。 官方提供两种暴露模式：公开模式带有一个 HTTPS 网址，空闲时自动休眠，来请求时一秒内唤醒；私有模式不留公网入口，只在后台常驻运行，主动连接同一个项目里的数据库或外部服务。理解了这两种模式，就能看懂官方宣传的五种应用场景。 第一拨场景是面向语音智能体的 WebSocket 长连接、用 Dockerfile 部署的 Python 接口，以及协调多项任务的普通智能体。很多人奇怪实时语音和数据库有啥关系，其实它跟数据库引擎毫无关系，纯粹是给自家无服务函数的四百秒超时限制打补丁。不少用 Supabase 全家桶的团队在做实时语音助手，需要后端维持一条不断开的双向长连接来中继音频流，顺手校验一下用户登录态。以前把这段代码放进无服务函数，用户聊到六分四十秒电话就会突然断掉，逼得开发者全跑去外部平台买容器。现在提供不断连的公开容器，干的其实就是防客户流失的活。 第二拨场景是从 Postgres 拉取任务的持久队列处理器，以及持续运行好几个小时的数据同步与向量回填。这两件事才是真正贴着数据库的刚需。想象一下，你的数据库里躺了几十万条历史文本，现在要调外部大模型接口，给每条数据重算一遍向量并写回表里。关系型数据库平时的职责是响应外部发来的读写查询，如果在数据库内部直接发起几十万次外部网络请求，不光会占满连接池，也没法处理接口限流、超时重试和断点续传；可要是放进无服务函数里，跑上六分多钟又会超时掐断。放一个私有模式的常驻容器在数据库内网里跑上几个小时，才真正帮免后端团队补上了批处理的缺口。 ## 把代码搬到离数据库两三毫秒的地方，到底能换来什么真收益？ 如果你的应用只是偶尔查一下表，大部分时间都在等外部的 AI 模型吐出文字，那把容器搬进机房也几乎感受不到延迟差别。真正能把同机房内网红利吃满的，是高频读写数据库、成批吞吐表记录的数据分析智能体。 在十月初，Dreambase 这个数据分析团队分享了他们的迁移实测报告，具体记录了网络延迟和数据吞吐的变化。由于此前 Supabase 不支持长任务，他们以前只能在外部平台部署数据智能体。此外，为了不在自己的服务器上复制客户的数据库，同时避免慢查询影响客户的生产主库，每次智能体回答问题都需要经过一系列复杂的步骤。每次调用 Claude Opus 5.5 模型来处理运营问题，程序都需要通过公网探测表结构并拉取数据，在内存分析引擎 DuckDB 中创建一个临时的数据快照，然后在快照上执行分析查询，最后将数据集存回客户的存储空间中。 他们在四十二万条事件记录的测试库上做了几轮对比。以前从外部跨区域走管理接口查一次表要六百多毫秒，跨区域直连数据库也要 65 毫秒，而从同区域的 Supabase Compute 直连 Postgres，中位查询延迟只有 2.9 毫秒。因为智能体答一道题要连发十几次查询，单次省下的延迟叠加起来，让等待数据的时间从近五秒压到一秒以内。 更重要的是同机房内网的高吞吐能力。在 Compute 容器内，他们把全部四十二万条事件记录从 Postgres 拉进内存 DuckDB 建一个快照，只花了 1 秒和 65MB 内存，把结果存回同项目存储空间的时间也从三秒多缩到眨眼之间。后续分析全在内存快照里完成，既隔绝了慢查询拖垮客户主库的风险，又保证所有数据全程留在客户项目边界内。 同机房内网将查库延迟压到 2.9 毫秒并实现 1 秒内存快照后，团队得以简化查询流程，将单题回答耗时缩短近一半且完全隔离生产主库。 在查库延迟降到两三毫秒、打快照只需一秒之后，智能体的查询工作流也随之变轻。以前跨公网拉数据太慢，程序为了减少往返，只能先凭表结构盲猜需要哪些字段，提前规划好再去建快照，平均每道题要折腾七八步；现在数据在手边，智能体可以直接发只读 SQL 快速探路，找准答案后再按需给支撑数据打快照，不仅每次少走了约四分之一的步骤，还把单题中位回答时间从半分钟砍到了十六秒左右。至于报告里同时宣称大模型调用成本降了近五倍，那其实混入了迁移时顺手删减无关工具等其他重构因素，并不能全算在内网直连头上。 当然，这个私有内测的工具还有很多功能限制。比如它没有本地持久化的磁盘，可能会随时重启，长任务需要实时保存中间状态到 Postgres 中。内测版本还没有实现按服务隔离密钥和出站防火墙，每个容器都默认可以拿到整个项目的密钥。如果你已经有成熟的基于容器的后端环境，并且主要做对外部接口的调用，那也不需要折腾。但如果你是纯前端配 Supabase 的免后端团队，或者在做高频把几十万行的表拉进内存折腾的数据智能体，这才是真正能帮你省心省事的拼图。