1、关于万小智
万小智是阿里云面向中小微企业和个人开发者的AI智能建站平台，致力于让“零代码、一分钟生成全栈应用”成为现实。用户只需用自然语言描述业务需求——如“我要一个带会员系统的在线课程平台”或“帮我做一个库存管理的进销存小程序”——万小智即可自动完成数据库设计、API 生成、前端页面搭建及部署上线的一站式交付。
万小智的业务场景面向数万至数十万轻量级 SaaS 租户，具有明显长尾分布和间歇性负载特征：白天活跃、夜间闲置，资源容易浪费。目标用户多为小微创业者、开发者及公益教育机构，对成本高度敏感，通常只能接受每月几十元级投入。同时，平台要求全托管免运维，用户无需数据库经验，也能获得开箱即用的 Serverless 体验。万小智的技术底座需要同时满足多租户强隔离（数据安全合规）、秒级弹性扩缩（匹配业务脉冲）、单租户低成本（支撑免费/低价 tiers）三大矛盾诉求，这对底层数据库架构提出了极高挑战。
2、业务挑战：Supabase 单租户模式下的成本壁垒
万小智早期选择基于开源 Supabase 构建产品原型，快速验证了产品方向。然而，当平台从原型走向规模化运营时，Supabase 原生的单租户单实例架构成为了不可逾越的成本壁垒。
- 实例碎片化：Supabase 采用“一租户一实例”模式，万小智若扩展到 2 万租户，就需维护 2 万个容器/虚拟机，仅计算成本就将达百万元/月，难以支撑商业模式。
- 资源闲置：90% 以上中小租户日均 QPS 低于 10，但每个实例仍需至少 2C4G，资源利用率不足 5%，大量算力被空转浪费。
- 连接池爆炸：租户规模扩大后，网关层需管理海量独立连接池，内存、端口和连接管理开销迅速上升，网关也更容易成为扩展瓶颈和故障点。
- 存储冗余：租户应用高度同质，但同样的索引、函数和插件在每个实例中重复存储，整体存储成本被放大 10～50 倍。
- 运维复杂：监控、备份、补丁和扩缩容都要专人维护，与“全托管免运维”的平台定位明显冲突。
归结起来，Supabase 卓越的开发者体验与万小智“万级租户、极致成本”的商业模型之间存在结构性冲突。官方 Supabase Cloud 定价对部分单个租户尚可接受，但平台方聚合万级租户时代价完全不可承受；自托管开源版则陷入“要么牺牲隔离安全性，要么破产”的两难。
万小智亟需一种架构，在保留 Supabase 完整能力栈的前提下，实现：
- 多租户密度：单数据库集群支撑数千租户，共享计算与连接资源；
- 真Serverless：流量归零时计算成本趋近于零，首请求秒级唤醒；
- 透明隔离：租户无感知共享，但数据、权限、计算环境强边界隔离；
- 生态兼容：零改造复用 Supabase SDK、CLI、Dashboard，保证开发者体验。
3、技术方案：PolarDB Supabase多租 + 全链路Serverless架构
针对万小智的核心挑战，阿里云瑶池旗下的云原生数据库 PolarDB 团队在开源 Supabase 基础上，设计并实现了一套安全、可扩展且开发者友好的多租户平台架构。该方案的核心思路是将多租户隔离逻辑完全内聚在后端基础设施层，对前端开发者完全透明，从而在不牺牲安全性的前提下实现极致的资源共享与成本收敛。
关键技术点一：基于 Schema 的租户数据沙箱隔离
方案的第一层防线是数据层面的物理隔离。PolarDB Supabase 为每个租户分配一个独立的数据库 Schema，而非传统方案中的独立数据库实例。这种设计实现了"逻辑隔离等效物理隔离"的效果：租户 A 的数据表、索引和函数对租户 B 完全不可见，即使它们共存于同一个 PolarDB 集群中。相比独立实例方案，Schema 级隔离在保持同等安全边界的同时，消除了实例间的资源碎片化，使数千租户得以共享同一个数据库引擎的计算能力和连接池资源。
关键技术点二：三层角色防御体系与零信任安全模型
方案围绕三个核心角色构建了严格的权限边界。
- 平台管理员（Admin）负责租户全生命周期管理和数据模型变更，通过受控后端以 service_role 密钥执行高权限操作；
- 租户/应用所有者（Tenant）通过平台 UI 配置业务数据结构，其操作意图被安全的后端工作流翻译为数据库操作，并在专属沙箱内执行；
- 应用使用者（End User）通过租户提供的应用前端进行数据增删改查，其所有 API 请求均被自动化安全机制透明地路由和隔离到对应的租户环境中。
在技术实现上，用户登录后其身份信息（包括所属租户标识）被加密签名在 JWT 中，形成不可篡改的“数字护照”。系统内建了一个在每个 API 请求执行前被强制调用的安全验证程序，充当“自动化安全检查站”——它严格校验 JWT 中的租户 ID 与请求目标租户的一致性，确保没有任何请求可以绕过身份和权限校验。这种“物理隔离 + 零信任校验”的双重保障机制，在共享架构下实现了与独立实例同等甚至更高的安全级别。
关键技术点三：四平面协同的全栈多租户隔离
PolarDB Supabase 的多租户隔离不仅覆盖数据层，而是贯穿整个技术栈的四个平面。
- 数据平面（PostgREST）确保新租户创建后其专属 API 接口能被实时自动发布，无需重启服务，通过平台内部的实时通知机制触发配置热更新。
- 认证平面（Supabase Auth）在用户注册、登录和会话刷新的全生命周期中携带并校验租户身份，将 JWT 中的租户 ID 与请求目标进行强制匹配，从根本上防止跨租户冒用。
- 计算平面（Edge Functions）通过“全局函数 + 租户函数”的分层模式，将跨租户共享逻辑与单租户定制逻辑解耦，函数在调用时显式携带租户 ID，运行时仅访问对应租户的数据沙箱与密钥。
- 运维平面（Postgres Meta）为平台提供租户级元数据和自定义 SQL 能力，使表结构管理和函数发布等运维操作也严格限定在各自的租户沙箱内。
四个平面的协同工作，使得多租户隔离从“数据库层面的局部方案”升级为“全栈级别的系统性工程”，每个环节都不留安全死角。
关键技术点四：全链路 Serverless 自动弹性
在多租户架构解决资源密度问题的基础上，PolarDB Supabase 进一步引入了全链路 Serverless 弹性机制，彻底消除闲置资源的成本消耗。该方案支持从网关层、Supabase 应用服务层到底层 PolarDB 数据库层的多维度按需弹性：当租户流量归零时，对应的计算资源可自动缩减至近零状态；当首个请求到达时，系统能在秒级时间内完成资源唤醒和请求响应。这种“用多少付多少”的真 Serverless 体验，与万小智大量长尾租户的间歇性负载特征高度匹配，从根本上解决了传统常驻实例模式下夜间零流量仍需全额计费的痛点。
PolarDB 自身的存储计算分离架构为 Serverless 弹性提供了坚实底座，计算节点可独立于存储进行秒级扩缩，而共享存储层确保了弹性过程中数据的一致性和持久性。
4、落地效果：成本下降 666 倍，性能经受压测验证
PolarDB Supabase 多租户方案在万小智平台的落地效果，通过严格的压测和成本核算得到了充分验证。
- 支撑更高租户密度：一套 2C8G 的 PolarDB-PG 配套网关/后端即可稳定承载 2000 个活跃租户 APP，显著提升平台资源利用效率。
- 大幅降低基础设施成本：在传统架构下，2000 个租户需独立部署 2000 个实例，对应至少 2000 个计算资源单元的开销。而采用 PolarDB 方案后，凭借先进的多租户共享架构，2000 个租户仅需共享 1 个集群实例（2个 gateway 和 2个 backend，仅含 4 个核心计算资源单元），资源成本下降了666倍。
- 兼顾性能与稳定性：在 QPS 4000+ 的高并发场景下，系统成功率仍保持 99.90%，满足业务对高可用和稳定性的要求。
这些数字不是理论推演，而是基于真实压测数据的保守估算。随着租户密度的进一步提升和 Serverless 弹性的充分利用，实际生产环境中的成本优势还有持续放大的空间。
5、总结
万小智面对的是一个典型的平台型 SaaS 数据库架构难题：如何在万级租户规模下，同时实现强隔离、低成本和高弹性。PolarDB Supabase 多租户方案通过四项关键技术设计给出了系统性的解答。最终，这套方案帮助万小智实现了单组集群支撑 2,000 租户、成本下降 666 倍的实际业务效果，同时保持了 Supabase 生态的完整兼容性和开发者友好的使用体验。
对于正在构建多租户 SaaS 平台、面临“隔离安全性与基础设施成本不可兼得”困境的技术团队而言，PolarDB Supabase 多租 + Serverless 架构提供了一条经过生产验证的可行路径。
