---
title: "When a follow graph does not need a graph database"
description: "Model follow and follower edges for high-volume reads, sharding, reverse lookups, and repair using the lessons of FlockDB."
canonical_url: "https://fanout.sh/system/archive/social-graph-follows-and-flockdb"
md_url: "https://fanout.sh/system/archive/social-graph-follows-and-flockdb.md"
access: "public"
---

# When a follow graph does not need a graph database

Model follow and follower edges for high-volume reads, sharding, reverse lookups, and repair using the lessons of FlockDB.

## Public overview

Social Graph Follows And FlockDB

Follow/follower storage looks like a graph problem, but not every graph-shaped problem needs a general graph database.

For Twitter-style follows, the hot operations are shallow adjacency-list reads:

who do I follow? who follows me? does A follow B? page through millions of followers, count followers/following.

Deep traversal is not the main requirement.

Day-Zero Relational Model

Use a generic table name like relations rather than follows if the product is likely to add:

close friends, blocks, mutes, favorites, groups, follow requests.

Generic does not mean vague. It means the table represents a product abstraction broader than one current button.

Why Sharding Breaks The Naive Query

If data is sharded by from user id , this is local:

But this can scatter across every shard:

The destination user could appear in rows whose sources live on many shards.

FlockDB Trick: Store Reverse Edges

For one follow action:

Now both reads are source-local:

---
This representation contains public Fanout content only. Protected Pro lessons, account data, billing, checkout, and pricing are not included.

Browse the public content map: https://fanout.sh/sitemap.md