SQL or NoSQL to build something like Twitter? It's one of the most common system design questions out there and it's a bit of a trap. Because the honest answer isn't a database. It's knowing where the actual bottleneck lives. For anything Twitter-shaped, the hard part was never the storage engine. It's the home timeline. When someone with millions of followers posts, do you write that tweet into every follower's feed (fan-out on write), or build the feed when they open the app (fan-out on read)? Get that call wrong and no database saves you. So the stack I'd reach for isn't "SQL" or "NoSQL" , it's both, each doing the one job it's good at: → Postgres for the source of truth: users, tweets, follows. ACID, real relationships, one place the data is correct. → Redis for the timeline - precomputed feeds, fast fan-out. → Elasticsearch for search. → Wide-column stores (Cassandra and friends) only when write volume genuinely demands it. Start with Postgres. Reach for NoSQL only where it earns its place. Most systems never outgrow that. The ones that do, outgrow it in one specific place at a time , not all at once. What's your default answer to this one? #systemdesign #backend #softwareengineering #databases