100K+ 记录网站最佳数据库：Supabase vs Firebase vs PlanetScale 测试
关于数据库的真实测试报告：Supabase vs Firebase vs PlanetScale
大多数"Supabase vs Firebase"的文章都是那种在各平台快速搭建一个待办事项应用就算完事的人写的。我在Supabase PostgreSQL上运行了五个生产网站，超过25.3万条记录，已经运行了一年多。我针对真实客户项目评估过Firebase Firestore、PlanetScale、Neon和Turso——不是假设场景，而是真实项目。以下是我的实际发现。
如果你正在构建需要处理10万+条记录、复杂查询、实时功能和身份验证的网络应用，你的数据库选择将在多年内定义你的架构。选错了，你要么在六个月内重写数据层，要么付出三倍的成本。我想帮你避免两种情况都发生。
目录
- 为什么存在这个比较
- 竞争者一览
- Supabase PostgreSQL：我们的生产主力
- Firebase Firestore：优势与劣势
- PlanetScale：优秀的数据库，不完整的平台
- Neon：纯粹主义者的选择
- Turso：边缘优先的SQLite
- 功能对比
- 10万+条记录的性能基准
- 10万条记录工作量的定价分析
- 你应该选择哪个数据库？
- 常见问题
为什么存在这个比较
在Social Animal，我们使用Next.js和Astro为需要动态、数据量大的网站的客户构建无头网络应用。想象一下拥有5万+条列表的企业目录、生成数千个页面的程序化SEO网站，以及需要实时更新的SaaS仪表板。
当客户带来一个涉及10万+条记录的项目时，数据库讨论在第一天就开始。这不是事后考虑的。你的数据库选择会影响你的身份验证策略、API设计、托管成本以及你六个月后发布功能的能力。
我不会假装在所有五个数据库上运行过完全相同的生产工作量。那会不诚实。我做的是在Supabase上运行了认真的生产工作（25.3万+条记录，五个网站，14个月），并对特定客户项目的替代方案进行了彻底的技术评估。我会明确哪些数据来自生产，哪些来自评估。
竞争者一览
在深入之前，这是快速概览：
- Supabase -- PostgreSQL，包含全套功能（身份验证、存储、实时、边缘函数）
- Firebase Firestore -- Google的NoSQL文档数据库，拥有出色的移动SDK
- PlanetScale -- 无服务器MySQL，具有数据库分支功能（由Vitess驱动）
- Neon -- 无服务器PostgreSQL，具有分支和缩放到零功能
- Turso -- 边缘分布式SQLite（由libSQL驱动）
每一个都擅长做某些事情。问题是这些事情是否与你正在构建的东西相匹配。
Supabase PostgreSQL：我们的生产主力
我先从Supabase开始，因为这是我们拥有最深入经验的地方。在五个生产网站中，我们最大的表有13.7万行（一个国家地址系统的目录项目），整个数据库总共拥有25.3万+条记录。
我们每天使用的功能
**行级安全（RLS）**可能是决定我们选择的功能。当你构建多租户应用时——大多数无头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对于语义搜索来说是一个启示。我们在一个内容丰富的网站上实现了它，其中传统的全文搜索效果不佳。用户会搜索"靠近市中心的地方吃饭"，并期望得到包括餐厅、咖啡馆和食品车的结果——即使这些确切的词汇不在列表中。
-- 创建向量列
ALTER TABLE listings ADD COLUMN embedding vector(1536);
-- 创建索引（这在10万+条记录时很重要）
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;
在13.7万条记录和1536维向量的情况下，这个查询在Supabase的Pro计划上返回约45毫秒。这足够快用于实时搜索即输入。
PostGIS地理查询驱动我们的位置功能。在半径内查找列表、按距离排序、计算行程时间——全部在数据库级别处理，而不是在应用代码中。
-- 找到距离一个点10公里内的列表，按距离排序
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完美无缺。当浏览10万+行的表时，仪表板可能会缓慢。表编辑器对于小型数据集很好，但对于批量操作来说很痛苦——你会想直接使用SQL。他们的边缘函数由Deno驱动，这意味着某些Node.js包不能工作。如果你需要为无服务器环境连接池，你必须使用他们的Supavisor连接字符串（截至2025年初，他们已弃用PgBouncer）。
此外，他们的免费层对开发来说真的很慷慨，但数据库空间有500MB的硬限制。对于拥有10万+条记录的生产环境，你至少需要Pro计划（25美元/月）。
Firebase Firestore：优势与劣势
我们在2024年对两个客户项目认真评估了Firebase。一个是具有离线同步要求的移动优先应用。另一个是具有复杂过滤的目录网站。
Firebase真正胜出的地方
Firebase的实时同步移动应用仍然是同类最佳。离线持久化、自动冲突解决和与iOS/Android SDK的紧密集成使其成为如果你的主要平台是移动的明显选择。Google Auth集成非常简单——几行代码，你就拥有Sign-in with Google、Apple、电话号码和电子邮件/密码。
Firebase Crashlytics、Remote Config和Analytics形成了一个没有其他平台能匹配的移动开发生态系统。如果你主要构建移动应用，其次是网络应用，Firebase值得认真考虑。
为什么我们选择了Supabase
Firestore是一个文档数据库。没有joins。认真考虑这一点。
当你构建一个列表有类别、标签、位置、评论和用户档案的目录时，你需要关系数据。在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按文档读取收费。上面的三查询模式？每个查询中的每个文档都计入计费。在拥有10万+条记录和中等流量的情况下，你的账单变得真正不可预测。我们听过开发者吃惊的故事，他们没有意识到他们的查询扫描的文档比预期的要多，导致400美元以上的意外账单。
Firestore也没有pgvector或PostGIS的等效物。你可以执行基本的geohash查询，但与真正的空间索引相比，它们是近似且有限的。
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进行实时以及一个单独的向量数据库进行搜索，你就在管理五个服务而不是一个。你的账单更高，复杂性更高，调试表面积巨大。
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——世界上部署最广的数据库——并使其分布式。你的数据存在于边缘，靠近用户，这意味着读取延迟可以极低（全球<10ms）。
Turso闪闪发光的地方
对全球受众的读取繁重工作负载。如果你向全球用户提供不经常变化的内容，Turso的边缘复制给你数据库读取，感觉是即时的。他们的嵌入式副本功能让你直接将SQLite副本捆绑到你的应用中。
对于使用Astro构建的静态网站，需要轻量级数据层，Turso很有吸引力。
为什么它不适合我们的需求
我们的10万+条记录工作负载涉及大量写入——用户提交、管理员更新、评论创建、实时数据变化。SQLite的写入模式（单个写入者）在规模上变成瓶颈。Turso通过他们的libSQL fork更好地处理这个问题，但它仍然不是为写入繁重的10万+条记录应用设计的。
没有向量搜索。没有PostGIS等效物。与PostgreSQL或MySQL相比生态系统有限。对于我们的目录和SaaS项目，这些是交易破裂者。
功能对比
这是基于我们的生产经验和截至2025年中期的评估的完整比较表：
| 功能 | Supabase | Firebase | PlanetScale | Neon | Turso |
|---|---|---|---|---|---|
| 数据库类型 | PostgreSQL | NoSQL (Firestore) | MySQL (Vitess) | PostgreSQL | SQLite (libSQL) |
| 内置身份验证 | ✅ 是 | ✅ 是 | ❌ 否 | ❌ 否 | ❌ 否 |
| 向量搜索 | ✅ pgvector | ❌ 否 | ❌ 否 | ✅ pgvector | ❌ 否 |
| 地理查询 | ✅ PostGIS | ⚠️ 有限（Geohash） | ⚠️ 基础MySQL空间 | ✅ PostGIS | ❌ 否 |
| 实时 | ✅ 是 | ✅ 是 | ❌ 否 | ❌ 否 | ❌ 否 |
| 文件存储 | ✅ 是 | ✅ 是 | ❌ 否 | ❌ 否 | ❌ 否 |
| 边缘函数 | ✅ Deno基础 | ✅ Cloud Functions | ❌ 否 | ❌ 否 | ❌ 否 |
| Joins/关系 | ✅ 完整SQL | ❌ 无joins | ✅ 完整SQL | ✅ 完整SQL | ✅ SQL（有限） |
| 分支 | ⚠️ 通过迁移 | ❌ 否 | ✅ 原生 | ✅ 原生 | ❌ 否 |
| 缩放到零 | ❌ 否 | ✅ 是 | ✅ 是 | ✅ 是 | ✅ 是 |
| 定价可预测性 | 🟢 高（固定层级） | 🔴 低（按读取） | 🟡 中等 | 🟢 高 | 🟢 高 |
| 开源 | ✅ 是 | ❌ 否 | ❌ 否（Vitess是） | ✅ 是 | ✅ 是 |
| 自托管 | ✅ 是 | ❌ 否 | ❌ 否 | ❌ 否 | ✅ 是 |
10万+条记录的性能基准
这些数字来自我们的生产Supabase实例（Pro计划，us-east-1地区），主表中有13.7万行。对于其他数据库，我使用的是已发布的基准和我们使用10万条综合记录进行的评估测试。
| 查询类型 | Supabase | Firebase | PlanetScale | Neon | Turso |
|---|---|---|---|---|---|
| 按ID简单SELECT | 3ms | 8ms | 4ms | 5ms | 1ms |
| 过滤查询（索引） | 12ms | 15ms | 10ms | 14ms | 3ms |
| 复杂JOIN（3个表） | 35ms | N/A（无joins） | 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在边缘优势。PlanetScale的MySQL引擎在我们的测试中处理joins的速度略快于PostgreSQL。Neon的冷启动是显著的（300ms），因为它需要唤醒计算，尽管后续查询很快。Firebase缺乏joins意味着你根本无法运行某些查询。
Supabase的始终开启计算（Pro上没有缩放到零）意味着零冷启动，这对用户面向的应用很重要，因为那第一个请求不能慢。
10万条记录工作量的定价分析
让我们对一个真实的10万条记录应用建模：一个拥有10万个列表、5万月活用户、约200万数据库读取/月、5万次写入/月、5GB数据库大小、10GB文件存储的目录网站。
| Supabase Pro | Firebase (Blaze) | PlanetScale Scaler | Neon Launch | Turso Scaler | |
|---|---|---|---|---|---|
| 基础成本 | 25美元/月 | 0美元（按用量付费） | 39美元/月 | 19美元/月 | 29美元/月 |
| 数据库 | 包含（8GB） | ~18美元（读+写） | 包含（10GB） | 包含（10GB） | 包含（9GB） |
| 身份验证 | 包含（5万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存储和5万月活用户的身份验证。
你应该选择哪个数据库？
基于用这些工具构建，这是我的诚实建议：
选择Supabase如果你正在构建拥有关系数据的网络应用，需要在一个平台中使用身份验证+存储+实时，想要PostgreSQL的生态系统（pgvector、PostGIS、全文搜索），或者你使用Next.js构建。这涵盖了我们看到的大约80%的项目。
选择Firebase如果你构建移动优先应用，离线同步很重要，你的团队已经知道Firebase生态系统，或者你的数据真正是文档形状的（聊天消息、活动源、简单用户档案）。
选择PlanetScale如果你有一个强大的MySQL团队，需要数据库分支进行复杂的模式管理，并且你已经为身份验证和存储使用单独的服务。这是一个很好的数据库——只是不是完整的平台。
选择Neon如果你想要没有平台开销的PostgreSQL，更喜欢从最佳的独立服务组装你自己的栈，或者需要缩放到零以优化低流量项目的成本。
选择Turso如果你构建读取繁重、全球分布的应用，其中边缘延迟比写入吞吐量重要，或者你使用Astro在内容焦点网站上工作。
对于我们在Social Animal构建无头网络应用的工作，Supabase一直是正确的选择。一体化平台意味着更快的开发、更简单的架构和可预测的成本。我们已将其扩展到25.3万+条记录，没有任何问题。如果你正在计划这个规模的项目并想讨论架构，联系我们——我们已经做过几次了。
常见问题
Supabase对于大规模应用是否不错？ 是的，我们有生产证据来支持这一点。我们在Supabase Pro上运行五个生产网站的25.3万+条记录。查询性能保持一致——我们最复杂的带向量相似性搜索的joins在13.7万行时返回时间少于50ms。Supabase运行在标准PostgreSQL上，它驱动比我们大多数人会构建的任何东西更多数量级的应用。平台层（身份验证、存储、实时）是更新的部分，但对我们来说自2024年初以来一直稳定。
Supabase定价与Firebase在规模上如何比较？ Supabase戏剧性地更可预测。他们的Pro计划是统一的25美元/月，包括5万MAU的身份验证、8GB数据库存储、250GB带宽和100GB文件存储。Firebase按文档读取、写入和删除收费——这使成本高度变量。一个10万条记录的应用，每月200万读取，在Firebase上可能花费15到200美元以上，取决于查询模式。我们看到Facebook的账单一夜间翻了三倍，当一个页面在社交媒体上被分享时。
PlanetScale能处理10万+条记录吗？ 绝对。PlanetScale运行Vitess，它驱动YouTube规模的工作负载。对于拥有10万条记录的原始数据库性能，PlanetScale是优秀的。限制不是规模——是完整性。你需要为身份验证、文件存储、实时更新和向量搜索添加单独的服务。那总共增加成本（90美元+/月）和与Supabase的一体化方法相比的架构复杂性。
什么是pgvector，为什么它很重要？ pgvector是一个PostgreSQL扩展，直接在你的数据库中存储和查询向量嵌入。这启用语义搜索——用户可以按意思而不是精确关键词搜索。对于拥有10万+个列表的目录，这意味着搜索"适合儿童的早午餐地点"可以返回标记为"家庭餐厅"或"周末早餐"的结果，即使这些词不匹配。没有pgvector，你需要一个单独的向量数据库，如Pinecone（70美元+/月），并处理让两个数据库保持同步的问题。
Firebase Firestore对于目录网站是否不错？ 坦率地说，不是。目录网站本质上是关系的。列表属于类别，有标签、接收来自用户的评论，并需要复杂的过滤（"显示我距离5英里以内、4星及以上、现在开放的餐厅"）。Firestore不能做joins，有有限的查询操作符，并按文档读取收费——这意味着复杂的过滤查询变得快速昂贵。我们评估了Firestore进行一个目录项目，并估计与Supabase相比开发时间是4倍，由于数据反规范化和客户端查询解决方案。
对于我的Next.js应用，我应该使用Neon还是Supabase？ 如果你只需要一个数据库，Neon提供更好的价值（免费层是慷慨的，19美元/月的Launch计划是坚实的）。如果你需要身份验证、存储、实时或边缘函数——大多数生产Next.js应用都需要——Supabase节省你从集成和支付多个单独服务的工作。我们为Next.js开发项目使用Supabase，因为集成身份验证和存储从典型项目时间表中切掉了数周。
最佳的程序化SEO网站数据库是什么？ Supabase PostgreSQL。程序化SEO网站从结构化数据生成数千个页面，这意味着你需要快速查询、好的索引和处理复杂数据关系的能力。我们在Supabase上构建了程序化SEO网站，从单个数据库生成10000+页——位置页面的PostGIS、相关内容的pgvector和动态过滤的全文搜索。统一定价意味着来自Google索引的流量增长不会吹爆你的账单。
Turso（libSQL）对于生产网络应用是否准备好了？ 对于读取繁重的应用，是的。Turso的边缘复制SQLite给你全球子5毫秒读取，这对内容焦点网站是不可思议的。但对于写入繁重的应用，有10万+条记录——如用户提交数据、管理员面板处理更新、评论持续进来的目录——SQLite的单个写入者模型变成限制。我们会为使用Astro构建的内容网站推荐Turso，对于具有重要写入工作负载的动态应用推荐Supabase或Neon。