啥是BaaS? 为什么云数据库厂商都在推Supabase服务?

啥是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
ALTER TABLE todos ENABLE ROW LEVEL SECURITY;

-- 创建策略：用户只能访问自己的 todos
CREATE POLICY "User can access own todos"
ON todos
FOR ALL
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 = 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” 展开
• 云厂商顺势提供“最佳实践”，吸引开发者

✅ 云厂商真正推的是什么？

🎯 云厂商的策略：推 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”：

🎯 这些平台提供：

• ✅ 自动构建 & 部署
• ✅ 全球 CDN 加速
• ✅ 自定义域名 & SSL
• ✅ 边缘函数（处理请求、重写、认证）
• ✅ 预览环境（Pull Request 自动部署）
• ✅ 与 BaaS（如 Supabase、Firebase）无缝集成

🌐 三、“前端即服务”的核心能力

如果定义 “Frontend as a Service”，它应包含：

🆚 四、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 一起，构成了现代无服务器全栈开发的铁三角。”

老铁, 你怎么看?

欢迎留言!!!!