Is NewSQL a real category, or a marketing term?

It's real. NewSQL databases like CockroachDB, Google Spanner, and YugabyteDB provide horizontal scaling across many machines (and even data centers) while still supporting a relational data model, SQL queries, and full ACID transactions — the two properties that "SQL vs NoSQL" framing usually treats as opposed. They achieve this with more sophisticated distributed consensus protocols than traditional single-master relational databases used, at the cost of higher write latency than a simple key-value store.

Can a relational database store schema-flexible data too?

Yes. PostgreSQL's JSONB column type (and similar features in MySQL and SQL Server) lets you store semi-structured, schema-flexible documents inside an otherwise normal relational table, queryable and indexable almost like a native document store. This is a common middle ground: strict schema and transactions for the core data, flexible JSON columns for the parts of the data model that genuinely vary or change shape often.

What does "eventual consistency" actually mean in practice?

It means that after a write succeeds, other replicas of that data are not guaranteed to reflect it immediately — a read routed to a different replica milliseconds later might still return the old value, though it will converge (become consistent) within some short window, typically milliseconds to seconds. This is usually acceptable for data like a social media like count or a product view counter, and usually not acceptable for something like an account balance, which is why the choice of database should track the actual consistency requirement of the data, not a blanket policy.

Does using NoSQL mean giving up joins entirely?

Not necessarily — most NoSQL databases support some form of lookup across collections (MongoDB's $lookup aggregation stage, for example), but it's typically slower and less optimized than a relational database's native join, which is exactly why the recommended NoSQL modeling pattern is to denormalize and embed related data together up front, designed around your application's actual query patterns, rather than normalizing first and joining later the way you would in SQL.

Is document/key-value the only kind of NoSQL database?

No — NoSQL is an umbrella term covering several distinct data models: document stores (MongoDB, Couchbase) for JSON-like nested data, key-value stores (Redis, DynamoDB) for simple fast lookups by key, wide-column stores (Cassandra, HBase) for very high write throughput at massive scale, and graph databases (Neo4j) optimized for traversing relationships. Each has different strengths, so "NoSQL" describes an entire family of tradeoffs relative to relational databases, not one single alternative.

← Software Engineering & Cloud Studio

Concept Explainer · Software Engineering

SQL vs NoSQL

The real choice isn't "which database is faster" — it's where you want structure enforced and where you want consistency guaranteed: at write time, or later.

"SQL vs NoSQL" gets framed as old-vs-new or slow-vs-scalable, but both framings miss the actual tradeoff. A relational (SQL) database makes you define your schema up front, enforces relationships between tables with foreign key constraints, and guarantees that a multi-step write either fully succeeds or fully rolls back (ACID transactions) — all of which cost something at write time and under heavy horizontal scale. A NoSQL database — document, key-value, wide-column, or graph — typically defers schema enforcement to the application, stores related data together instead of normalized across tables, and is designed from the ground up to shard across many machines, usually by relaxing strict consistency to eventual consistency. Neither is a strict upgrade over the other; they optimize for different things, and modern "NewSQL" and multi-model databases increasingly blur the line between them.