100K+ 记录网站的最佳数据库：Supabase vs Firebase vs PlanetScale 实测对比
大多数关于 "Supabase vs Firebase" 的文章都是由那些在每个平台上快速搭建了一个待办事项应用就宣告完成的人写的。我在 Supabase PostgreSQL 上运行了 253,000+ 条记录，跨越 5 个生产网站，已经有一年多了。我针对真实的客户项目（而不是假设性的项目）评估了 Firebase Firestore、PlanetScale、Neon 和 Turso。这是我真正发现的。
如果你正在构建一个需要处理 100K+ 条记录、具有复杂查询、实时功能和身份验证的网络应用，你的数据库选择将在多年内定义你的架构。选择错误，要么在六个月内重写数据层，要么支付是应该支付的 3 倍。我想让你避免两者都遭遇。
目录
- 为什么存在这个对比
- 竞争者一览
- Supabase PostgreSQL：我们的生产主力
- Firebase Firestore：它的优势和劣势
- PlanetScale：很好的数据库，不完整的平台
- Neon：纯粹主义者的选择
- Turso：边缘优先的 SQLite
- 逐项功能对比
- 100K+ 记录的性能基准测试
- 100K 记录工作负载的定价分析
- 你应该选择哪个数据库
- 常见问题
为什么存在这个对比
在 Social Animal，我们构建无头网络应用——主要使用 Next.js 和 Astro——为需要动态、数据密集型网站的客户服务。想想拥有 50K+ 列表的企业目录、生成数千个页面的程序化 SEO 网站，以及需要实时更新的 SaaS 仪表板。
当客户来找我们时，提出一个涉及 100K+ 条记录的项目，数据库对话在第一天就发生。这不是事后考虑。你的数据库选择会波及你的身份验证策略、API 设计、托管成本，以及你在六个月后能否推出功能。
我不会假装我在所有五个数据库上运行了相同的生产工作负载。那会不诚实。我所做的是在 Supabase 上运行真正的生产环境（253K+ 条记录，5 个网站，14 个月），并对特定客户项目的替代方案进行了彻底的技术评估。我会明确说明哪些数据来自生产，哪些来自评估。
竞争者一览
在深入之前，这是快速的概览：
- Supabase —— PostgreSQL 加上所有必需的东西（身份验证、存储、实时、边缘函数）
- Firebase Firestore —— Google 的 NoSQL 文档数据库，具有出色的移动 SDK
- PlanetScale —— 无服务器 MySQL，具有数据库分支（由 Vitess 提供支持）
- Neon —— 无服务器 PostgreSQL，具有分支和缩放到零
- Turso —— 边缘分布式 SQLite（由 libSQL 提供支持）
每一个都真正擅长某些事情。问题是这个某些事情是否与你正在构建的东西匹配。
Supabase PostgreSQL：我们的生产主力
我从 Supabase 开始，因为这是我们经验最深的地方。在 5 个生产网站中，我们最大的表有 137K 行（一个目录项目的国家地址系统），我们在所有数据库中总共有 253K+ 条记录。
我们日常使用的功能
行级安全 (RLS) 可能是为我们决定采用 Supabase 的功能。当你构建多租户应用时——大多数 无头 CMS 驱动的网站 最终都会变成这样——你需要每个用户的数据隔离。使用 RLS，安全逻辑存在于数据库本身。你的 API 层不需要记住在每次查询时都按 user_id 过滤。数据库强制执行它。
这是在我们项目中的典型 RLS 策略：
-- 用户只能看到他们自己组织的列表
CREATE POLICY "org_isolation" ON listings
FOR SELECT
USING (org_id = (SELECT org_id FROM profiles WHERE id = auth.uid()));
-- 管理员可以看到一切
CREATE POLICY "admin_access" ON listings
FOR ALL
USING (EXISTS (
SELECT 1 FROM profiles
WHERE id = auth.uid() AND role = 'admin'
));
这是真正的 SQL。这不是专有 DSL。如果你曾需要离开 Supabase，这些策略可以转换到任何 PostgreSQL 主机。
pgvector 对于语义搜索来说是一个启示。我们在一个内容丰富的网站上实现了它，传统全文搜索没有起到应有的作用。用户会搜索 "downtown 附近的用餐地点"，并期望得到包括餐厅、咖啡馆和食品卡车的结果——即使这些确切的词不在列表中。
-- 创建向量列
ALTER TABLE listings ADD COLUMN embedding vector(1536);
-- 创建索引（在 100K+ 记录时这很重要）
CREATE INDEX ON listings USING ivfflat (embedding vector_cosine_ops)
WITH (lists = 100);
-- 语义搜索查询
SELECT id, name, 1 - (embedding <=> $1) AS similarity
FROM listings
WHERE 1 - (embedding <=> $1) > 0.78
ORDER BY embedding <=> $1
LIMIT 20;
在 137K 条记录、1536 维向量的情况下，此查询在 Supabase 的 Pro 计划上在 ~45ms 内返回。这足够快以支持实时搜索即输入。
PostGIS 地理查询支持我们的位置基础功能。查找半径内的列表、按距离排序、计算行车时间——所有这些都在数据库级别处理，而不是在应用代码中。
-- 查找距离一个点 10km 内的列表，按距离排序
SELECT id, name,
ST_Distance(location, ST_MakePoint(-73.9857, 40.7484)::geography) AS distance_m
FROM listings
WHERE ST_DWithin(
location,
ST_MakePoint(-73.9857, 40.7484)::geography,
10000
)
ORDER BY distance_m
LIMIT 50;
实时订阅 让我们构建实时仪表板，而不需要 WebSocket 基础设施。客户的管理面板显示新提交瞬间出现，因为我们订阅相关表上的 INSERT 事件。零额外基础设施。
什么不是完美的
我不会假装 Supabase 是完美的。当你浏览具有 100K+ 行的表时，仪表板可能会很慢。表编辑器对小数据集是可以的，但对于批量操作来说很痛苦——你需要直接使用 SQL。它们的边缘函数由 Deno 驱动，这意味着某些 Node.js 包不起作用。如果你需要无服务器环境的连接池，你必须使用它们的 Supavisor 连接字符串（截至 2025 年初，他们已弃用 PgBouncer）。
此外，他们的免费层对于开发来说是真正的慷慨，但有 500MB 数据库空间的硬限制。对于具有 100K+ 条记录的生产，你至少需要 Pro 计划（$25/月）。
Firebase Firestore：它的优势和劣势
我们在 2024 年认真评估了 Firebase 的两个客户项目。一个是具有离线同步需求的移动优先应用。另一个是具有复杂过滤的目录网站。
Firebase 真正擅长的地方
Firebase 对移动应用的实时同步仍然是同类最佳的。离线持久化、自动冲突解决和与 iOS/Android SDK 的紧密集成使其在主要平台是移动时成为显而易见的选择。Google Auth 集成非常简单——几行代码，你就有了使用 Google 登录、Apple、电话号码和电子邮件/密码。
Firebase Crashlytics、Remote Config 和 Analytics 形成了没有其他产品可以匹配的移动开发生态系统。如果你首先构建移动应用，其次构建网络应用，Firebase 值得认真考虑。
为什么我们选择了 Supabase
Firestore 是一个文档数据库。没有 JOIN。让这沉入你的脑子。
当你构建一个具有列表的目录，这些列表有类别、标签、位置、评论和用户档案时，你需要关系数据。在 Firestore 中，你要么对所有内容进行非规范化（跨文档复制数据并祈祷保持同步），要么你进行多次往返查询并在应用代码中 JOIN 数据。
这是在每个数据库中 "按类别查找列表与平均评分" 的样子：
-- Supabase：一个查询，完成
SELECT l.*, c.name AS category_name,
AVG(r.rating) AS avg_rating,
COUNT(r.id) AS review_count
FROM listings l
JOIN categories c ON l.category_id = c.id
LEFT JOIN reviews r ON r.listing_id = l.id
WHERE c.slug = 'restaurants'
GROUP BY l.id, c.name
ORDER BY avg_rating DESC
LIMIT 20;
// Firestore：三个查询 + 客户端 JOIN
const categorySnap = await db.collection('categories')
.where('slug', '==', 'restaurants').get();
const categoryId = categorySnap.docs[0].id;
const listingsSnap = await db.collection('listings')
.where('categoryId', '==', categoryId).get();
// 现在获取每个列表的评论...
// 然后在应用代码中计算平均值...
// 然后排序...你明白了。
真正的症结是：Firestore 按文档读取计费。上面的三查询模式？每个查询中的每个文档都计数。在 100K+ 条记录和适度流量的情况下，你的账单变得真正不可预测。我们听说过开发人员的恐怖故事，他们没有意识到他们的查询扫描的文档比预期要多，出现了 $400+ 的意外账单。
Firestore 也没有 pgvector 或 PostGIS 的等价物。你可以进行基本的地理哈希查询，但与真实的空间索引相比，它们是近似的和受限的。
PlanetScale：很好的数据库，不完整的平台
PlanetScale 在引擎盖下运行 Vitess —— 与支持 YouTube 数据库相同的技术。对于纯 MySQL 性能，它很好。他们的数据库分支功能（创建分支、进行模式更改、合并回来）确实是创新的，我希望 Supabase 本身有。
PlanetScale 做得好的事情
他们的无服务器驱动很快。连接管理为你处理，在无服务器环境中这非常重要，在这种环境中，每次函数调用可能会打开一个新的数据库连接。模式分支使数据库迁移感觉像 Git 拉取请求——安全、可审查、可逆。
对于拥有强大 MySQL 专业知识并构建传统网络应用的团队，PlanetScale 是坚实的。
缺失的东西
PlanetScale 只是一个数据库。就这样。比较你需要构建一个完整的应用堆栈的东西：
| 功能 | Supabase | PlanetScale + 附加项 |
|---|---|---|
| 数据库 | ✅ 包含 | ✅ 包含 |
| 身份验证 | ✅ 包含 | ❌ 需要 Clerk ($25+/月) 或 Auth0 |
| 文件存储 | ✅ 包含 | ❌ 需要 S3 或 Cloudflare R2 |
| 实时 | ✅ 包含 | ❌ 需要 Pusher 或 Ably |
| 向量搜索 | ✅ pgvector | ❌ 不可用 |
| 地理查询 | ✅ PostGIS | ❌ 基本 MySQL 空间 |
| 边缘函数 | ✅ 包含 | ❌ 需要单独部署 |
通过为身份验证添加 Clerk、为存储添加 S3、为实时添加 Pusher，以及为搜索添加单独的向量数据库，你是在管理 5 项服务而不是一项。你的账单更高、复杂性更高，调试表面积也很大。
PlanetScale 还在 2024 年 4 月停止了他们的免费层（Hobby 计划），所以现在入场点是他们 Scaler 计划的 $39/月。这比 Supabase Pro 更昂贵，并提供的功能更少。
Neon：纯粹主义者的选择
Neon 是我如果只需要 PostgreSQL 就会选择的数据库。他们的无服务器架构确实令人印象深刻——缩放到零意味着当你的数据库不被查询时你什么都不支付。他们的分支功能对于预览部署很出色（为每个 PR 启动一个数据库分支）。
Neon 支持 pgvector 和 PostGIS，因为它是标准 PostgreSQL。所以你获得向量搜索和地理查询。原始数据库功能与 Supabase 几乎相同。
为什么我们仍然选择 Supabase
Neon 是一个数据库。Supabase 是一个平台。使用 Neon，你需要添加：
- 身份验证 —— Clerk、Auth0 或自己构建
- 存储 —— S3、Cloudflare R2 或类似
- 实时 —— Pusher、Ably 或自定义 WebSocket 服务器
- 边缘函数 —— 在 Cloudflare Workers 或 Vercel 上单独部署
对于某些团队，这种模块化方法实际上更可取。如果你已经对身份验证有意见（以及 Clerk 的预算），为一切使用 S3，并且不需要实时，Neon 的专注方法意味着更少的供应商锁定。
但对于我们的 无头开发项目，在一个仪表板中拥有身份验证、存储和实时，一个账单和一组 API 密钥，价值很大。开发人员速度在你在紧密时间表上交付客户项目时很重要。
Neon 的定价也很有竞争力：他们的免费层包括 0.5GB 存储和 190 计算小时/月。$19/月的 Launch 计划提供 10GB。对于纯数据库来说，这是无服务器 PostgreSQL 中的最佳价值。
Turso：边缘优先的 SQLite
Turso 是有趣的技术。他们采用了 SQLite——部署最广泛的数据库——并使其分布式。你的数据生活在边缘，靠近你的用户，这意味着读取延迟可能非常低（全球 sub-10ms）。
Turso 闪耀的地方
读取密集型工作负载，具有全球受众。如果你为全球的用户提供不经常更改的内容，Turso 的边缘复制为你提供感觉即时的数据库读取。他们的嵌入式副本功能让你直接在应用中捆绑 SQLite 副本。
对于使用 Astro 的静态网站，需要轻量级数据层，Turso 是令人信服的。
为什么它不符合我们的需求
我们的 100K+ 记录工作负载涉及大量写入——用户提交、管理员更新、评论创建、实时数据更改。SQLite 的写入模型（单写入者）在规模上成为瓶颈。Turso 通过他们的 libSQL 分支更好地处理这个问题，但它仍然不是为写入密集的 100K+ 记录应用设计的。
没有向量搜索。没有 PostGIS 等价物。与 PostgreSQL 或 MySQL 相比，生态系统有限。对于我们的目录和 SaaS 项目，这些是破坏交易的问题。
逐项功能对比
这是基于我们的生产经验和截至 2026 年中旬的评估的完整对比表：
| 功能 | Supabase | Firebase | PlanetScale | Neon | Turso |
|---|---|---|---|---|---|
| 数据库类型 | PostgreSQL | NoSQL (Firestore) | MySQL (Vitess) | PostgreSQL | SQLite (libSQL) |
| 内置身份验证 | ✅ 是 | ✅ 是 | ❌ 否 | ❌ 否 | ❌ 否 |
| 向量搜索 | ✅ pgvector | ❌ 否 | ❌ 否 | ✅ pgvector | ❌ 否 |
| 地理查询 | ✅ PostGIS | ⚠️ 有限 (Geohash) | ⚠️ 基本 MySQL 空间 | ✅ PostGIS | ❌ 否 |
| 实时 | ✅ 是 | ✅ 是 | ❌ 否 | ❌ 否 | ❌ 否 |
| 文件存储 | ✅ 是 | ✅ 是 | ❌ 否 | ❌ 否 | ❌ 否 |
| 边缘函数 | ✅ Deno 基础 | ✅ 云函数 | ❌ 否 | ❌ 否 | ❌ 否 |
| JOINs / 关系 | ✅ 完整 SQL | ❌ 没有 JOIN | ✅ 完整 SQL | ✅ 完整 SQL | ✅ SQL（有限） |
| 分支 | ⚠️ 通过迁移 | ❌ 否 | ✅ 本地 | ✅ 本地 | ❌ 否 |
| 缩放到零 | ❌ 否 | ✅ 是 | ✅ 是 | ✅ 是 | ✅ 是 |
| 定价可预测性 | 🟢 高（固定层） | 🔴 低（按读取） | 🟡 中等 | 🟢 高 | 🟢 高 |
| 开源 | ✅ 是 | ❌ 否 | ❌ 否 (Vitess 是) | ✅ 是 | ✅ 是 |
| 自托管 | ✅ 是 | ❌ 否 | ❌ 否 | ❌ 否 | ✅ 是 |
100K+ 记录的性能基准测试
这些数字来自我们的生产 Supabase 实例（Pro 计划，us-east-1 区域），主表中有 137K 行。对于其他数据库，我使用发布的基准和我们使用 100K 合成记录的评估测试。
| 查询类型 | Supabase | Firebase | PlanetScale | Neon | Turso |
|---|---|---|---|---|---|
| 按 ID 简单 SELECT | 3ms | 8ms | 4ms | 5ms | 1ms |
| 过滤查询（索引） | 12ms | 15ms | 10ms | 14ms | 3ms |
| 复杂 JOIN（3 表） | 35ms | N/A (没有 JOIN) | 28ms | 38ms | 25ms |
| 向量相似性（前 20） | 45ms | N/A | N/A | 42ms | N/A |
| 地理半径（10km） | 22ms | ~50ms (geohash) | N/A | 24ms | N/A |
| 全文搜索 | 18ms | N/A (使用 Algolia) | 15ms | 20ms | 12ms |
| 批量 INSERT（1000 行） | 180ms | 250ms | 150ms | 195ms | 320ms |
| 冷启动（无服务器） | N/A (总是开启) | ~100ms | ~50ms | ~300ms | ~20ms |
几件事脱颖而出。Turso 的读取性能是例外的——这是 SQLite-at-edge 的优势。PlanetScale 的 MySQL 引擎在我们的测试中处理 JOIN 的速度略快于 PostgreSQL。Neon 的冷启动很明显（300ms），因为它需要唤醒计算，尽管后续查询很快。Firebase 缺乏 JOIN 意味着你根本无法运行某些查询。
Supabase 的始终开启计算（Pro 上没有缩放到零）意味着零冷启动，对于用户面向的应用很重要，其中第一个请求不能很慢。
100K 记录工作负载的定价分析
让我们模拟一个真实的 100K 记录应用：拥有 100K 个列表的目录网站，50K 月活跃用户，~200 万数据库读取/月，~50K 写入/月，5GB 数据库大小，10GB 文件存储。
| Supabase Pro | Firebase (Blaze) | PlanetScale Scaler | Neon Launch | Turso Scaler | |
|---|---|---|---|---|---|
| 基础成本 | $25/月 | $0（按使用付费） | $39/月 | $19/月 | $29/月 |
| 数据库 | 包含 (8GB) | ~$18（读取 + 写入） | 包含 (10GB) | 包含 (10GB) | 包含 (9GB) |
| 身份验证 | 包含 (50K MAU) | 包含 | +$25/月 (Clerk) | +$25/月 (Clerk) | +$25/月 (Clerk) |
| 存储 (10GB) | 包含 | ~$3/月 | +$2/月 (R2) | +$2/月 (R2) | +$2/月 (R2) |
| 实时 | 包含 | 包含 | +$25/月 (Pusher) | +$25/月 (Pusher) | +$25/月 (Pusher) |
| 估计总计 | $25/月 | ~$21/月 | ~$91/月 | ~$71/月 | ~$81/月 |
Firebase 看起来很便宜，直到你意识到两件事。首先，$21 的估计假设可预测的读取模式。一个病毒时刻或机器人爬取你的网站可能会大幅增加读取——你的账单也会随之增加。其次，一旦你需要向量搜索等功能，你就是在添加 Pinecone 或 Weaviate，它们的起价为 $70/月。
Supabase 为所有内容提供固定的 $25/月——数据库、身份验证、存储、实时、边缘函数——对于这个工作负载大小来说价值非常好。Pro 计划包括 8GB 数据库、250GB 带宽、100GB 存储和身份验证的 50K 月活跃用户。
你应该选择哪个数据库
这是我基于使用这些工具构建的诚实建议：
如果你正在构建具有关系数据的网络应用，在一个平台中需要身份验证 + 存储 + 实时，需要 PostgreSQL 的生态系统（pgvector、PostGIS、全文搜索），或你正在使用 Next.js 构建，请选择 Supabase。这涵盖了可能 80% 的我们看到的项目。
如果你正在构建一个移动优先应用，其中离线同步很重要，你的团队已经了解 Firebase 生态系统，或者你的数据确实是文档形状的（聊天消息、活动源、简单的用户档案），请选择 Firebase。
如果你有一个强大的 MySQL 团队，需要用于复杂模式管理的数据库分支，并且你已经为身份验证和存储使用单独的服务，请选择 PlanetScale。这是一个很好的数据库——只是不是完整的平台。
如果你想要没有平台开销的 PostgreSQL，更喜欢从同类最佳服务组装自己的堆栈，或者需要缩放到零以优化低流量项目的成本，请选择 Neon。
如果你正在构建一个读取密集、全球分布的应用，其中边缘延迟比写入吞吐量更重要，或者你使用 Astro 在内容聚焦网站上工作，请选择 Turso。
对于我们在 Social Animal 所做的工作，构建 无头网络应用，Supabase 一直是正确的选择。一体化平台意味着更快的开发、更简单的架构和可预测的成本。我们已经将其扩展到 253K+ 条记录，没有遇到问题。如果你正在规划这个规模的项目并希望讨论架构，联系我们——我们已经做过几次了。
常见问题
Supabase 对大规模应用有好的吗？
是的，我们有生产证据来支持这一点。我们在 Supabase Pro 上的 5 个生产网站中运行 253K+ 条记录。查询性能保持一致——我们最复杂的 JOIN 与 137K 行的向量相似性搜索在 50 毫秒以内返回。Supabase 在标准 PostgreSQL 上运行，它为数量级更大的应用提供动力，超过我们大多数人会构建的任何内容。平台层（身份验证、存储、实时）是较新的部分，但对我们来说从 2024 年初开始一直是稳定的。
Supabase 定价与规模上的 Firebase 相比如何？
Supabase 明显更可预测。他们的 Pro 计划是固定的 $25/月，包括 50K MAU 的身份验证、8GB 数据库存储、250GB 带宽和 100GB 文件存储。Firebase 按文档读取、写入和删除收费——这使得成本高度可变。一个拥有 200 万月读取次数的 100K 记录应用在 Firebase 上的成本可能从 $15 到 $200+ 不等，取决于查询模式。我们看到当页面在社交媒体上共享时，Firebase 账单三倍增长。
PlanetScale 能处理 100K+ 条记录吗？
绝对可以。PlanetScale 运行 Vitess，它为 YouTube 规模的工作负载提供动力。对于具有 100K 条记录的原始数据库性能，PlanetScale 很好。限制不是规模——是完整性。你需要为身份验证、文件存储、实时更新和向量搜索添加单独的服务。这增加了成本（$90+/月总计）和架构复杂性，与 Supabase 的一体化方法相比。
什么是 pgvector，为什么它重要？
pgvector 是一个 PostgreSQL 扩展，直接在你的数据库中存储和查询向量嵌入。这支持语义搜索——用户可以按意思而不是精确关键词搜索。对于拥有 100K+ 列表的目录，这意味着搜索 "kid-friendly brunch spots" 可以返回标记为 "family restaurant" 或 "weekend breakfast" 的结果，即使这些词不匹配。没有 pgvector，你需要一个单独的向量数据库，如 Pinecone（$70+/月），并处理保持两个数据库同步。
Firebase Firestore 对目录网站有好的吗？
说实话，没有。目录网站本质上是关系型的。列表属于类别，有标签，收到来自用户的评论，需要复杂的过滤（"显示我 5 英里内评分 4+ 的餐厅，现在营业"）。Firestore 无法做 JOIN，有有限的查询操作符，并按文档读取计费——这意味着复杂的过滤查询很快变得昂贵。我们为目录项目评估了 Firestore，与 Supabase 相比，由于数据非规范化和客户端查询变通方法，估计开发时间增加了 4 倍。
我应该为我的 Next.js 应用使用 Neon 还是 Supabase？
如果你只需要数据库，Neon 提供更好的价值（免费层很慷慨，$19/月 Launch 计划很稳定）。如果你需要身份验证、存储、实时或边缘函数——大多数生产 Next.js 应用都需要——Supabase 可以让你免于集成和支付多个单独服务的费用。我们为我们的 Next.js 开发项目 使用 Supabase，因为集成的身份验证和存储从典型的项目时间表中减少了几周。
程序化 SEO 网站的最佳数据库是什么？
Supabase PostgreSQL。程序化 SEO 网站从结构化数据生成数千个页面，这意味着你需要快速查询、良好的索引和处理复杂数据关系的能力。我们构建了在 Supabase 上生成 10K+ 页面的程序化 SEO 网站——用于位置页面的 PostGIS、用于相关内容的 pgvector，以及用于动态过滤的全文搜索。固定定价意味着 Google 索引的流量激增不会爆炸你的账单。
Turso (libSQL) 对生产网络应用准备好了吗？
对于读取密集型应用，是的。Turso 的边缘复制 SQLite 给你全球 sub-5ms 读取，这对内容聚焦网站来说是不可思议的。但对于写入密集型应用，有 100K+ 条记录——如用户提交数据、管理员处理更新、评论不断进来的目录——SQLite 的单写入者模型变成限制。我们会为使用 Astro 构建的内容网站推荐 Turso，而对于具有大量写入工作负载的动态应用推荐 Supabase 或 Neon。