Skip to main content

Social Graph Firebase Schema

The social graph stores relationships between users: followers, following, friend requests, mutual friendships, blocked users, and feed visibility. Social apps use this data to build feeds, profiles, search, messaging, and notification surfaces.

Quick Answer​

Social graph data is usually stored by user id with inbound and outbound subcollections. A relationship is confirmed when both sides contain the expected relationship records, or when the app-specific status field marks the connection as accepted. Denormalized user data improves read speed but must be kept in sync when profiles change.

Common Collection Shape​

Common Firestore paths:

social_graph/{userID}/inbound_users/{relatedUserID}
social_graph/{userID}/outbound_users/{relatedUserID}

The exact collection names can vary by product. Search the app source and Firebase rules before changing schema names:

rg "social_graph|inbound_users|outbound_users|friendship|follow" src firebase

Relationship Direction​

PathMeaning
inbound_usersUsers who followed, requested, or connected to the current user.
outbound_usersUsers the current user followed, requested, or connected to.

For mutual friendship or mutual follow, the app can check both directions or a status field, depending on the product.

Example Relationship Document​

{
  id: 'related-user-id',
  firstName: 'Alex',
  lastName: 'Morgan',
  profilePictureURL: 'https://example.com/avatar.jpg',
  type: 'follow',
  status: 'accepted',
  createdAt: timestamp
}

Many apps store denormalized user profile data in relationship documents so followers and friends lists load quickly without extra reads.

Denormalization Tradeoff​

Denormalized user data improves screen performance but creates a maintenance requirement:

  • when a user changes name or profile photo, relationship documents may need updates;
  • backend Functions can perform fan-out updates;
  • stale profile data should not break app navigation;
  • large users may need batched updates and cost controls.

If your app includes Firebase Functions, look for profile update or social graph maintenance logic under the Firebase backend.

Security Rules​

Before production, rules should enforce:

  • users can create only relationships involving their own user id;
  • users cannot modify another user's private relationship data directly;
  • blocked users cannot keep writing social edges;
  • admin or Functions-only cleanup uses server-side privileges;
  • reads are limited to data the app is allowed to expose.

Do not use public read/write rules for social graph collections.

Verification Checklist​

  • Follow/request action writes outbound data for the acting user.
  • Follow/request action writes inbound data for the target user when expected.
  • Accepting a request creates the required mutual relationship state.
  • Unfollow/unfriend removes or updates both directions.
  • Block removes or hides relationship and feed data.
  • Profile changes update denormalized relationship data when required.
  • Firestore indexes exist for relationship queries.

Troubleshooting​

ProblemFix
Followers list is emptyCheck inbound/outbound collection names and Firestore rules.
Mutual friendship is not detectedVerify both relationship directions or status fields are written.
Old avatar appears in followers listCheck denormalized profile update Functions or cleanup scripts.
Relationship write failsCheck Auth state, rules, and required fields.
Social feed shows blocked usersCheck block cleanup and feed filtering logic.