Simulating 'Moltbook' at Scale: A Hybrid Experiment with Firebase Data Connect

#Architecture#PostgreSQL#Firebase#Scaling#Simulation

--- postId: iflLZaMTI99QL6JjdDtZ --- Simulating 'Moltbook' at Scale: A Hybrid Experiment with Firebase Data Connect As CareerVivid grows towards millions of po

--- postId: iflLZaMTI99QL6JjdDtZ --- Simulating 'Moltbook' at Scale: A Hybrid Experiment with Firebase Data Connect As CareerVivid grows towards millions of posts and hundreds of thousands of active users, we reached a critical architectural crossroad. Our initial pure NoSQL approach, while excellent for productivity tools like resume drafting, faced significant challenges in supporting a high-scale, relational social engine. Today, we are unveiling our answer: a Hybrid Architecture that seamlessly blends the real-time flexibility of Cloud Firestore with the relational power of PostgreSQL via Firebase Data Connect. 🏗️ The High-Level Design Our system now follows a clear functional split: - Cloud Firestore: Continues to power user profiles, workspace configurations, and offline-first resume drafts. - Firebase Data Connect (Postgres): Powers the social graph (Follows, Likes, Shares) and the global/personalized feeds. 💎 The Relational Data Schema By moving social data into PostgreSQL, we've gained the ability to perform complex relational joins in a single, high-performance query. Below is the exact schema currently powering our community: Core Social Tables - Users: Mirrored data from Firebase Auth with real-time social stats (follower counts, post counts). - Posts: Relational content storage with built-in UUID generation and Markdown support. - Follows: A highly optimized join table implementing the social graph with foreign key integrity. - Interactions: Atomic tracking for Likes and Comments. 🚀 Performance & Scale Strategies 1. Solving the "Celebrity" Fan-out Problem Traditional NoSQL social networks often "push" new posts into the feeds of all followers. For users with 100k+ followers, this is incredibly expensive. Our new architecture uses a Pull Model (Join-based). By utilizing PostgreSQL's efficient B-tree indexing on the Follow table, we can aggregate a personalized feed in sub-20ms without redundant data duplication. 2. Partial Indexing for Active C