Facebook's answer to serving 700TB of graph search data is lots of SSDs
Facebook's graph search feature requires finding and serving the right data fast, and from a database that currently houses more than a trillion posts and 700 terabytes of data overall.
Context & Ripple Effects
Facebook had already built infrastructure for Graph Search alongside a trillion-edge graph-processing engine based on Hadoop and open source software. Its earlier 100-petabyte Hadoop operation shows the distinction at issue: large-scale data retention and batch processing do not by themselves deliver interactive lookup speeds.
The SSD deployment puts the serving layer at the center of Graph Search’s architecture. It also extends Facebook’s 2013 interest in flash storage for older photos from archival economics to latency-sensitive retrieval.
First-order effects
- Facebook must provision substantial SSD capacity to serve queries against a Graph Search database containing more than one trillion posts and 700TB of data.
- Graph Search users receive results from a storage tier designed for fast retrieval rather than relying solely on Facebook’s broader Hadoop estate.
Second-order effects
- Facebook’s graph-processing and serving systems become more explicitly tiered: Hadoop can manage the large graph corpus while SSDs absorb the interactive lookup workload.
- Facebook’s infrastructure spending shifts toward the data path that determines query latency, making storage-media choice a product-performance decision for Graph Search.
Third-order effects
- If Facebook applies the same pattern across data-heavy features, flash becomes core system infrastructure rather than a niche cache or archival medium.
- Large consumer data platforms are moving toward architectures that separate bulk graph processing from low-latency data serving, with the storage layer shaping what search experiences are practical.
The trend: Interactive search over social-scale data is turning SSD capacity into a defining part of the data-center data path.