Firestore 与 Realtime Database：哪个更好，为什么？

Source: Dev.to

Firebase 提供了两种数据库：

• Realtime Database – 原始的 JSON 树形数据库
• Cloud Firestore – 较新的面向文档的数据库

两者都支持实时同步并且可以离线使用，但它们针对不同的需求而构建。下面是一个快速对比以及我个人的选择——以及原因。

快速概览

实时数据库：它是什么以及何时表现出色

它是什么 – 一个巨大的 JSON 树。你在诸如 /users/uid/profile 或 /chats/chatId/messages 之类的路径上读取和写入。数据是嵌套的；监听一个路径会返回该路径下的所有内容（也可以使用浅读取来限制深度）。没有“按字段查询”——路径本身就充当了查询。

优势

• 简单 – 没有集合、没有索引。只需读取/写入路径。非常适合小型应用和原型。
• 延迟极低 – 直接路径访问使其非常适合高频更新（例如在线状态、光标位置、实时比分）。
• 小规模时成本低 – 当数据量和流量适中时，存储 + 带宽的计费方式可能比 Firestore 的每次操作计费模型更便宜。
• SDK 体积小 – 包大小更小，适用于受限环境。

劣势

• 没有真实查询 – 你不能“获取所有 role = admin 的用户”或“获取 createdAt > X 的消息”。必须读取路径后在客户端过滤，或进行大量去规范化。
• 扩展性与深度限制 – 深层树结构和宽度分叉（例如一次写入触及许多节点）扩展性不佳；可能需要扁平化或拆分数据。
• 仅树形结构 – 关系和多对多操作笨拙，常导致数据重复和额外的同步逻辑。

何时使用

• 简单的实时应用（在线状态、基础聊天、实时计数器）
• 原型或概念验证
• 数据天然呈树形且查询需求极少的场景
• 已经基于实时数据库构建的项目，且迁移成本不值得

Firestore：它是什么以及何时闪耀

What it is – A document database. Data lives in collections (e.g., users, chats); each document has an ID and key‑value (and nested) data. Documents can contain subcollections (e.g., chats/chatId/messages). Queries use where, orderBy, limit, and compound indexes. Real‑time listeners work on collections or query results.

优势

• Rich queries – “Users where role == 'admin'”、 “messages where chatId == X orderBy createdAt limit 50”。服务器端查询和显式索引让复杂的数据访问变得轻松。
• Scales better – 多区域、自动扩展，没有单一树结构的瓶颈。非常适合大量集合和复杂访问模式。
• Clearer data model – 集合和文档与实体及关系映射良好，减少了大量去规范化的需求。
• Strong offline support – 查询和监听在离线时同样可用并支持持久化，体验与 Realtime Database 相同。

劣势

• Pricing can bite – 按读取/写入/删除计费。大量读取流量（例如每次屏幕加载都“列出所有项目”）如果没有缓存或分页会变得昂贵。
• More setup – 索引、安全规则和数据建模需要比“仅仅一个路径”更多的前期思考。
• Slightly higher latency – 灵活查询比单路径读取需要更多处理，虽然差异通常可以忽略不计。

何时使用

• 大多数新建的 Firebase 项目
• 任何需要过滤、分页或对同一数据进行多视图展示的场景
• 预计数据量和查询复杂度会增长的应用

并排比较：关键差异

哪个更适合您？

如果您需要 快速原型、简单的实时功能，或者已经深入使用 Realtime Database 项目，请继续使用 Realtime Database。它轻量、在小规模时成本低，并且对直接路径读取提供超低延迟。

如果您正在构建一个 将会成长 的 新应用，需要 复杂查询、分页，或想要 更清晰的数据模型，请选择 Firestore。它的可扩展性、查询能力以及多区域弹性使其成为更安全的长期选择，尽管您需要更仔细地管理定价和索引。

最佳？我的推荐

对于大多数今天的应用：Firestore 是更好的默认选择。

原因

• 查询 – 几乎每个应用最终都需要“按条件获取项目”或“带分页的有序列表”。Firestore 原生支持；Realtime Database 需要变通和去规范化。
• 扩展性 – 如果应用增长，Firestore 能随之扩展。Realtime Database 可能会遇到结构限制，需要大幅重构。
• 数据模型 – 文档和集合与我们对用户、聊天、帖子等的思考方式相匹配。更易维护，也更容易让新人上手。
• 生态系统和未来 – Google 正在投入 Firestore（多区域、更好的工具）。Realtime Database 稳定，但新特性首先落在 Firestore 上。

Realtime Database 仍然是最佳选择的情况

• 非常简单的实时需求 – 在线状态、实时计数器，或几乎没有查询需求的小树结构。此时简洁性和延迟比灵活性更重要。
• 在极小规模下严格控制成本 – 读写几乎为零，想要最小账单；Realtime Database 的计费可能更低。
• 已有 Realtime Database 应用 – 迁移有成本。如果当前应用简单且稳定，保持使用 Realtime Database 直至需要 Firestore 的查询和扩展能力。

总结

• 对于新项目以及任何需要查询或会增长的场景，使用 Firestore。
• 对于简单、基于路径的实时应用，或已经在使用且迁移不划算的情况，使用 Realtime Database。

在实践中，“哪个更好” = 大多数情况下选择 Firestore；Realtime Database 只适用于少数但真实的使用场景。

Saad Mehmood — Portfolio