How do we choose between SQL and NoSQL for a new high-traffic application?

All answers to this question.

The "industry standard" is moving toward using the right tool for the specific data type within the same app. This is called Polyglot Persistence. For your user profiles and social graph, a NoSQL or Graph database might be great for flexibility and speed. However, for anything involving transactions or financial data, you absolutely want the ACID compliance of a SQL database like PostgreSQL. Modern Postgres also handles JSONB data incredibly well, which bridges the gap between the two worlds. Don't choose a database based on a trend; choose it based on whether your data is "relational" (needs joins) or "document-based" (self-contained).

   Answered 2025-06-19 by Elizabeth Harris

Have you considered how your team’s expertise plays into this, or are you strictly looking at the technical benchmarks?

   Answered 2025-06-22 by Brian Wright

• Brian brings up a very practical point. A perfectly optimized MongoDB cluster is useless if your team only knows how to write complex SQL queries. The "developer experience" and operational knowledge are just as important as the database's latency. If your team is already experts in Postgres, it can scale a lot further than people think with proper sharding and indexing. Don't underestimate the overhead of learning to manage and backup a new type of database in a production environment under heavy load.

     Commented 2025-06-25 by Michael Turner

If your data schema is still evolving rapidly, NoSQL is a lifesaver. You don't want to be running massive "Alter Table" commands on a live database every week.

   Answered 2025-06-27 by Nancy Allen

• Exactly, Nancy. Schema flexibility is the primary reason startups gravitate toward NoSQL early on. It lets you iterate the product without the database becoming a bottleneck.

     Commented 2025-06-28 by Kevin Parker