这两个名字几乎在我们每个产品里都出现。简单说：Vercel 管「网站怎么上线、怎么跑」，Supabase 管「数据存哪、谁能动」。一个负责门面与运行，一个负责仓库与账本，拼起来，一个小团队不用自己买服务器、不用养运维，就能做出完整的线上产品。本文从来历讲到能力全景，再落到——我们到底用了哪些、哪些还没用上、为什么。
先用一张图把两者摆清楚。它们不是竞争关系，而是一前一后的搭档：
你写好的网站代码，一推送，它就帮你部署上线，自动配好网址、HTTPS、全球加速。还能跑一些轻量后端逻辑（接口、定时任务）。
类比：开店的「门面 + 后厨 + 收银台」——顾客看到的、点单跑腿的，都归它。
一个开箱即用的数据库（PostgreSQL），外加现成的登录、文件存储、实时推送等后端能力。数据长期存哪、谁能读写，都由它管。
类比：店铺的「仓库 + 账本 + 保险柜」——东西存这、谁能动有规矩。
了解来历不是考古，而是能帮你记住它们最擅长什么——一个产品的「出身」往往决定了它今天最强的那块肌肉。
创始人 Guillermo Rauch（也是开源框架 Next.js 的作者）。最初的卖点极简：开发者敲一行 now，就把网站推上线，不用碰服务器。
从「部署工具」升级为「前端 / 全栈云平台」。因为自家就做 Next.js，所以 Vercel 上跑 Next.js 的体验是全行业最顺的——这也是我们几乎所有 Web 项目用 Next.js + Vercel 的根本原因。
Firebase 是 Google 的后端服务，好用但封闭、且不是关系型数据库。Supabase 反过来——底子用最成熟、最通用的 PostgreSQL，在它外面包一圈现成能力。
登录鉴权、文件存储、实时推送、自动生成的 API、向量搜索……都围着那个 Postgres 数据库长出来。开源、可自托管，数据始终是标准 SQL，迁走也不被绑死。
下面是它们各自对外提供的能力全景（不是我们用了多少，是它们「能干」多少）。先有这张地图，第 4、5 章「我们用了哪些 / 没用哪些」才看得明白。
不是所有项目都该用这套，但对我们这种「小团队、要快、不想养运维」的情况，它几乎是默认答案。典型适配场景：
面向用户的 Web 产品 / 官网 / 后台、需要数据库存账号与业务数据、要频繁迭代上线、团队人少没专职运维。—— 我们的产品基本都在这一类。
需要长时间运行的重后台 / 常驻进程（如挂着浏览器自动化、跑大模型）、对单机性能 / 成本有极致要求的场景——这类我们会放到 Fly.io 这种能跑常驻服务的地方。
所以在我们这，常见的分工是三层：
这也是为什么很多功能要「绕一下数据库」——不同机器之间，靠 Supabase 这张共享账本交接。这一点单独有一篇讲：自动回复为什么要「绕」数据库 →
把上面两个工具箱拿过来，勾一遍我们实际用到的。✅ 在用 ◐ 部分项目用 ○ 基本没用
| 能力 | 我们怎么用 | 状态 |
|---|---|---|
| 部署托管 | 所有 Web 项目（含 upio.ai 这个站本身）都靠它：推代码 → 自动上线，约一分钟生效。 | ✅ 在用 |
| 预览环境 | 改动先在临时网址看效果、给团队 review，确认了再合并到正式站。 | ✅ 在用 |
| Serverless 函数 | 产品的后端接口（API 路由）大量跑在这——例如某个产品就有几十个接口。 | ✅ 在用 |
| Cron 定时任务 | 重度使用。我们的获客类产品里有几十个定时任务（巡检、跑批、生成）都挂在 Vercel Cron 上。 | ✅ 在用 |
| 全球 CDN / 图片优化 | 跟着 Next.js 默认就吃到了，基本「免费白拿」，没特意配。 | ✅ 在用 |
| 能力 | 我们怎么用 | 状态 |
|---|---|---|
| Postgres 数据库 | 核心中的核心。所有业务数据——用户、聊天记录、任务状态、跑批结果——都存这。多个产品各有自己的库。 | ✅ 在用 |
| 「中转台」用法 | 不同机器（云端服务器、云电脑、Fly 后台）之间靠它交接：一方写进表，另一方读出来接着干。数据库是它们的「公共信箱」。 | ✅ 在用 |
| 状态机 + 审核闸 | 给每条记录打状态（待处理 / 可发 / 等人工）。比如 AI 生成的回复草稿先存库、过一道安全闸，敏感的拦下来等人看，不直接发。 | ✅ 在用 |
| Auth 鉴权 | 看项目——有的产品直接用 Supabase 登录体系，有的自建。不是全员统一。 | ◐ 部分项目 |
「没用上」不等于「该用没用」。大多数是当前用不到，或我们用别的方式解决了。知道它们在那，等需要时能想起来，就够了。
| 能力 | 为什么没用 | 状态 |
|---|---|---|
| 存储类 Blob / KV | 文件和数据我们统一放 Supabase / 别处，没必要再开一套 Vercel 自己的存储，避免数据散落。 | ○ 没用 |
| AI Gateway | 我们调大模型走 OpenRouter（统一入口、比价、容灾）已经够了，没叠 Vercel 这层。 | ○ 没用 |
| Edge / 中间件 | 大部分逻辑放普通 Serverless 函数或 Fly 后台就够，边缘计算的低延迟需求还没到。 | ○ 没用 |
| Firewall / 微前端 | 防护规模没到、团队也不大，这些「大厂级」能力暂时用不上。 | ○ 没用 |
| 能力 | 为什么没用 / 替代方案 | 状态 |
|---|---|---|
| Realtime 实时 | 本可以「数据一变前端立刻知道」，但我们多数场景用定时轮询（每隔几分钟醒一次去查）就够，简单、可控、好排障。 | ○ 没用 |
| Storage 文件桶 | 目前文件类需求不多，或放在了别的地方，没专门用它的对象存储。 | ○ 没用 |
| Edge Functions | 后端逻辑放 Vercel 函数或 Fly 后台，没必要再在 Supabase 侧跑一套。 | ○ 没用 |
| Vector 向量搜索 | 还没做语义检索 / RAG。等要给 AI 接「长期知识库」时，这是第一个会启用的能力。 | ○ 未来候选 |
| Queues 队列 | 用「数据库状态字段 + 定时轮询」土法实现了排队效果，量级没大到非上专业队列。 | ○ 没用 |
| Branching 分支 | 改库直接走迁移脚本，团队小、协作冲突少，还没到要数据库分支的复杂度。 | ○ 没用 |
不用记那一长串功能名。把这页浓缩成一行，以后听到这两个词，脑子里浮现这句就够：