最近在 Pigsty v3.1中，我们提供了开箱即用的Supabase自建支持。这是一篇关于如何自建 Supabase 的详细教程。完整的教程，我建议您直接参考我们的博客：https://pigsty.cc/zh/blog/db/supabase/
Supabase 是一个开源的 Firebase，是一个 BaaS （Backend as Service）。Supabase 对 PostgreSQL 进行了封装，并提供了身份认证，消息传递，边缘函数，对象存储，以及基于 PG 数据库模式自动生成的 REST API 与 GraphQL API。
Supabase 旨在为开发者提供一站式的后端解决方案，减少开发和维护后端基础设施的复杂性，使开发者专注于前端开发和用户体验。用大白话来说就是：让开发者告别绝大部分后端开发的工作，只需要懂数据库设计与前端即可快速出活！
目前，Supabase 是 PostgreSQL 生态人气最高的开源项目，在 GitHub 上已经有高达7万4千的Star数。并且和 Neon，Cloudflare 一起并称为赛博菩萨 —— 因为他们都提供了非常不错的云服务免费计划。目前，Supabase 和 Neon 已经成为许多初创企业的首选数据库 —— 用起来非常方便，起步还是免费的。
为什么要自建Supabase？
小微规模（4c8g）内的 Supabase 云服务极富性价比[12]，人称赛博菩萨。那么 Supabase 云服务这么香，为什么要自建呢？
比较直观的原因是是我们在《云数据库是智商税吗？[13]》中提到过的：当你的规模超出云计算适用光谱，成本很容易出现爆炸式增长。而且在当下，足够可靠的本地企业级 NVMe SSD[14]在性价比上与云端存储有着三到四个数量级的优势，而自建能更好地利用这一点。
另一个重要的原因是功能， Supabase 云服务的功能受限 —— 出于与RDS相同的逻辑， 很多 强力PG扩展[15] 因为多租户安全挑战与许可证的原因无法作为云服务提供。故而尽管PG扩展是 Supabase 的一个核心特色，在云服务上也依然只有 64 个可用扩展，而 Pigsty 提供了多达 340[16] 个开箱即用的 PG 扩展。
此外，尽管 Supabase 虽然旨在提供一个无供应商锁定的 Google Firebase 开源替代，但实际上自建高标准企业级的 Supabase 门槛并不低：Supabase 内置了一系列由他们自己开发维护的 PG 扩展插件，而这些扩展在 PGDG 官方仓库中并没有提供。这实际上是某种隐性的供应商锁定，阻止了用户使用除了 supabase/postgres Docker 镜像之外的方式自建。
Pigsty 解决了这些问题，我们将所有 Supabase 自研与用到的 10 个缺失的扩展打成开箱即用的 RPM/DEB 包，确保它们在所有主流Linux操作系统发行版[17]上都可用：
我们还在 Supabase 中默认安装了以下扩展，您可以参考可用扩展列表启用更多。
同时，Pigsty 还会负责好底层高可用[28] PostgreSQL[29] 数据库集群，高可用 MinIO[30] 对象存储集群的自动搭建，甚至是 Docker[31] 容器底座的部署。最终，您可以使用 Docker Compose 拉起任意数量的无状态 Supabase 容器集群，并使用外部由 Pigsty 托管的企业级 PostgreSQL 数据库与 MinIO 对象存储，甚至连反向代理的 Nginx 等都已经为您配置准备完毕！
在这一自建部署架构中，您获得了使用不同内核的自由（PG 12-17），加装340个扩展的自由，扩容与伸缩Supabase/Postgres/MinIO的自由，免于数据库运维的自由，以及告别供应商锁定的自由。而相比于使用 Supabase 云服务需要付出的代价，不过是准备一（几）台物理机/虚拟机 + 敲几行命令，等候十几分钟的区别。
单节点自建快速上手
让我们先从单节点 Supabase 部署开始，我们会在后面进一步介绍多节点高可用部署的方法。首先，使用 Pigsty 标准安装流程 安装 Supabase 所需的 MinIO 与 PostgreSQL 实例；
curl -fsSL https://repo.pigsty.io/get | bash
./bootstrap # 环境检查，安装依赖
./configure -c supa # 重要：请在配置文件中修改密码等关键信息！
./install.yml # 安装 Pigsty，拉起 PGSQL 与 MINIO！
然后额外运行 supabase.yml
完成剩余的工作， 拉起无状态部分的 Supabase 容器，Supabase 就可以使用了（默认端口 8000
/8433
）。
./supabase.yml # 安装 Docker 并拉起 Supabase 无状态部分
请在部署 Supabase 前，根据您的实际情况，修改自动生成的 pigsty.yml
配置文件中的参数（主要是密码！） 如果您只是将其用于本地开发测试，可以先不管这些，我们将在后面介绍如何通过修改配置文件来定制您的 Supabase。
如果您的配置没有问题，那么大约在 10 分钟后，您就可以在本地网络通过 http://<your_ip_address>:8000
访问到 Supabase Studio 管理界面了。
自建关键技术决策
以下是一些自建 Supabase 会涉及到的关键技术决策，供您参考：
使用默认的单节点部署 Supabase 无法享受到 PostgreSQL MinIO 的高可用能力。尽管如此，单节点部署相比官方纯 Docker Compose 方案依然要有显著优势：例如开箱即用的监控系统，自由安装扩展的能力，各个组件的扩缩容能力，以及数据库时间点恢复能力等。
如果您只有一台服务器，Pigsty 建议您直接使用外部的 S3 作为对象存储，存放 PostgreSQL 的备份，并承载 Supabase Storage 服务。这样的部署在故障时可以提供一个最低标准的 RTO （小时级恢复时长）/ RPO （MB级数据损失）兜底容灾水平[45]。此外，如果您选择在云上自建，我们也建议您直接使用 S3，而非默认使用的本体 MinIO ，单纯在本地 EBS 上再套一层 MinIO 转发，除了便于开发测试外，对生产实用并没有意义。
在严肃的生产部署中，Pigsty 建议使用至少3～4个节点的部署策略，确保 MinIO 与 PostgreSQL 都使用满足企业级高可用要求的多节点部署。在这种情况下，您需要相应准备更多节点与磁盘，并相应调整 pigsty.yml
配置清单中的集群配置，以及 supabase 集群配置中的接入信息。
部分 Supabase 的功能需要发送邮件，所以要用到 SMTP。除非单纯用于内网，否则对于严肃的生产部署，我们建议您考虑使用外部的 SMTP 服务。自建的邮件服务器发送的邮件可能会被对方邮件服务器拒收，或者被标记为垃圾邮件。
如果您的服务直接向公网暴露，我们建议您使用 Nginx 进行反向代理，使用真正的域名与 HTTPS 证书，并通过不同的域名区分不同的多个实例。
关于这些主题的讨论，请点击查看原文阅读细节。
广告时间
中国地区的用户请注意，如果您没有配置好 Docker 镜像站点或代理服务器，那么会有极大概率会翻车在 ./supabase 最后一步的镜像拉取上。
我们建议您掌握科学上网技巧，参考 Docker 模块 FAQ 的说明配置镜像或代理。当然话都说到这儿了不打个广告也不合适：
我们提供 Supabase 自建专门咨询服务[44]，¥2000 / 例，半小时内详细答疑，购买附赠预制离线安装包，可以无需互联网（自然也无需翻墙）安装，将您的企业级自建 Supabase 安稳扶上马！
离线软件包使用说明：请在执行安装前，将收到的 pkg.tgz 放置于 /tmp/pkg.tgz，将 supabase 目录整个放置在 /tmp/supabase 即可。
