如果只维护 1–2 个长期项目，而且需要 Auth、RLS、Realtime、Storage 这些能力紧密配合，Supabase 更省心。
如果同时维护多个 side project，核心需求只是 Postgres，愿意把鉴权、媒体存储拆开选择，Vercel + Neon + Cloudinary + Auth.js 的组合通常更灵活，也更容易控制固定成本。
这次对我最有用的不是记住某个产品的价格，而是意识到：免费额度的真正瓶颈不一定是流量，也可能是项目数量、存储方式或某个必须付费的能力。
最开始是在给 dreamlydia 个人作品集网站选后端方案。
当时我已经有两个长期在线的项目使用 Supabase。它们本身都没有达到很高的数据库或流量用量，但已经占满了免费档允许的两个活跃项目。
第三个项目如果继续使用 Supabase，就会因为"项目数量"而进入付费，而不是因为业务量真的增长到了需要付费的程度。
这让我把选型问题从"Supabase 和 Neon 哪个更好"改成了几个更具体的问题：
把这些约束拆开以后，选择反而简单很多。
定位：Postgres + Auth + Storage + Realtime + Edge Functions 的 all-in-one 后端平台。
当时的价格与限制：Free 是 $0，最多 2 个活跃项目，项目 7 天没有访问会自动暂停；Pro 是 $25/月起，包含第一个项目，额外项目需要继续增加费用；Team 是 $599/月起。
Supabase 最大的优势不是单独某项能力最强，而是这些能力已经被放在同一套系统里：Postgres 数据库、Auth、Storage、Realtime、Edge Functions、Row Level Security（RLS）。
其中 Auth 和 RLS 的结合尤其省事。用户身份和数据库权限可以直接在数据库层建立关系，不需要自己再拼一套权限系统。
如果产品有多人协作、实时状态同步之类的需求，Realtime 也可以直接使用，不需要额外接另一项服务。
我踩到的真正瓶颈：项目数量。 对个人开发者来说，Supabase 免费档最容易忽略的限制不一定是数据库容量，而是 2 个活跃项目。我当时两个已经上线、需要长期维护的项目正好把额度占满。dreamlydia 作为第三个项目，即使几乎没有流量，也会因为"项目数"进入新的成本区间。
这和"项目做大以后为更多资源付费"是两回事。前者的成本来自你同时维护多少个项目，而不是某个项目到底用了多少资源。对于喜欢持续做 side project 的人，这个维度很值得提前看。
更适合的情况：手上只有 1–2 个长期项目；希望数据库、鉴权、存储尽量集中在一个平台；需要 Realtime；需要 Auth + RLS 深度绑定；更重视省配置和维护，而不是把每一块成本压到最低。
定位：Serverless Postgres。
Neon 和 Supabase 不是完全同一种产品。它主要解决数据库这一层，不负责帮你把 Auth、Storage 和 Realtime 一起打包。
当时的价格与限制：Free 是 $0，一个 organization 下最多 100 个项目，每个项目包含 100 CU-hour/月计算额度、0.5GB 存储、5GB 出网流量；Launch / Scale 按实际用量计费，不以固定月租作为主要门槛。
Neon 对我最大的吸引力不是某个数据库性能指标，而是免费档允许的项目数量非常宽松。如果同时维护很多小项目，大部分项目本身用量很低，那么"100 个项目"与"2 个项目"的差别非常实际。
它还有几个对个人开发比较友好的特点：无访问时可以 scale-to-zero；支持数据库 branching，可以像 Git 分支一样为不同开发环境创建数据库分支；和 Vercel 集成顺畅；@neondatabase/serverless 可以通过 HTTP 适配 Serverless / Edge 环境。
数据库分支对我个人项目不是刚需，但如果以后多人协作、PR 预览环境越来越多，这个能力会更有价值。
代价：需要自己拼完整后端。 Neon 只负责 Postgres，因此其他能力需要另外选择：Auth → Auth.js；图片 / 视频 → Cloudinary；Realtime → 需要其他方案。这会增加一点集成工作，但好处是每一层都能独立替换，不需要为了数据库一起购买其他暂时用不到的能力。
更适合的情况：同时维护多个 side project；需要标准 Postgres；项目部署在 Vercel；主要需求是数据库，不依赖 Supabase Realtime；愿意自己组合 Auth、Storage 等服务；希望固定成本尽量低。
定位：图片 / 视频上传、处理、转码和 CDN 分发。
Cloudinary 在这套组合里承担的是媒体层，而不是普通文件存储。
当时的价格：Free 是 $0，不需要信用卡，每月 25 credits，1 credit 可以对应约 1000 次图片 / 视频转换，或 1GB 存储，或 1GB 视频带宽，不同消耗可以混合计算；Plus 是 $89/月起，225 credits。
个人作品集里图片和短视频很多，但我不想为了上传、裁剪、格式转换、压缩和 CDN 再自己做一套后端。Cloudinary 比普通对象存储多了一层媒体处理能力：浏览器可以通过 unsigned upload preset 直接上传；图片和视频可以走同一套 /auto/upload 逻辑；上传结果会返回尺寸信息；URL 参数可以直接做裁剪、压缩和格式转换；CDN 分发已经包含在服务里。
对 dreamlydia 这种低流量、媒体较多的个人站点，这比自己搭上传接口和图片处理管线省事很多。
需要留意的地方：25 credits 对小型作品集网站通常够用，但视频的存储、转换和带宽消耗会明显快于普通图片。所以媒体服务的瓶颈和数据库又不一样：不是项目数量，而更可能是存储、转换次数和视频流量。
定位：前端与 Serverless 部署平台，尤其适合 Next.js。
当时的价格与免费额度：Hobby 是 $0，面向个人 / 非商用项目，包含约 100 万次 Edge 请求、100GB 数据传输、100 万次函数调用等免费额度；Pro 是 $20/月起。
对个人项目来说，我更在意部署流程能不能足够简单：Git push 自动部署；PR / 分支自动生成预览环境；Serverless Function 开箱即用；Next.js 基本零配置；可以直接连接 Neon 等生态服务。
只要项目仍然属于个人、非商用、低到中等流量，Hobby 档的成本压力很低。真正需要重新评估的节点，是项目开始商用、团队协作增加，或者函数调用和带宽明显增长以后。
当数据库从 Supabase 换成 Neon 后，Auth 也需要独立解决。
我最后使用 Auth.js，不是因为它能完全替代 Supabase Auth，而是因为当前项目并不需要 Supabase 那种 Auth + RLS + Realtime 的深度整合。
对个人作品集这类产品，鉴权需求相对简单，把 Auth 独立出来以后，数据库就可以自由选择 Neon，而不必为了 Auth 继续锁定一整套 BaaS。
这个思路的前提是：先确认自己是不是真的需要平台级深度整合，再决定要不要为了"省一项集成"使用 all-in-one。
| 组合 | 更适合的情况 | 主要取舍 |
|---|---|---|
| Vercel + Supabase | 1–2 个长期项目，需要 Auth / RLS / Realtime，希望一站式 | 集成成本低，但多项目时项目数量会更早成为成本 |
| Vercel + Neon + Cloudinary + Auth.js | 多个 side project，需要 Postgres，媒体较多，希望控制固定成本 | 需要自己拼服务，但每层更独立，项目数量更宽松 |
我自己的实际使用也是两套并存：已有的长期产品继续使用 Supabase；dreamlydia 这种新的个人项目则采用 Neon + Cloudinary + Auth.js，再部署到 Vercel。
1. 免费额度卡的是"用量"还是"项目数量"？ 很多时候我们只看数据库容量、带宽和请求数，却忽略项目数量本身也可能是计费维度。如果你只维护一个项目，Supabase 的 2 项目限制几乎没有影响；如果你同时有 5–10 个小产品，它可能比数据库容量更早成为问题。
2. 哪些能力真的需要绑在一起？ 如果 Auth、RLS、Realtime 本来就高度相关，拆开反而会增加大量集成成本。如果项目只是需要一个数据库、一套简单 Auth 和媒体上传，那么全部绑定在一个 BaaS 上未必有必要。
3. 媒体是不是产品的重要资源？ 图片 / 视频较多时，Cloudinary 这类专门媒体服务能省掉大量处理逻辑。但如果只是偶尔上传几个普通附件，用独立媒体平台可能反而过度。
4. 我愿意承担多少"拼服务"的成本？ all-in-one 的价值是真实存在的：少账号、少配置、少连接层、少出错点。模块化方案省下的可能是钱，但会增加集成和维护关系。所以不能只算月费，也要算自己的开发时间。
5. 项目未来最可能先在哪个维度增长？ 项目数量增长 → 更关注每项目固定成本；协作需求增长 → 更关注 Realtime、权限和预览环境；图片 / 视频增长 → 更关注媒体带宽和处理额度；用户与业务增长 → 更关注 Auth、数据库性能和商用套餐。
选型时如果知道最可能先撞到哪堵墙，就不需要为所有未来情况同时做准备。
Supabase：项目数比流量更早撞墙。 我原来默认"免费额度用完"应该意味着项目做大了。实际上第三个项目还没什么流量，就因为已有两个长期项目而需要考虑付费。这让我之后看任何 SaaS 免费档都会专门检查：它限制的是资源，还是资源容器的数量。
Neon：拆开以后，别忘了你还缺什么。 从 Supabase 切到 Neon 很容易只看到数据库价格，却忘了 Supabase 原来还替你做了 Auth、Storage、Realtime。比较成本时要比较完整系统，而不是单独比较数据库这一行。
Cloudinary：免费视频不等于视频没有成本。 个人站点图片通常很轻，但视频会同时消耗存储、转换和带宽。作品集一旦大量放自动播放视频，25 credits 的消耗速度需要单独观察。
模块化方案的隐性成本是集成。 Neon + Auth.js + Cloudinary 在现金成本上很友好，但连接关系、环境变量、权限和故障排查都比 Supabase 一体化方案多。如果项目本身很小，而且只有一个，省下的月费未必值得额外的维护复杂度。
我现在不会再问"Supabase 和 Neon 哪个更好"。
更有用的问题是：这个项目需要哪些能力？这些能力有没有必要绑在一个平台？我同时会维护多少个项目？我最可能先在哪个计费维度撞墙？
对于个人开发者，技术栈的"性价比"不是单纯选最便宜的服务，而是在 现金成本、集成复杂度、维护时间和未来增长方式 之间找到最适合当前项目的一点。