PostgreSQL 与 MongoDB 对比
开源关系型数据库的王者 PostgreSQL 与灵活的 NoSQL 文档数据库 MongoDB。该如何根据你的数据模型选择合适的数据库?
在你自己的服务器上运行、自 1986 年起不断成熟的开源关系型数据库
构建在真正的 PostgreSQL 之上的托管式开源后端平台
这个决定没有唯一正确答案。如果你是小团队且优先考虑速度,那么 Supabase 就是正确选择:auth、storage、realtime 和连接池都已就绪。若负载可预测、有数据落地要求(17 个区域中没有土耳其),或成本随用户数增长,则自建 PostgreSQL 更胜一筹。一个警示:官方文档写明,自托管时托管式备份/PITR 会被禁用——掌控权到手的同时也接手了恢复演练。备份本身不是判断标准;能否恢复才是。
| 分类 | Self-hosted PostgreSQL | Supabase |
|---|---|---|
| 性能 | 8/10 | 8/10 |
| 学习难易度 | 5/10 | 8/10 |
| 生态系统 | 9/10 | 8/10 |
| 社区 | 9/10 | 9/10 |
| 就业市场 | 8/10 | 7/10 |
| 面向未来 | 8/10 | 8/10 |
# Self-hosted PostgreSQL - WAL 归档 + PITR 配置(postgresql.conf)
wal_level = replica
archive_mode = on
archive_command = 'test ! -f /var/backups/pg_wal_archive/%f && cp %p /var/backups/pg_wal_archive/%f'
max_wal_senders = 3
# 创建基础备份(pg_basebackup)
pg_basebackup -D /var/backups/base -Ft -z -P -U replicator -h localhost
# PITR:恢复到指定时间点(recovery.signal + postgresql.conf)
# 1) 将基础备份解压到恢复目录
# 2) 在 postgresql.conf 中添加以下几行,并创建 recovery.signal 文件
restore_command = 'cp /var/backups/pg_wal_archive/%f %p'
recovery_target_time = '2026-09-23 09:00:00+03'
# pg_hba.conf - 仅允许应用服务器连接
host appdb app_user 10.0.0.5/32 scram-sha-256
-- SQL (psql):安装扩展(完全自由 —— 自托管特有)
CREATE EXTENSION IF NOT EXISTS vector;
CREATE EXTENSION IF NOT EXISTS postgis;
CREATE EXTENSION IF NOT EXISTS pg_cron;
# 连接池(PgBouncer, pgbouncer.ini)
[databases]
appdb = host=127.0.0.1 port=5432 dbname=appdb
[pgbouncer]
pool_mode = transaction
max_client_conn = 500
default_pool_size = 25-- SQL (Supabase SQL Editor): 1) 创建表并开启 RLS(Data API 强制要求)
create table public.notes (
id uuid default gen_random_uuid() primary key,
user_id uuid references auth.users not null,
content text not null,
created_at timestamptz default now()
);
alter table public.notes enable row level security;
create policy "kullanicilar kendi notlarini okur"
on public.notes for select
using (auth.uid() = user_id);
create policy "kullanicilar kendi notlarini yazar"
on public.notes for insert
with check (auth.uid() = user_id);
// 2) 使用 supabase-js 查询(RLS 自动生效)
import { createClient } from '@supabase/supabase-js'
const supabase = createClient(
process.env.SUPABASE_URL!,
process.env.SUPABASE_ANON_KEY!
)
const { data: notes, error } = await supabase
.from('notes')
.select('id, content, created_at')
.order('created_at', { ascending: false })
// 3) Postgres 客户端连接字符串(参见官方 "Endpoints and IP versions" 表)
// Direct connection(长驻后端、pg_dump、迁移场景):
// postgresql://postgres:[YOUR-PASSWORD]@db.[PROJECT-REF].supabase.co:5432/postgres
// Dedicated pooler(仅 transaction 模式,付费套餐可用):
// postgresql://postgres:[YOUR-PASSWORD]@db.[PROJECT-REF].supabase.co:6543/postgres
// 手动拼接连接串:从 Dashboard > Connect 页面复制(shared pooler 的 host 无法从区域直接推导)。这个决定没有唯一正确答案。如果你是小团队且优先考虑速度,那么 Supabase 就是正确选择:auth、storage、realtime 和连接池都已就绪。若负载可预测、有数据落地要求(17 个区域中没有土耳其),或成本随用户数增长,则自建 PostgreSQL 更胜一筹。一个警示:官方文档写明,自托管时托管式备份/PITR 会被禁用——掌控权到手的同时也接手了恢复演练。备份本身不是判断标准;能否恢复才是。
获取免费咨询由于 Supabase 使用标准 PostgreSQL,你可以通过 `pg_dump`/`pg_dumpall` 或原生 Postgres 复制导出数据;官方文档以一个 Node.js 脚本示例说明了项目间迁移(含 auth/storage)。而在自托管端重建 Auth、Storage、Realtime 等 Supabase 专属服务(通过 Docker Compose 运行官方自托管技术栈)是另一项工作——迁移数据与搭建对等服务是两个不同的步骤。