基于PolarDB Supabase一键AI建站资源成本直降666倍

首页

AI教程

热心网友

转载

2026-05-28

1、关于万小智

万小智是阿里云面向中小微企业和个人开发者的AI智能建站平台，它的核心愿景很明确：让“零代码、一分钟生成全栈应用”成为现实。用户只需要用自然语言描述自己的业务需求——比如“我要一个带会员系统的在线课程平台”或者“帮我做一个库存管理的进销存小程序”——万小智就能自动完成从数据库设计、API生成、前端页面搭建到部署上线的全流程。

这个平台的业务场景很有特点，它面向的是数万到数十万的轻量级SaaS租户，呈现出典型的长尾分布和间歇性负载特征：白天活跃、夜间闲置，资源很容易浪费。目标用户主要是小微创业者、开发者和公益教育机构，他们对成本高度敏感，通常只能接受每月几十元级别的投入。与此同时，平台还必须做到全托管、免运维，让用户即使没有任何数据库经验，也能获得开箱即用的Serverless体验。

这就对底层的技术底座提出了近乎矛盾的要求：既要满足多租户间的强隔离（数据安全合规），又要能实现秒级弹性扩缩（匹配业务的脉冲式访问），还得保证单租户的低成本（以支撑免费或低价套餐）。这三大诉求交织在一起，对底层数据库架构的挑战是极高的。

2、业务挑战：Supabase单租户模式下的成本壁垒

在早期，万小智选择基于开源的Supabase来构建产品原型，这个选择帮助团队快速验证了产品方向。然而，当平台需要从原型走向规模化运营时，Supabase原生的“单租户单实例”架构，就变成了一道难以逾越的成本壁垒。

具体来看，挑战主要体现在几个方面：

实例碎片化：Supabase采用“一租户一实例”的模式。这意味着，如果万小智扩展到2万个租户，就需要维护2万个容器或虚拟机。仅计算成本一项，就可能达到百万元每月，这显然难以支撑其商业模式。

资源闲置：超过90%的中小租户，日均QPS可能都低于10。但每个实例至少需要2核4G的资源，导致资源利用率不足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多租户方案在万小智平台的落地效果，通过严格的压力测试和成本核算，得到了充分的验证。

支撑更高租户密度：一套2核8G的PolarDB-PG配套网关/后端，即可稳定承载2000个活跃租户应用，显著提升了平台的资源利用效率。
大幅降低基础设施成本：这是最直观的收益。在传统架构下，支撑2000个租户需要独立部署2000个实例，对应至少2000个计算资源单元的开销。而采用PolarDB方案后，凭借先进的多租户共享架构，2000个租户仅需共享1个集群实例（包含2个gateway和2个backend，总计仅4个核心计算资源单元），资源成本下降了惊人的666倍。
兼顾性能与稳定性：在QPS超过4000的高并发场景下，系统成功率仍能保持在99.90%，满足了业务对高可用和稳定性的要求。

需要强调的是，这些数字并非理论推演，而是基于真实压测数据的保守估算。随着租户密度的进一步提升和Serverless弹性的充分利用，实际生产环境中的成本优势还有持续放大的空间。