Apple 构建了 iCloud 来存储数十亿个数据库
Apple 利用 FoundationDB 以数十亿个逻辑数据库的规模驱动 iCloud，这引发了人们对数据库与文件系统关系的比较，也凸显了现代存储架构如何模糊二者边界。评论者把这一优雅的后端与 iCloud 面向用户时常见的不可靠表现形成对照，提到照片、文件和消息多年未能稳定同步，以及缺少基于云的 Time Machine 备份。讨论还涉及谁在生产环境中运行 FoundationDB、如何处理大规模模式迁移，以及像 Obsidian 或 CouchDB 这样的替代工具为何在同步与一致性方面成功或受挫。
iCloud 的可靠性和用户体验
- 多条评论反映可靠性很差：照片和文件卡在同步状态好几天、不同设备上的照片数量不一致，以及进度/状态不透明。
- 有些用户通过删除本地 iCloud 数据或使用 Apple 的故障排除工具解决了问题，但也有人说这些办法无效，或者需要等待数小时。
- iMessage / “Messages in iCloud” 被描述为不稳定：已读/未读和删除状态经常无法在 macOS 和 iOS 之间一致同步。
- 用户很难控制哪些项目保存在本地、哪些被卸载到云端，尤其是在 iPhone 上，导致频繁重新下载，以及离线行为不可用。
- 有些人已经完全放弃使用 iCloud 进行文件同步，因为即使是第三方同步工具，Apple 的 FileProvider API 也会强推“优化存储”的行为。
数据库与文件系统的讨论
- 若干评论认为，在更高的抽象层次上，文件系统和数据库很相似：二者都把键/路径映射到 blob/记录，并且可以彼此之上分层构建。
- 也有人强调重要的实际差异：查询能力、事务/ACID 语义、性能敏感性，以及对磁盘的“机械同理心”。
- 讨论中提到了历史和实验性系统：WinFS、ReiserFS、BeOS 的 BeFS、Oracle DBFS、bcachefs、大型机时代的分层数据库，以及结合 FUSE + SQL 的项目。
- 共识更偏向于“文件系统是数据库的一种专门化形式”，但它们的 API、性能约束和生态预期都大不相同。
FoundationDB 与 Apple 的架构
- Apple 使用 FoundationDB 加上更高层的分层（例如 Record Layer）被认为在技术上很优雅，能够支持数十亿个逻辑数据库。
- 一些实践者表示，在 FoundationDB 上构建事务型、模式驱动系统的体验非常好，但也指出运维上手和扩展都不简单。
- 线程中列出了多个外部采用者（例如分析、监控、云服务提供商、邮件服务器、KV 存储），以及偏好裸机集群的自托管支持者。
iCloud 中的备份与 Time Machine
- 多位评论者希望 Time Machine 能像 iOS 备份一样备份到 iCloud。
- 由于 Apple 的服务战略，这一缺失被认为很奇怪；提到的可能原因包括：存储成本、与现有 iCloud 数据的冗余、家庭上传带宽，以及 macOS 上 API 的复杂性。
- 一些用户通过第三方云存储加上诸如 dotfile 管理器之类的工具来变通；另一些人则更偏好真正的系统级快照。
存储引擎与性能
- 讨论了 FoundationDB 底层的存储栈：早期使用 SQLite b-tree，后来改为 RocksDB，而 Apple 自己的 Redwood 引擎则加入了针对 FDB 的优化，例如前缀压缩。
- 还提到了 SQLite 的实验性 HCTree 引擎，如果成熟，可能带来未来的性能提升。
Notes 与同步工具
- 有些人称赞 Apple Notes 通过 iCloud 处理冲突的能力；也有人报告严重的数据丢失并因此避免使用它。
- Obsidian 获得了强烈推荐，尤其是其工作流和插件生态系统；一些人认为基于 iCloud 的 Obsidian 同步不可靠，而 Obsidian 自家的同步服务则被认为稳定。