Convex：把 Firebase 该有的样子做出来的实时全栈后端

Convex 是一家近年在开发者社区热度上升很快的全栈后端（BaaS）创业公司，其定位被 Koala 点评为「Firebase 该有的样子」：用纯 TypeScript 同时定义数据库 schema、查询与 API，前端通过 React hooks 自动订阅数据变化，开发者既不用手写缓存失效逻辑，也不用手动维护 WebSocket。2026 年以来它与 Supabase 在社交平台上的公开对立进一步抬高了关注度。本文基于 Convex 官网与官方定价页的一手阅读，对其架构、计费与局限做一次克制的分析。

一、背景动机：BaaS 的第二代

Firebase 等第一代 BaaS 解决了「后端从零搭建太慢」的问题，但长期被诟病三点：SDK 老旧、锁定在专有生态、实时能力与关系型数据模型之间存在割裂。Convex 的叙事正是针对这三点：数据库、函数、工作流、同步、搜索、文件存储全部内建，且统一在 TypeScript 这一套语言里，官方口号是「All TypeScript, zero glue（全是 TypeScript，零胶水）」。

从团队背景看，Convex 的两位创始人都来自 Dropbox 大规模存储体系：CEO Jamie Turner 曾任 Dropbox 存储、数据库与业务平台工程高级总监，更早是被 Google 收购的 Bump 的工程负责人；CTO James Cowling 曾任 Dropbox 首席工程师，是把 Dropbox 数据迁出 S3 的 EB 级存储系统的技术负责人。官方强调「我们在 EB 级规模上学会了如何构建和运行分布式系统，所以你不必学」——这是其向企业客户售卖信任的核心论据。

二、是什么：一个「反应式」后端

Convex 把自己称为 reactive backend platform（反应式后端平台）。与传统「前端发请求、后端返回一次性数据」的模型不同，Convex 的查询是反应式的：前端订阅一个查询函数，当底层数据被任何写入改变时，Convex 会自动把最新结果推回前端，缓存与失效由平台处理。官方列出的四个「解决掉的最难问题」是：

• ACID 事务：保证并发写入不会损坏数据；
• 端到端类型安全：数据库 schema 与函数类型一路传到前端组件，官方称这能在上线前拦截 agent 的幻觉（类型错误）；
• 自动缓存与弹性伸缩：「火了也不会被打挂」；
• 实时同步：用户立即看到最新数据。

生态上，Convex 推 Components 概念——沙箱化、开源的可复用模块，例如 Workpool（把模型调用与后台任务 fan-out 到托管池，自带重试、退避与并行）、Workflow（多步流程带 checkpoint、可重试、可恢复）、Agents（内置线程、上下文与向量检索）。这些组件直接面向 2026 年的 AI 应用负载设计，是它区别于传统 BaaS 的重要信号。

三、计费模型：按席位 + 按用量

Convex 的定价分三档，官方定价页（2026-09 实读）如下：

在 Professional 档（美国东部 N. Virginia 区，1.0x 系数），用量额度为：函数调用每月含 2500 万次，超出每百万次 $2；查询/变更计算免费；Action 计算含 250 GB·小时，超出 $0.30/GB·小时；数据库存储含 50 GB，超出 $0.20/GB；文件存储含 100 GB，超出 $0.03/GB；搜索存储含 1 GB，超出 $0.50/GB。并发上限方面，Professional 档为 10,000 并发会话、256 并发查询、512 并发 Action，部署类型为 serverless、部署类 S256、部署上限 300 个。

这套定价的特点是「席位费打底 + 用量计费叠加」。对小团队而言 $25/人/月并不贵，但函数调用与存储是随业务线性增长的：一个日活较高的多用户应用，2500 万次函数调用很快会触顶，之后每百万次 $2 的溢出费需要纳入成本模型。

四、官方自己标注的口径偏差与局限

读官方页面时必须区分「官方称」与「已核实」，尤其注意页面上自己标注的未完成项：

1. Analytics engine（分析引擎）在 Professional 档标注为「SOON」，即尚未 GA，却已出现在高级功能清单里；
2. Custom roles（自定义角色）在 Professional 档明确标「No」——虽然 Professional 已包含 RBAC，但细粒度自定义角色要等到更高档；
3. SAML/SSO、Service SLA、Fast backup/restore、BYOC 在 Professional 档均为「No」，只有企业档（$2,500/月起）才提供；
4. Professional 档不按 CPU 时间计费（CPU-time pricing: No），意味着成本主要由函数调用次数与 Action GB·小时决定，重计算型负载的账单可预测性需要自行压测。

此外，Koala 点评中提到的两点并非官方口径、而是社区共识层面的风险，需要单独标注：作为托管服务，长期成本随规模上升，以及数据迁出（vendor lock-in）成本——Convex 的数据模型与函数都绑定在其托管运行时上，迁移到自建 Postgres/Supabase 并非简单导出即可完成。

五、适用与不适用场景

适合： 快速原型到中小型生产应用、实时协作类产品（多人编辑、仪表盘、社交 feed）、大量调用 LLM/Agent 的工作流型应用——Workpool/Workflow 组件正是为这类负载设计；重视端到端类型安全、想砍掉后端胶水代码的 TypeScript 团队。

不适合： 需要 BYOC、自托管或严格数据驻留的大型企业（要等企业档且无 BYOC）；计算密度极高、希望按 CPU 时间精细计费的批处理负载；对锁定极度敏感、预期未来要迁出的项目。

六、客观分析：优势与意义

优势： 创始人在 Dropbox EB 级存储的工程背景是真实背书；类型安全贯穿前后端的开发体验确实丝滑；实时同步、工作流、向量检索开箱即用，与 AI Agent 负载的契合度高于传统 BaaS。

局限： 仍是闭源托管服务，无 BYOC、无自部署版本；Pro 档缺失 SSO/SLA/自定义角色；分析引擎尚未 GA；定价随用量增长的长期成本需要提前建模。

Convex 的意义在于：它证明了 BaaS 这一品类在「AI 原生应用」时代仍然有生命力——只是卖的不再是「少写后端」，而是「让前端和 agent 都能直接、类型安全地操作一个会自动同步的数据库」。对正在 Supabase、Firebase、Convex 之间做选型的团队，建议先用 Free 档把一个真实实时页面跑通，再用上面的资源价目表估算自己负载下的月度账单，而不是只看 $25/人/月这个数字。

参考来源

• Convex 官网
• Convex 官方定价页
• Koala 项目库条目：Convex