SQL vs NoSQL

Databases

Also known as: relational vs non-relational, polyglot persistence

SQL databases store data in structured tables with predefined schemas and support ACID transactions, while NoSQL databases use flexible data models (document, key-value, column-family, or graph) optimized for specific access patterns and horizontal scaling.

SQL (relational) databases like PostgreSQL, MySQL, and SQL Server enforce a rigid schema with tables, rows, and columns. They excel at complex queries with JOINs, strong consistency guarantees, and transactional integrity (ACID). They are the default choice when data relationships are well-defined.

NoSQL databases trade some of these guarantees for flexibility and scalability. Document stores (MongoDB) handle semi-structured data, key-value stores (Redis, DynamoDB) provide fast lookups by key, column-family stores (Cassandra) optimize for write-heavy workloads, and graph databases (Neo4j) excel at relationship-heavy queries.

In system design interviews, the choice depends on requirements: need complex transactions and strong consistency? SQL. Need flexible schemas, horizontal scaling, or specific access patterns? NoSQL. Many modern systems use both (polyglot persistence) — SQL for transactional data, NoSQL for caching or analytics.

The key is to let your access patterns drive the database choice, not the other way around.

Related Terms

Database IndexingDatabases
Database ShardingDatabases
CAP TheoremReliability
Database ReplicationDatabases

Ready to design?

Practice using sql vs nosql in a real system design on Supaboard's interactive whiteboard.

Browse Challenges