What Database Does Facebook (Meta) Use?

Meta runs sharded MySQL as the system of record for the social graph. RocksDB is the storage engine, and a cache layer called TAO sits in front. The social graph is the store of users, posts, comments, and the links between them.

So yes, Facebook uses MySQL. It is not one large MySQL server. It is thousands of small shards, each holding one slice of the data.

No single database serves the whole company. Meta runs different stores for different jobs, and most of them are built in house.

The Main Stores and What They Do

Why MySQL and Not Something Newer

Meta kept MySQL and changed what sits under it. MySQL lets you swap the storage engine, which is the part that writes bytes to disk.

Meta replaced the default engine with MyRocks, which is built on RocksDB. RocksDB is a key value store Meta wrote and released as open source. It uses a log structured design, which writes data in sorted batches instead of updating pages in place.

The reported gain was space. Candidates and public talks describe roughly half the storage of the previous engine for the same data. Less storage means fewer servers.

What TAO Does

A social graph read is small and very frequent. Loading one profile can need hundreds of tiny lookups.

TAO sits between the application and MySQL and answers those lookups from memory. It understands the graph model directly, so it stores objects and the links between them.

Writes go through TAO to MySQL. Reads almost never touch MySQL. In a system design interview, this is the pattern to name: a purpose built cache tier over a sharded relational store.

Two Common Mistakes About Facebook's Databases

The first mistake is saying Cassandra runs Messenger. Cassandra was created at Facebook and open sourced from there, which is why the claim spreads. Messenger did not stay on it. Messenger storage moved to HBase and later onto the RocksDB based stack.

The second mistake is saying HBase holds the social graph. The graph lives in MySQL behind TAO. HBase was used for messages and for time series style operational data, not for the graph.

How the Pieces Fit Together

Think of it as four layers.

• Caches. memcached and TAO answer most reads.
• System of record. Sharded MySQL with MyRocks keeps the durable copy.
• Special purpose stores. ZippyDB for key value data, Haystack and f4 for media files.
• Analytics. Events land in the warehouse, and Presto queries it.

Files are the part people forget. Photos and videos never go in the database. Only the metadata and a storage key do.

Why Interviewers Ask This

The question tests whether you know that scale changes design, not technology choice. A relational database is still correct at this size, once you shard it and cache it properly.

If you get this question, answer in three parts. Name MySQL as the system of record. Name the cache tier. Then say that blobs and analytics live somewhere else entirely.

How to Prepare

• Learn the building blocks. Grokking System Design Fundamentals covers sharding, caching, and replication in plain language.
• Practice the full designs. Grokking the System Design Interview works through news feed and messaging systems that use this exact shape.
• Know the SQL side. See what SQL Meta uses for the query language questions.
• Know the backend around it. What backend Meta uses and which programming languages Meta uses cover the services on top.
• Prepare the product design round. The Meta product architecture interview explains a round that is unique to this company.
• Read the whole loop in one place. The Meta interview guide covers every stage.