托管后端即服务的入门套餐每月几百元，而一台能跑起全套开源 BaaS 的服务器月付一两百就能开机，这笔账看上去毫无悬念。真正的转折发生在上线三个月之后：用户上传的图片把对象存储堆到几百 GB，实时订阅把长连接数吃满导致新用户连不上，某个月的出网流量跑了几个 TB 才被机房账单提醒，再加上一次半夜的数据库故障——没人值班，第二天早上才有人发现。订阅费确实省下来了，但它换来的不是零成本，而是一整套原本由托管方承担的资源画像、故障模式和值班责任。这篇文章只算这一笔账，不谈怎么用、也不谈低代码。
把 Supabase 这类开源 BaaS 套件的自托管编排文件打开，会看到十来个容器。它们对外是一个"后端"，对内是六种完全不同的资源消耗方式，混在一台机器上时互相抢的是不同东西。
整个套件的数据底座通常是一个 PostgreSQL 实例，业务表、对象存储的元数据、认证的用户表、实时订阅的权限判定都落在同一个库里。它的瓶颈很少先出现在 CPU 上，而是先出现在连接数、缓冲区命中率和写放大上。PostgreSQL 默认的最大连接数在多数发行版里是一百上下（公开渠道参考值，实际需结合版本与业务模型确认），每个连接在服务端是一个独立进程，即使空闲也会占住一份内存。这意味着"CPU 还有 70% 空闲、内存还剩 4G"和"数据库已经连不上了"可以同时成立。
认证服务负责签发 JWT、校验密码、处理 OAuth 回调、发验证邮件和短信。密码哈希是刻意设计的慢操作，注册和登录高峰时它消耗的是 CPU 而不是带宽；邮件和短信则要依赖外部通道，一旦第三方限流，注册链路就断了。这块资源的曲线是"脉冲型"的：平时几乎为零，营销活动一上来就尖峰。
存储服务本身是一个 S3 兼容的文件网关，文件落在本地盘或挂载的卷上，元数据写回数据库。它对磁盘是顺序写、对数据库是行数增长。很多团队在规划时按"用户上传总量"估容量，最后却发现容量从来不是问题，出网才是——文件存进去只花一次，读出去会被重复收费。
实时服务通常基于 WebSocket 长连接运行，每个在线客户端对应一条常驻连接。它的资源模型是"每个连接一份固定开销乘以连接数"，与消息量关系不大：一万条连接安静地挂着，内存和文件描述符照样被占满。这类服务属于典型的"连接密集型"负载，和数据库、存储的扩容逻辑完全不同。
自动生成的 REST 层把数据库表直接映射成 HTTP 接口，边缘函数则提供一段可运行的沙箱。前者是轻量转发，后者是突发 CPU——一次批量导入、一次报表生成能把整机的 CPU 打满几十秒。如果函数和数据库同机，这段时间数据库也在被拖慢。
连接池是自建部署里几乎必装又最容易配错的一层，它决定了应用实际能用多少条数据库连接；后台管理界面本身不重，但它常常是唯一暴露在公网的管理入口，安全加固的成本不在资源层面而在运维层面。加上日志采集、备份任务、监控代理，一台"能跑起来"的机器其实在跑十几个进程，各自有自己的峰值时刻。
自建 BaaS 遇到的第一个真实故障，通常不是磁盘满了，也不是 CPU 飙高，而是日志里反复出现的连接耗尽报错。原因很直接：套件的每个组件都要连数据库，而连接是有限资源。
直连模式下，每个应用请求占用一条数据库会话，直到请求结束才释放。并发一上来，连接数就线性增长。池化则把连接复用起来：事务模式池在一条 SQL 事务结束时就把连接交还，会话模式池则在整个客户端会话期间持有连接。前者能把很低的连接数支撑起很高的并发，代价是不支持依赖会话状态的能力——预编译语句的会话级缓存、监听与通知、会话级咨询锁、临时表等，这些在事务池下会失效或报错。所以正确的划分是：无状态的自动 REST 查询走事务池，管理后台和需要会话特性的管理操作走直连，认证服务这类有会话语义的组件单独给一小段直连配额。
连接耗尽可能发生在三个地方：应用侧的连接池上限、数据库的最大连接数、以及操作系统层面的进程与内存约束。盲目把数据库最大连接数调高是最常见的错误做法——连接数上去之后，内存占用和上下文切换跟着涨，反而更容易把实例拖垮。真正该做的是先量出峰值并发下的实际连接需求，再决定是加池还是加连接。
基础备份加 WAL 归档是时间点恢复（PITR）的标准做法，它的成本不是一次性的。假设库体积 50GB，每天一份全量保留 7 天，光全量就是 350GB；再叠加 WAL——WAL 的量等于写入量，一张被高频更新的表会在短时间内产生远大于自身体积的 WAL。很多团队把备份放在同一块盘上，最后备份先于业务把盘写满。更稳的做法是备份落独立卷或独立机，并明确保留窗口和清理策略。
PostgreSQL 的自动清理负责回收死元组，高频更新的表会持续产生死元组，触发清理线程占用 IO；如果表的规模增长后仍沿用默认的清理阈值，清理会跟不上，表膨胀、查询变慢。索引则是另一面：每个额外索引在写入时都要维护，索引越多写越慢。这两项都不会体现在"配置够不够"的判断里，但决定了长期运行时的 IO 余量，也是同机部署时最容易被数据库抢占的资源。
对象存储是自建 BaaS 里最容易被低估的一项，因为它的计价直觉是错的。团队本能地按"用户会上传多少 GB"去规划磁盘，但磁盘是整个链条里最便宜的一段。
用户上传一张 3MB 的原图，系统通常会生成列表缩略图、详情页中图、移动端小图，甚至再加一张webp 版本。如果业务还涉及视频转码、PDF 预览、报表导出、数据备份下载，派生文件的总量可以轻松达到原始文件的二到三倍。更麻烦的是这些文件往往是"自动生成、从不清理"的：原图删了，缩略图还留着；转码失败了一半，中间产物还在盘上。
上传流程若分为"先传文件，再提交业务记录"两步，中途放弃的上传就变成没有任何业务引用的孤儿对象；软删除则让文件在数据库里标记为已删，实际仍占空间。这两类文件不会出现在任何业务统计里，只会在磁盘告警时才被发现。识别办法是定期比对存储目录的实际对象清单与数据库元数据表，把差值列出来人工确认后再清理。
海量小文件的问题不在容量而在元数据：inode 消耗、目录遍历、随机读。一个装了几百万个几十 KB 文件的盘，即使只用了三成容量，备份和 fsck 的时间也可能长到不可接受。缩略图这类场景尤其典型，建议按哈希做分层目录，避免单目录文件数过大。
可靠的做法是给对象存储划出明确的生命周期规则：临时上传目录保留固定天数后强制清理，派生文件可标记为可重建（丢了能重新生成，因此备份优先级最低），归档类文件移到低频存储。判断标准很简单——能重建的文件不需要进备份，不能重建的文件必须有多份副本。这条规则能把备份体积压下来一大截。
实时订阅是自建 BaaS 里最"不像 Web 服务"的一块，它的容量规划方法和数据库完全不同，用请求量去估一定估错。
每条 WebSocket 连接在服务端对应一个常驻的执行体，占用一份内存和至少一个文件描述符。内存消耗随连接数线性增长，与这段时间有没有消息无关。因此实时服务的内存规划应该按"峰值并发连接数乘以单连接开销"来算，而不是按日活或 QPS 算。单连接开销在不同实现与配置下差异很大，属于公开渠道参考值，实际需结合自身业务模型与实测确认。
默认的文件描述符上限在很多发行版里是一千出头，这个数字在实时服务面前几乎立刻就会被撞到。需要同时调整进程级和系统级的上限，还要留意内核的连接队列与本地端口范围。这类参数不调，服务会在看起来很健康的资源水位下直接拒绝新连接，故障现象是"新用户连不上、老用户正常"，非常容易被误判成应用 bug。
房间模型下，一条变更要推送给房内的每个订阅者，序列化与写出都是按订阅者数量重复执行的。一个两千人的在线房间，一条消息就是两千次写出。因此真正决定实时服务上限的往往不是总连接数，而是"单个频道的人数乘以消息频率"。产品设计上限制频道规模、对高频变更做合并与节流，比扩容更划算。
服务重启或网络抖动之后，全部客户端会在几乎同一时刻重连，形成惊群：瞬时连接请求远超服务端的接纳能力，进而把认证和数据库也一起拖住，导致恢复时间被拉长。成熟的客户端实现应当带指数退避和随机抖动，服务端侧则要有限流与排队。自建部署需要自己确认所用的客户端 SDK 是否具备退避策略，这一点托管服务通常在 SDK 里已经处理好。
如果只能提醒一件事，那就是出网。本地开发时几个人访问，出网可以忽略；上生产之后，出网往往成为账单上增长最快的一行，而且它和 CPU、内存、磁盘容量完全无关，加到配置也解决不了。
几个常见来源叠加：图片和视频未经 CDN 直接从源站返回；API 响应没有压缩也没有分页，一个列表接口返回几百 KB；健康检查、监控抓取、搜索引擎爬虫持续请求；备份同步到异地机房；日志与镜像拉取。这些单项都不起眼，但都以"月"为单位累积。判断方法是在源站上按路径统计出网字节数，把前几名列出来，通常会发现一两个接口贡献了大部分流量。
引入 CDN 之后，出网被分成两段：命中 CDN 的部分由 CDN 出网，未命中的请求回源，产生源站出网。这里最常见的误判是用"请求命中率"评估效果——正确的指标是字节命中率，即命中字节数占总出网字节数的比例。一个站点可能 95% 的请求命中，但那 5% 的未命中请求全是大文件，字节命中率只有 40%。真正和源站账单相关的是字节命中率。提升它的手段包括：给静态资源设置较长的缓存有效期并在文件名或查询参数上做版本化，避免大文件被频繁回源；确认 CDN 是否对大文件做分段回源，避免一次未命中导致整个大文件从源站拉取。
机房给出的"带宽"至少有三种口径：峰值带宽（按端口速率上限）、保底带宽（按承诺速率计费、超出另算）、按流量（按月度累计出网字节数计费）。同样的业务，在这三种口径下的成本差异可以非常大。还需要问清入方向是否计费、内网流量是否计入、CDN 回源流量是否单独计量。这些不是技术细节，而是直接决定账单形态的条款。
前面四笔账都能用钱买资源解决，第五笔不能。它会持续消耗团队里最贵的人力，而且组件数量越多，它的增长越接近非线性。
自托管套件通常由多个独立项目组合而成，各自有各自的发布节奏。升级不是执行一条更新命令那么简单：需要先在影子环境完整跑一遍，确认数据库迁移脚本、配置文件格式、环境变量命名没有变化，再选低峰窗口切换。跳过影子环境直接升级，是自建部署最常见的自伤方式。
备份任务显示成功只说明文件写出来了，不说明它能恢复。真正有价值的动作是定期做恢复演练，把备份还原到一台独立机器上，量出实际耗时，确认恢复出来的数据完整性和时间点是否符合预期。演练频率取决于业务的数据变更速度，高频写入的系统应当更频繁；至少要在每次重大版本变更之后做一次。
托管服务里，半夜数据库挂了有对方的值班工程师；自建之后，这个角色落回团队自己。这不只是"辛苦"的问题，而是恢复时间的问题——没人第一时间响应，故障时长就从分钟级变成小时级。如果团队没有轮值安排，自建的第一年大概率会经历一次较长的不可用。
操作系统补丁、数据库小版本、容器镜像的依赖漏洞、TLS 证书轮换、密钥与令牌的存储与更换，这些都属于持续性工作。其中数据库和操作系统补丁需要重启窗口，实时服务重启又会触发前面说的重连风暴，所以要连带着设计平滑重启路径。
| 成本项 | 它随什么增长 | 最容易被低估的点 | 控制手段 | 超出后会怎样 |
|---|---|---|---|---|
| 数据库连接数 | 并发请求数、组件数量、未池化的客户端 | CPU 与内存还很闲时连接已经耗尽 | 事务池承接无状态查询，直连配额留给会话型操作 | 新请求直接报错，故障表现为"部分功能失效" |
| 备份与 WAL 归档 | 库体积、写入量、保留天数与份数 | 高频更新表的 WAL 远大于表本身 | 备份落独立卷，明确保留窗口与清理策略 | 备份先于业务写满磁盘，主库连带受影响 |
| 对象存储容量 | 上传量、派生文件倍数、软删除与孤儿对象 | 缩略图与转码产物让占用翻倍 | 生命周期规则、孤儿对象比对、可重建文件不进备份 | 磁盘告警、inode 耗尽、备份窗口拉长 |
| 对象存储与接口出网 | 文件被读取的次数、响应体大小、爬虫与监控 | 容量便宜，但读取是重复付费 | 响应压缩与分页、静态资源版本化、按路径统计出网 | 账单增长快于业务增长，且加配置无法缓解 |
| 实时订阅长连接 | 峰值并发连接数、单频道人数、消息频率 | 空闲连接照样吃内存和文件描述符 | 调高描述符上限、限制频道规模、节流与合并 | 新用户连不上，老用户无感知，排障方向易跑偏 |
| 源站出网与 CDN 回源 | 字节命中率的补集、大文件分段回源 | 用请求命中率评估，误以为缓存很有效 | 盯字节命中率、延长静态资源缓存、确认回源策略 | 回源流量居高不下，CDN 只省下一部分账单 |
| 运维工时 | 组件数量、发布频率、合规要求、值班安排 | 升级、演练、值班都不体现在配置单上 | 影子环境升级、定期恢复演练、明确轮值 | 故障恢复时间从分钟级退化到小时级 |
自建的估算顺序不能从"我买多大的机器"开始，要从四个业务数字开始。这四个数字决定资源上限，机器配置只是它们的落地形式。
日活决定了登录、注册、令牌刷新的请求量，也间接决定数据库的读写比例。读多写少的内部管理后台和写多读少的埋点型应用，对数据库的压力形态完全不同：前者吃缓冲区命中率，后者吃写入与自动清理的 IO。估算时先给出一个粗略的读写比，比单纯记一个 QPS 有用得多。
峰值并发连接数是实时服务唯一的硬指标。它和日活之间没有固定换算关系——一个协作类工具可能在几百日活下就有上百条常驻连接，而一个表单填报系统几千日活也只有个位数连接。应当按"同时打开页面的用户数乘以每用户订阅频道数"来估，再乘以单连接开销得到内存量级，同时把文件描述符上限设到峰值之上并留出余量。
把静态资源的平均大小乘以月访问次数，加上接口响应体的总量，再加上备份同步和日志外发，得到一个月度出网字节数。这个数字一旦达到数百 GB 量级，就该认真比较"按流量计费"和"峰值带宽计费"两种口径，并评估 CDN 能把字节命中率提到多少。出网是唯一一个"业务增长会直接线性推高账单"的项，其余资源都可以靠一次性扩容解决。
对象存储容量按"原始上传量乘以派生倍数"估算，再叠加一个孤儿对象的余量系数。备份盘则只对不可重建的数据负责：数据库全量加 WAL 归档是一份，关键原始文件是另一份，缩略图和转码产物不进备份。这样算出来的两块盘容量通常差距很大，也正好对应两种不同的磁盘要求——数据库盘要随机 IO，备份盘只要求容量和顺序写。
第一类是数据必须留在境内或内网：受数据出境、行业监管或企业内网策略约束，业务数据不能落到境外托管平台上，这时自建不是成本选择而是合规选择，多出来的运维成本属于必须付出的代价。第二类是团队已有数据库管理员和值班机制：数据库备份、恢复演练、慢查询优化本来就有人做，多一套 BaaS 组件的边际成本很低。第三类是负载长期稳态、流量可预测的内部系统：内部管理后台、工单系统、报表平台这类日活固定、峰值可预期的场景，自建的资源曲线是平的，规模效应能体现出来。
第一类是两三个人的小团队且没有轮值安排：运维工时不是配置能补的，缺人的团队会把成本从账单转移到人的精力上。第二类是流量尖峰不可预测的产品验证阶段：MVP 阶段的核心诉求是快速迭代和随时调整，把时间花在连接池调优和备份演练上是资源错配。第三类是出网量大但缺乏 CDN 经验的团队：出网是自建最容易失控的一项，没有缓存治理经验时，账单的不确定性会抵消掉省下的订阅费。
完全自建和完全托管之间还有一档：把最容易出事的数据库交给托管，应用与实时服务自建；或者自建主体，只把对象存储与出网交给有 CDN 的对象存储服务。这样保留了对数据和代码位置的控制权，同时把最不可控的两项——数据库恢复和出网账单——外包出去。对多数中小团队来说，这条路线比一次性二选一更稳。
初期为了控制成本，把整套套件放在一台机器上是合理的，但有一个前提条件不能被省掉：数据库的数据盘与对象存储的盘要分开。原因不是容量，而是 IO 争抢——自动清理、索引维护、大文件读写和缩略图生成会同时冲击同一块盘的 IO 队列，导致数据库响应抖动。条件允许时把 WAL 再单独放一块盘，效果更好。当业务量上来后，第一个该拆出去的通常是数据库，因为它对资源确定性的要求最高。
数据库的随机读写特性决定了它对存储介质的延迟敏感，NVMe 相比机械盘在这类负载上的差异是数量级别的，这块预算不建议省。内存方面要同时满足数据库缓冲区和操作系统页缓存的需求，常见的做法是给数据库缓冲区分配总内存的四分之一左右（公开渠道参考值，实际需结合数据规模与并发确认），其余留给页缓存和同一台机器上其他组件。把内存全部分给缓冲区，反而会让文件系统缓存失效。
需要分别确认应用层的连接上限、数据库的最大连接数、操作系统的文件描述符上限，以及内核的连接队列与端口范围。这四者的最小值决定系统实际能承载的连接数，任何一处没调都会成为瓶颈。调完之后要做一次带退避策略的压力测试，观察在连接打满前后服务的失败模式是否符合预期，而不是只看能不能连上。
签约前需要确认的口径包括：是峰值带宽、保底带宽还是按流量计费；入方向是否计费；内网与回源流量如何计量；超出后的处理方式。同时要确认故障侧的响应机制——硬件故障能否自动迁移、是否有可用的快照回滚、工单响应渠道与语言、是否提供防护能力。这些问题看起来琐碎，但它们决定了故障发生后的恢复时间，而恢复时间才是自建真正的隐性成本。
以一万网络这类深耕 IDC 19 年（成立于 2007 年）的服务商在这类"多组件同机"场景下的常见建议为例，配置评估通常不是从 CPU 核数开始，而是先确认两块盘的划分方式、文件描述符与连接数上限，以及带宽到底是按峰值、按保底还是按流量计价。像一万云 ¥25 起、裸金属 E5-2620 ¥999 起、E5-2698v4×2 ¥3999 起（海外买 1 送 1）这类官网明示价，可以作为预算比选的起点，具体配置与价格以官网实时报价为准；海外非明示节点的物理机月租一律需实时询价。
为什么坑：监控面板上 CPU 三成、内存五成，看起来非常健康，但连接已经打满，新用户全部连不上，且这类故障的现象是"部分功能失效"，很容易被误判成应用逻辑问题。怎么判断：在监控里单独画出连接池使用率、数据库当前连接数与峰值、进程打开的文件描述符数量三条曲线，看它们是否逼近上限。怎么避：上线前把四层上限逐一核对并在压测中确认失败模式；给连接池和数据库分别设置告警阈值，阈值定在峰值的七成左右而不是九成。
为什么坑：备份成功只证明文件被写出来了，不证明能恢复，也不证明恢复耗时可接受。等真正需要恢复时才发现备份缺少关键的 WAL 段、或者恢复一次要十几个小时，等于没有备份。怎么判断：问团队一个问题——最近一次把备份完整还原到独立机器并跑通业务校验是什么时候，答不上来就是没演练。怎么避：安排固定周期的恢复演练，记录实际耗时与恢复到的时间点，把结果写成文档；演练至少要在每次大版本升级后补做一次。
为什么坑：三者共享一个 IO 队列，缩略图批量生成或备份任务启动时，数据库的响应延迟会同步恶化，而监控上看到的只是"磁盘使用率"，看不出是谁在抢。怎么判断：观察数据库响应时间的抖动是否与备份窗口、批量任务窗口重合。怎么避：数据盘、对象存储盘、备份盘物理分开或至少逻辑分卷；批量任务限制并发并安排在低峰；对 IO 敏感的数据库优先使用 NVMe。
为什么坑：请求命中率高不代表源站出网少，少量未命中的大文件请求可能贡献绝大部分回源字节，导致源站账单没有明显下降，团队却以为缓存已经生效。怎么判断：同时拉取请求命中率和字节命中率两个指标，两者的差值越大说明大文件回源问题越严重。怎么避：以字节命中率作为优化目标，给静态资源设置较长缓存期并用版本化的文件名或参数更新，确认 CDN 对大文件的分段回源行为，避免整文件回源。
为什么坑：开源套件由多个独立项目组成，跨版本升级可能带来数据库迁移脚本、配置格式或环境变量命名的变化，直接升级会一次性把多个变量引入生产。怎么判断：如果团队没有一个可以完整还原生产数据量的影子环境，就说明不具备安全升级的条件。怎么避：先在影子环境用生产量级的数据跑完整升级流程与回归，确认无误后再选低峰窗口切换，并提前确认回滚路径；升级后留意实时服务的重连风暴。
能跑和能撑是两件事。4 核 8G 跑起全套容器、导入少量测试数据、几个人访问，通常没有问题，这也是很多人第一次评估时得到的印象。问题出现在负载形态变化之后：数据库缓冲区、实时服务的常驻连接、对象存储的页缓存、边缘函数的突发 CPU，这四项会同时向 8G 内存要资源。判断标准不是"能不能启动"，而是"峰值时刻各项资源是否同时逼近上限"。建议在压测中把连接数拉到预估峰值的两倍以上，观察最先触顶的是哪一项——多数情况下是内存或文件描述符，而不是 CPU。
因为开发阶段几乎不存在出网。本地和内网测试时，静态资源可能根本没走源站，接口返回几条数据，监控抓取也只有一两个节点。上生产之后，几类流量同时出现：图片视频未经 CDN 直接返回、列表接口返回体没有压缩也没有分页、搜索引擎与爬虫持续抓取、备份同步到异地、日志外发。这些单项都很小，但按月累积。最有效的定位办法是在源站按路径统计出网字节数并排序，通常会发现一两个接口或一类静态资源贡献了大部分流量，针对性处理后出网会明显下降。
先看是哪一层不够。如果是应用侧每个请求都新建连接、请求结束后才释放，那么加连接池（事务模式）的收益最大，因为它把连接从"按并发数占用"变成"按事务占用"。如果是连接池已经配好但仍不够，说明确实是并发量上来了，才需要考虑提高数据库的最大连接数——但要注意连接数提高会同步推高内存占用与上下文切换，可能反而降低吞吐。如果两者都做了还是不够，通常说明查询本身太慢，连接被长时间占住，此时应该优化慢查询和索引，而不是继续加连接。
取决于出网量和 IO 争抢程度。初期放在本地的独立磁盘上完全可行，前提是这块盘和数据库的数据盘分开，避免缩略图生成和数据库自动清理抢同一个 IO 队列。当出现下面两种情况时，就该考虑独立出来：一是出网量已经大到让源站带宽成为主要成本，需要配合 CDN 做专门的缓存治理；二是文件读写已经明显影响数据库响应延迟。独立部署的另一个好处是容量可以单独扩容，不必为了加磁盘而迁移数据库。
不要从日活出发，要从"同时打开页面的用户数"出发。先估峰值时同时在线的用户数，再乘以每个用户平均订阅的频道数，得到峰值连接数的量级；然后按单连接的内存开销估算内存需求，并把文件描述符上限设在这个数字之上并留余量。单连接开销在不同实现下差异较大，属于公开渠道参考值，实际需结合自身业务模型与实测确认。另外还要单独评估"单个频道的人数乘以消息频率"，因为广播扇出是按订阅者数量重复执行的，一个几千人的房间即使总连接数不高也可能成为瓶颈。
备份空间主要由两部分构成：全量备份乘以保留份数，加上 WAL 归档乘以保留天数。一个 50GB 的库每天一份全量保留 7 天，光全量就是 350GB；WAL 的量等于写入量，高频更新的表会让这一部分远大于直觉。因此备份盘应该按"库体积乘以份数加写入量乘以天数"来规划，并明确清理策略。演练频率取决于数据变更速度和业务容忍度，写入频繁的系统应当更频繁；最低要求是每次大版本升级后做一次完整恢复演练，并把实际耗时与恢复到的时间点记录下来，作为 RTO 与 RPO 的真实依据。
如果只是为了省下每月几百元的订阅费，通常不划算。两三个人的团队里，运维工时是最稀缺的资源：升级要在影子环境跑、备份要定期演练、半夜故障要有人响应，这些工作不会因为团队小而减少。更现实的判断依据是看自建的动机是什么——如果是数据必须留在境内或内网、或者已有成熟的数据库运维能力，那么自建是必要选择，成本该认；如果只是觉得托管贵，那么先把出网、对象存储和值班这三项的真实成本算出来再决定。折中方案也值得考虑：数据库用托管，应用与实时自建。
有几个信号比较明确：一是运维工时已经明显挤占产品开发时间，团队开始为了修基础设施而推迟需求；二是出网账单波动大且难以预测，缓存治理始终做不到位；三是经历过一次恢复时间超过预期的故障，说明值班与演练机制不足以支撑当前规模；四是合规约束发生了变化，原先必须自建的前提不再成立。迁移时的顺序建议是先迁数据库和对象存储这两项最依赖运维能力的部分，应用与实时服务可以晚一步。具体费用需实时询价，以官网实时报价为准。
落到采购环节，像一万网络这类服务商在配这类多组件同机方案时，通常建议把数据库盘与对象存储盘分开、把带宽口径（峰值 / 保底 / 按流量）问清，并配合免费系统盘快照（每日 3 份 / 30 秒回滚）与 7×24 中文工单（平均 5 分钟响应）来压缩自建多出来的运维面。海外非标节点的物理机月租一律以官网实时报价为准。
把这笔账算完，结论是清楚的：自建 BaaS 省下的是确定的、可预测的订阅费，换来的是一组不确定的、需要自己管理的资源和责任。它不是一个进程，而是数据库、认证、对象存储、实时推送、API 网关和后台管理六类组件，每一类有自己的资源画像、有自己的扩容方式、也有自己的故障模式。真正决定这笔账是否划算的分水岭，从来不是 CPU 核数和内存大小，而是出网流量和谁来值班这两件事——前者会随业务增长线性推高账单且无法靠加配置解决，后者决定了故障发生后的恢复时间是分钟级还是小时级。
所以给一个带条件的判断：如果数据必须留在境内或内网、团队已有数据库运维与值班机制、业务负载长期稳态，自建是合理且长期更经济的选择；如果是两三人的小团队、处在产品验证阶段、或者出网量大却缺乏缓存治理经验，优先托管，把时间花在产品上。介于两者之间的团队，可以考虑数据库托管加应用自建的折中方案，把最不可控的两项外包出去。预算比选时可以关注服务商在故障侧的服务能力，例如免费系统盘快照（每日 3 份 / 30 秒回滚）、硬件故障 10 分钟自动迁移、7×24 中文工单平均 5 分钟响应、5–20G 免费 DDoS 防护与免费备案协助，这些能力决定的是恢复时间，而恢复时间正是自建最难自己补上的一环。具体资费需实时询价，以官网实时报价为准。
Supabase 官方自托管与架构文档：关于数据库、认证、存储、实时、REST 与边缘函数的组件划分与部署要求。
PostgreSQL 官方文档：最大连接数、连接池模式、WAL 归档与时间点恢复、自动清理与索引维护的资源影响。
PostgreSQL 连接池相关项目文档：事务模式池与会话模式池的能力差异及其对会话级特性的限制。
PocketBase 等轻量后端即服务官方文档：单体部署形态下的资源占用与存储模型，用于对比多组件套件的复杂度差异。
主流 CDN 服务商公开文档：请求命中率与字节命中率的定义、缓存有效期与回源策略对源站出网的影响。
工信部与监管机构关于数据出境的公开规定：数据是否必须留在境内或内网的合规判断依据。
一万网络官网公开信息：服务器与裸金属产品的明示报价区间、快照与故障迁移等服务条款。
适用边界：本文中的连接数量级、单连接内存开销、内存分配比例等均属公开渠道参考值，实际需结合业务模型、并发特征与实测确认；本文不提供任何托管 BaaS 与自建的精确成本对比数字，也不构成对特定产品的推荐。具体以签约时最新报价与合同为准。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
