啥是BaaS? 为什么云数据库厂商都在推Supabase服务?
digoal约 9 分钟啥是BaaS? 为什么云数据库厂商都在推Supabase服务?
低代码这么多年了, 始终不温不火, 但是比低代码更高级亿点点的BaaS(还是需要写点前端代码的)确热火朝天?
有了BaaS(后端即服务), FaaS(前端即服务)还会远吗?
BaaS, FaaS 都有了, 离低代码火起来是不是就更近一步了呢?
今天这篇文章就来介绍一下火遍全网的BaaS产品Supabase是啥? 为什么云厂商纷纷推出支持Supabase的服务!!!
🚀 Supabase 详细介绍 —— 开源 Firebase 替代品
📌 一、Supabase 是什么？
Supabase 是一个 开源的 BaaS（Backend as a Service）平台，基于 PostgreSQL 构建，提供：
✅ 实时数据库（Realtime） ✅ 身份认证（Auth） ✅ 存储（Storage） ✅ 边缘函数（Edge Functions） ✅ 自动 API 生成（REST + GraphQL） ✅ 仪表盘（Dashboard）
💡 定位：开源版 Firebase，但基于 SQL 和 PostgreSQL 生态，更适合复杂业务和开发者控制。
官网：https://supabase.com
GitHub：https://github.com/supabase/supabase（⭐ 80K+ Stars）
🧩 二、核心组件与架构
1. PostgreSQL（核心数据库）
所有数据存储在 PostgreSQL 表中 支持复杂查询、JOIN、事务、扩展（如 PostGIS、pgvector） 开发者可直接写 SQL，也可用自动生成的 API
2. Supabase Auth（身份认证）
基于 GoTrue（开源身份服务） 支持： 邮箱/密码 OAuth（Google、GitHub、Apple 等） 魔法链接（Magic Link） SSO（企业版） JWT 令牌集成，与 PostgreSQL RLS（行级安全）深度绑定
3. Supabase Storage（对象存储）
基于 PostgreSQL + 文件系统 类似 AWS S3，支持上传/下载/管理文件 自动与 Auth 集成，支持权限控制
4. Realtime（实时订阅）
基于 PostgreSQL 的逻辑复制（Logical Replication） + WebSocket 客户端可订阅表变更（INSERT/UPDATE/DELETE） 低延迟，适合聊天、协作、通知等场景
5. Edge Functions（边缘函数）
基于 Deno，部署在边缘节点 类似 AWS Lambda，用于自定义业务逻辑 支持 TypeScript，与 Supabase SDK 无缝集成
6. Auto API（自动生成 API）
根据 PostgreSQL 表结构，自动生成： RESTful API TypeScript SDK GraphQL API（实验性） 开发者无需写后端代码，前端直接调用
🎯 三、Supabase vs Firebase
🎯 Supabase 优势：SQL 能力强、开源可控、适合复杂业务
🎯 Firebase 优势：生态成熟、移动端集成好、上手简单
🛠️ 四、快速开始（5 分钟部署）
1. 创建项目
# 安装 CLI
npm install -g supabase
# 登录
supabase login
# 初始化项目
supabase init
# 启动本地开发环境
supabase start
2. 前端调用（React 示例）
import { createClient } from '@supabase/supabase-js'
const supabase = createClient(
'https://your-project.supabase.co',
'your-anon-key'
)
// 插入数据
const { data, error } = await supabase
.from('todos')
.insert([{ title: 'Hello Supabase!' }])
// 订阅实时变更
supabase
.channel('todos')
.on('postgres_changes', { event: 'INSERT', schema: 'public', table: 'todos' }, (payload) => {
console.log('New todo:', payload.new)
})
.subscribe()
🔐 五、安全机制 —— RLS（行级安全）
Supabase 的核心安全模型是 PostgreSQL RLS（Row Level Security）：
-- 启用 RLS
ALTERTABLE todos ENABLEROWLEVELSECURITY;
-- 创建策略：用户只能访问自己的 todos
CREATEPOLICY"User can access own todos"
ON todos
FORALL
USING (auth.uid() = user_id);
✅ 所有 API 请求自动携带 JWT，PostgreSQL 根据
auth.uid()过滤数据
🌐 六、部署与自托管
1. 云托管（Supabase Platform）
官方托管，免费层可用 自动扩展，无需运维
2. 自托管（Docker/K8s）
git clone https://github.com/supabase/supabase
cd supabase/docker
docker-compose up
✅ 适合企业私有化部署，数据完全自主可控
📊 七、适用场景
📈 八、性能与扩展性
单实例性能：取决于 PostgreSQL 配置（CPU/内存/磁盘） 读写分离：支持（通过多个客户端连接不同副本） 分片（Sharding）：需手动实现（如 Citus 扩展） 缓存：可集成 Redis（通过 Edge Functions）
🚀 Supabase 正在开发 “Database Branching”（类似 Neon），支持秒级克隆数据库，适合开发/测试环境。
🧩 九、生态与工具
| Supabase CLI | |
| Supabase Studio | |
| VS Code Extension | |
| Flutter/Dart SDK | |
| pgvector |
✅ 十、总结
| 定位 | |
| 核心优势 | |
| 适用人群 | |
| 学习成本 | |
| 生产可用 |
📌 一句话总结：
Supabase = PostgreSQL + 自动生成 API + 实时 + Auth + Storage + 边缘函数 —— 一个开源、可控、强大的现代 BaaS 平台。
🚀 为什么云数据库厂商都在推Supabase服务?
实际上，云数据库厂商并没有在“推 Supabase 服务” —— 这是一个常见的误解。
更准确地说：
✅ Supabase 是一个独立的开源 BaaS（Backend as a Service）平台，基于 PostgreSQL 构建。
✅ 云厂商（如 AWS、Azure、Google Cloud）是在“推 PostgreSQL 托管服务”，而 Supabase 正好构建在其上。
✅ 开发者社区和创业公司热捧 Supabase，因为它开源、灵活、功能全，是 Firebase 的 SQL 替代品。
❌ 误解澄清：云厂商 ≠ 推 Supabase
📌 Supabase 是 独立公司（supabase.com） 的产品，不是任何云厂商的官方服务。
✅ 那为什么“感觉”云厂商在推 Supabase？
原因 1：Supabase 依赖云厂商的 PostgreSQL 服务
Supabase 的核心是 PostgreSQL 开发者部署 Supabase 时，通常选择： AWS RDS/Aurora PostgreSQL Google Cloud SQL for PostgreSQL Azure Database for PostgreSQL 阿里云 RDS PostgreSQL
👉 云厂商乐见其成，因为 Supabase 带动了 PostgreSQL 托管服务的使用量。
原因 2：云厂商市场部“蹭热点”
云厂商博客或案例中会写： “如何在 AWS 上部署 Supabase” “使用 Azure PostgreSQL 运行 Supabase” 这是 技术整合文章，不是官方推广 Supabase
原因 3：开发者社区推动
Supabase 在 GitHub 有 80K+ Stars，社区活跃 大量教程、视频、模板围绕 “Supabase + AWS/GCP/Azure” 展开 云厂商顺势提供“最佳实践”，吸引开发者
✅ 云厂商真正推的是什么？
| AWS | ||
| Azure | ||
| Google Cloud | ||
| 阿里云 | ||
| 腾讯云 |
🎯 云厂商的策略：推 PostgreSQL → 吸引开发者 → Supabase 自然跑在上面 → 增加云服务收入
✅ 为什么开发者喜欢 Supabase？（这才是“推”的本质）
1. 开源 & 可自托管
代码全开源（MIT 协议） 可部署在任意云或私有环境 企业可控，无厂商锁定
2. 功能齐全，开箱即用
Auth（身份认证） Realtime（实时订阅） Storage（对象存储） Edge Functions（边缘函数） Auto API（REST/GraphQL）
3. 基于 PostgreSQL，SQL 能力强
支持复杂查询、JOIN、事务、扩展（如 PostGIS、pgvector） 适合中大型业务，非简单 CRUD
4. 替代 Firebase
Firebase 是 NoSQL，Supabase 是 SQL 更适合需要关系型数据、复杂查询的场景
📈 数据佐证
Supabase GitHub Stars：80K+（2025 年 4 月） Supabase 官方云平台用户：超过 100,000 个组织 云厂商 PostgreSQL 增长： AWS Aurora PostgreSQL 年增长 > 40% Azure Database for PostgreSQL 年增长 > 50%
📌 Supabase 的流行，间接推动了云厂商 PostgreSQL 服务的增长。
✅ 总结
📌 一句话真相：
云厂商没有推 Supabase —— 但他们推的 PostgreSQL，正好是 Supabase 的地基。开发者用 Supabase，云厂商卖 PostgreSQL，双赢。
FaaS(前端即服务)展望
非常好的问题！
你问：
有 BaaS（Backend as a Service），那么有 FaaS（前端即服务）吗？
✅ 短答案：
没有官方或广泛接受的 “FaaS = Frontend as a Service” 概念 —— 因为 “FaaS” 在业界已被 “Function as a Service”（函数即服务） 占用。
但！
✅ “前端托管 + 边缘渲染 + 无服务器前端” 的组合，本质上就是 “前端即服务” —— 我们可以称之为 “Frontend as a Service” 或 “Hosted Frontend Platform”。
🧩 一、为什么没有 “Frontend as a Service” 这个词？
1. 命名冲突：FaaS = Function as a Service
AWS Lambda、Azure Functions、Google Cloud Functions 都叫 FaaS 业界已约定俗成，无法再用于 “Frontend”
2. 前端本质是 “静态资源 + 渲染”，不是 “服务”
后端（BaaS）提供 API、数据库、认证等“服务” 前端主要是 HTML/CSS/JS，传统上是“部署到 CDN”，不是“服务化”
✅ 二、但“前端即服务”确实存在 —— 只是不叫 FaaS
现代前端开发中，以下平台和服务，本质上就是 “Frontend as a Service”：
| Vercel | ||
| Netlify | ||
| Cloudflare Pages | ||
| AWS Amplify Hosting | ||
| Firebase Hosting |
🎯 这些平台提供：
✅ 自动构建 & 部署 ✅ 全球 CDN 加速 ✅ 自定义域名 & SSL ✅ 边缘函数（处理请求、重写、认证） ✅ 预览环境（Pull Request 自动部署） ✅ 与 BaaS（如 Supabase、Firebase）无缝集成
🌐 三、“前端即服务”的核心能力
如果定义 “Frontend as a Service”，它应包含：
| Git 集成 | git push |
| 自动构建 | |
| 全球 CDN | |
| 边缘渲染 | |
| 无服务器函数 | |
| 预览环境 | |
| A/B 测试 & 分支部署 | |
| 安全 & 合规 |
🆚 四、BaaS vs “Frontend as a Service”
✅ 两者常搭配使用：
Vercel（前端） + Supabase（后端） = 完整无服务器全栈应用
🚀 五、未来趋势：前端越来越“服务化”
1. 边缘计算 + 前端融合
Vercel Edge Functions、Cloudflare Workers 让前端能运行“服务端逻辑” 实现“中间件”、“认证”、“A/B 测试”在边缘执行
2. AI 驱动的前端服务
自动化 A/B 测试 动态内容生成（如个性化推荐） AI 优化加载性能
3. 无代码前端平台
Webflow、Framer、Builder.io 让非开发者也能“服务化”前端
✅ 六、总结
📌 一句话记住：
“FaaS 是 Function，前端托管平台是 Frontend as a Service —— 它们和 BaaS 一起，构成了现代无服务器全栈开发的铁三角。”