Apple built iCloud to store billions of databases

Original Article ↗ Hacker News Discussion ↗

Apple’s use of FoundationDB to power iCloud at the scale of billions of logical databases prompts comparisons between databases and filesystems, and highlights how modern storage architectures blur that boundary. Commenters contrast this elegant backend with iCloud’s often unreliable user-facing behavior, citing years-long issues syncing photos, files, and messages and the lack of cloud-based Time Machine backups. The thread also touches on who else runs FoundationDB in production, how large-scale schema migrations are handled, and why alternative tools like Obsidian or CouchDB succeed or struggle with sync and consistency.

iCloud reliability and user experience

  • Multiple comments report poor reliability: photos and files stuck syncing for days, inconsistent photo counts across devices, and opaque progress/state.
  • Some users fixed issues by deleting local iCloud data or using Apple’s troubleshooting tools, but others say those didn’t help or required hours of waiting.
  • iMessage/“Messages in iCloud” is described as flaky: read/unread and deletion status often fail to sync consistently across macOS and iOS.
  • Users find it hard to control which items are stored locally vs offloaded, especially on iPhone, leading to frequent re-downloads and unusable offline behavior.
  • Some have abandoned iCloud for file sync entirely, frustrated that “Optimize storage” behavior is pushed even onto third‑party sync tools via Apple’s FileProvider API.

Database vs filesystem discussions

  • Several comments argue that at a high abstraction level, filesystems and databases are similar: both map keys/paths to blobs/records and can be layered on top of each other.
  • Others emphasize important practical differences: querying capability, transactions/ACID semantics, performance sensitivity, and “mechanical sympathy” for disks.
  • Historical and experimental systems are cited: WinFS, ReiserFS, BeOS’s BeFS, Oracle DBFS, bcachefs, mainframe-era hierarchical databases, and projects using FUSE + SQL.
  • Consensus leans toward “a filesystem is a specialized form of database,” but with very different APIs, performance constraints, and ecosystem expectations.

FoundationDB and Apple’s architecture

  • Apple’s use of FoundationDB plus higher-level layers (e.g., Record Layer) is praised as technically elegant for supporting billions of logical databases.
  • Some practitioners report excellent experiences building transactional, schema-driven systems on FoundationDB, noting that operational on-ramp and scaling are nontrivial.
  • Thread lists several external adopters (e.g., analytics, monitoring, cloud providers, email servers, KV stores), plus self‑hosting advocates who prefer bare-metal clusters.

Backups and Time Machine in iCloud

  • Multiple commenters wish Time Machine could back up to iCloud, mirroring iOS backups.
  • The absence is seen as puzzling given Apple’s services strategy; possible reasons mentioned: storage cost, redundancy with existing iCloud data, home upload bandwidth, and API complexity on macOS.
  • Some users work around this with third‑party cloud storage plus tools like dotfile managers; others prefer true system-level snapshots.

Storage engines and performance

  • FoundationDB’s underlying storage stack is discussed: earlier SQLite b-trees, later RocksDB, and Apple’s own Redwood engine with FDB-specific optimizations like prefix compression.
  • SQLite’s experimental HCTree engine is mentioned as a potential future performance win if it matures.

Notes and sync tools

  • Apple Notes via iCloud is praised by some for conflict handling; others report serious data loss and avoid it.
  • Obsidian gets strong endorsements for its workflow and plugin ecosystem; iCloud-based sync for Obsidian is described as unreliable by some, while Obsidian’s own sync service is reported as stable.