The Great Database Schism
Think of a traditional SQL database like a single, highly organized filing cabinet. It keeps everything perfectly ordered and consistent — you can always trust what you read. But when you need to store more, you have to buy a bigger cabinet. You can't just add a second cabinet and have them work as one. NoSQL databases solved this by spreading data across many cabinets, but the trade-off was that the cabinets didn't always agree with each other, and you lost the ability to do complex, multi-step operations atomically.
For decades, engineers faced a binary choice:
- SQL (RDBMS): You get ACID transactions, complex joins, and strong consistency. But, you can't easily scale writes across multiple servers. You are stuck scaling vertically — buying a bigger, more expensive single machine.
- NoSQL: You get massive horizontal scalability and high availability. But, you sacrifice ACID transactions, joins become difficult or impossible, and you often deal with eventual consistency — meaning different clients may read different values for the same key at the same moment.
ACID stands for Atomicity (all-or-nothing operations), Consistency (data always satisfies defined rules), Isolation (concurrent transactions don't interfere), and Durability (committed data survives crashes). These guarantees are non-negotiable for financial systems, inventory management, and any domain where data correctness is critical.
Enter NewSQL
NewSQL is a class of modern database systems that attempts to get the best of both worlds. The goal is to provide the scalability and high availability of NoSQL systems while maintaining the ACID guarantees and familiar SQL interface of a traditional RDBMS.
How do they do it? By rethinking database architecture from the ground up, using distributed consensus algorithms, novel approaches to timekeeping, and separating concerns that traditional databases bundled together. The most prominent examples are Google Spanner, CockroachDB, and TiDB.
The practical implication is significant: instead of choosing between "correct but unscalable" and "scalable but eventually consistent," you can now build systems that are both. A global payments platform can process transactions across continents with the same ACID guarantees a single-server PostgreSQL instance provides — just at orders-of-magnitude greater scale.
Interviewers frequently ask: "Why not just use PostgreSQL with read replicas?" The answer is that read replicas solve read scalability but not write scalability — all writes still go to a single primary. NewSQL databases distribute writes across multiple nodes using consensus protocols, which is fundamentally different. Be ready to explain this distinction clearly.
Key Point: NewSQL databases combine the horizontal scalability of NoSQL with the transactional guarantees and SQL interface of traditional RDBMSs. They achieve this not by bolting features onto existing systems, but by redesigning the storage and replication layers from scratch.