The definition is a bit confusing - basically I'm asking if SQL is a subset of the NoSQl family:


I'm asking this because "Not-only" means NoSQL is much larger, but still includes SQL as a part of it.

On the other hand, since we can't do typical sql operations like joins in a NoSQL database, then SQL is not part of nosql!

I'm wondering which holds true?

  • 8
    Since SQL99, SQL also handles non-relational concepts. Today there are arrays, XML, JSON among other things, and rumors say that SQL20xy will contain graph. – Lennart Mar 20 at 14:05
  • 3
    To the point of everything else said so far, it's just buzz words. "Not Only" doesn't have to be inclusive of everything in the "Only" portion of the phrase if you want to hold the phrase accountable. Rather because NoSQL is inclusive of some things that SQL is and is also some things in addition to SQL, your venn diagram should overlap only partly, with SQL having a section to just itself, same for NoSQL. And if you really wanted to push the definitions, than just as Lennart mentioned, SQL actually can do everything NoSQL can now and could be argued to be the superset not subset here. – J.D. Mar 20 at 15:24
  • 17
    NoSQL means exactly what it says. No SQL. Zero SQL. Do not pass SQL, do not collect $200. They just retconned it after they realized SQL was actually useful. – user253751 Mar 22 at 10:43
  • 2
    (the SQL is just pining for the fjoins) – user253751 Mar 22 at 18:04


The main distinction between database systems is not the language used to query the database, but rather the consistency model of the system. The Venn diagram should be two intersecting sets - SQL is not a proper subset of NoSQL, but rather its own data access language which may or may not be complemented by other techniques. SQL would be a proper subset of database query languages.

There is NoSQL, OldSQL and NewSQL.

NoSQL used to mean "Not SQL" but now is (more) likely to mean "Not only SQL" - as many of the providers of NoSQL systems are (trying to) bolt-on/graft SQL interfaces over their Key-Value (KV), Document or Graph stores.

OldSQL systems are essentially the main RDBMS providers' offerings (Oracle, SQL Server, Sybase, PostgreSQL, MySQL...). On page 13 of this presentation (.pdf), Michael Stonebraker purports to show that OldSQL only spends 4% of the time doing "useful" work - also to be found here:

enter image description here

His contention is that one should split OLTP work and OLAP work between different systems - OLTP should be done by shared nothing sharded architectures such as, suprise, surprise, his own system, VoltDB and that OLAP should be done by columnar store (also, see here) type architectures (such as Vertica, in which he also had a role). It is worth noting that Stonebraker, as well as being very successful in the commercial arena is also huge in academia and has won a Turing award - Computer Science's "Nobel prize"!

NewSQL is (IMHO) the most interesting of the systems to spring (figuratively speaking) like the Phoenix reborn from the ashes of OldSQL. Their USP is that they are HTAP systems (Hybid Transactional and Analytical Processing).

These are distributed systems which can support both OLAP and OLTP queries simultaneously due to the data being spread over several nodes - which can be on or in the same rack, data centre or continent and/or be globally distributed between and amongst cloud providers to increase resilience and redundancy - expect to add ~ a '0' to the cost for every fractional '9' you add to your uptime provision.

They use a consensus algorithm (usually Raft or Paxos) to coordinate nodes' data and sharding is transparent - even to the systems' DBA's. The three exemplars of such systems would be CockroachDB, TiDB and YugaByte.

It is interesting to note that, while having a certain level of success, these systems are not (yet?) household names. The "big boys" are fighting back with columnar store and KV offerings bolted/grafted on to their own systems. Of particular interest in this debate is that these systems themselves sit "on top" of a KV store (usually RocksDB - although CockroachDB is developing their own one in Go called Pebble). PostgreSQL also has documents (JSONB) and a KV store.

To answer the question, the real distinguishing feature between systems is not the interface one uses to query the data (which can and does range from direct C language programming (imperative) to SQL (declarative) - and flavours/adaptations thereof), but rather the transaction consistency model.

These models are either ACID (consistent) vs. BASE (available) and the key is where these systems fit with respect to the CAP theorem. Also, KV stores can support some or all ACID transaction characteristics.

OldSQL and NewSQL value consistency above all else ('CP' under the CAP system) - their argument is that, for example, a banking system with inconsistent results is a recipe for disaster (true!).

However the NoSQL aficionados would suggest that not all systems require cast-iron consistency. For example, ordering a book from Amazon (say) using a BASE database ('AP' in CAP terms) - might (incorrect stock level shown) be a few days late, or even cancelled - but the upside is faster queries and easier operation (no consensus to maintain).

This is the crux of the distinction between database systems - 'CP' or 'AP'! CP will always either give you the correct answer (majority of nodes still available) or no answer, whereas AP systems will normally respond (even if only one node is up) but your answer may not have taken other nodes' data updates into account when responding (i.e. network links between them down...).

I hope this is a satisfactory "first-pass" at an answer - it's a large topic and, for db nerds, absolutely fascinating. I would urge you to read around it (Wiki is a good start, but no substitute for primary sources). In particular, I would advise you to look in detail at the underlying architectures of CockroachDB and TiDB and see how they shard and move data from node to node while maintaining consistency.

There are comprehensive lists of various NoSQL systems here and here (best IMHO). There's also a popularity ratings site here (but avoid the comparisons - they just repeat the blurb from the systems' websites - often out-of-date).

Final word, there are "mixed-model" (or multi-model) databases (ArangoDB and OrientDB - both have F/LOSS and Enterprise versions - OrientDB now part of SAP), but there's a reason why they're not household names. ArangoDB doesn't support ANSI SQL, but rather its own flavour - AQL and neither does OrientDB support ISO SQL.

The best multi-model db that I've worked with is PostgreSQL which has KV and document stores as mentioned above. You can use SQL to query these and join with "ordinary" tables. Work is ongoing to add OpenCypher - an open graphical query language standard - to it (see here and here).

Final, final word: PostgreSQL also has a Columnar Store extension and a Time Series extension - both of which are very important (sub)-classes of database system. Both extensions are just that, extensions and not forks - you can use "normal" SQL (i.e. the full range of PostgreSQL's very standards compatible SQL) with these extensions.

So, we can see that while NoSQL is, in some cases, but not all (many systems designers are happy to remain as simple KV stores for example), adding SQL capabilities, SQL is fighting back, adopting and adapting to new and/or more sophisticated data storage and retrieval requirements - some of which I haven't even touched on (GIS systems...). So to say that NoSQL fully encompasses SQL would be an incomplete picture...

As pointed out in comments to the question itself, the SQL standard now tackles non-relational paradigms and this will only increase into the future! Also addressed by other answers - worth reading (1 & 2)!

  • 1
    Here's a good article - I seem to recall from the dark recesses of my brain, that other systems [have used/are using] PostgreSQL's query parsing engine using Go's FFI (foreign function interface) and I'm fairly sure that CockroachDB has PG code in it - so they're learning the lessons without paying the price, so to speak! :-) – Vérace Mar 20 at 15:30
  • 18
    Please do not use code markup for emphasis, it messes up all kinds of stuff, from web crawlers to screen readers to other reading aids. – Polygnome Mar 20 at 17:15
  • 6
    @Vérace I don't need to explicitly tag you. Its your answer, you get notified either way. I only redundantly tag the author of the question/answer when I'm actually answering a comment, like now, to indicate that my comment isn't related to the answer but another comment. – Polygnome Mar 20 at 17:50
  • 2
    @Vérace I would agree... the Star Star Tick that you do seems out of place... I've never seen it used and it just looks... weird. You could use Star Star for bold... or Star Star Star for bold italic Like This (I think) (or... underscore in place of stars, apparently - meta.stackexchange.com/questions/167266/… )... in either place, the grey box around the words is not normal. (and it's compounded by you using bold elsewhere without the "extra" emphasis of grey box) – WernerCD Mar 20 at 18:12
  • 3
    @Vérace You got italics and bold for emphasis, or both. You can add capitalization if needed, but I'd only use that sparingly. Network consensus is not to use code markup for emphasis because of the reasons I listed before (see for example this Meta QA: meta.stackexchange.com/questions/135112/…). – Polygnome Mar 20 at 18:25

NoSQL was, is, and always will be a vague buzzword, not a well-defined term.

Its origin is related to a historical trend: at the beginning of this century, if you said "database", the assumption would be that you were talking about an SQL-based relational database, and "choosing a database" just meant choosing which implementation of that technology you were using. As part of the "Web 2.0" and "cloud" technology movements, people began to challenge this assumption, and work with completely different database systems - systems that, unusually for the time, featured "no SQL". Wikipedia suggests the first use of "NoSQL" to refer to these was 2009.

The term initially referred mostly to document-based and key-value databases, because that is what a lot of people were working on at the time; it was a useful catch-all in a rapidly evolving field. As more ideas were explored, the term became more confusing than useful - some of the databases it covers have nothing in common other than not being SQL-relational. Worse, some non-relational databases started adding SQL or SQL-like querying languages; and some relational databases started adding features that let you use them in hybrid non-relational ways.

Retro-fitting the "no" to mean "not only" is a cute way to make the term make sense again, but the better idea is probably just not to use it. Its only value is as a reminder that "database" does not have to mean "relational SQL-based database"; using other terms like "data store" can serve that same purpose without centring everything on the mostly-irrelevant question of how things relate to SQL.


SQL is a language. NoSQL is an approach to choosing database systems. It makes no sense to compare them.

The origin of "Not Only SQL" lies in the fact that not too long ago, when you had some data to store, the only question was "Oracle or Microsoft?" Nobody ever thought about whether or not a SQL RDBMS would actually be the best solution for storing that data. Using something other than Oracle or SQL Server was simply unthinkable.

The idea behind "Not Only SQL" is exactly what it says: when you choose how to store your data, you consider not only SQL but also other possibilities. The idea is that you analyze your data and choose the storage solution that best fits the data. If your data is object-shaped, you use an object store, if your data is document-shaped, you use a document store, if your data is XML-shaped, you use an XML store, if your data is a graph, you use a graph database, if your data is tree-shaped, you use a tree database, if your data looks like a flat key-value structure, you use a key-value store, if you want to store time series data, you use a time series database, … and if your data is rectangular table-shaped relational data, then by all means use an RDBMS.

Even if your data is relational, SQL is still not the only choice. There are non-SQL relational databases, hyper-relational databases, post-SQL relational databases (e.g. Rel), there are things like NF², and so on. All of those are relational, but none of those are SQL.

There is a myth that NoSQL databases don't support consistency, or don't support transactions. That is wrong. First off, there is no such thing as a "NoSQL database". NoSQL is not a database technology, it is an approach to choosing a database. But even if we look at the databases that are typically called "NoSQL databases", we see that there are actually different ones with many different approaches towards consistency and transactions. E.g. Datomic offers SQL-like ACID guarantees and transactions. There are some that offer even higher guarantees than SQL does. And there are ones that offer relaxed guarantees compared to SQL.

Some offer flexible, configurable guarantees, that allow you to pick and choose between performance and guarantees along various dimensions. Sometimes even different choices for different data.

So, really the idea behind NoSQL is simply that you analyze your requirements and choose the solution that best fits your requirements. That's all there is to it.

And really, that's so far only talking about how data is stored. How the data is queried is really another question altogether. It is perfectly possible to query many "non-SQL" databases with SQL. The performance characteristics may be different, but the functionality won't be. Likewise, you can query "traditional SQL" databases with languages other than SQL. In fact, in many modern systems, there is actually not a lot of SQL. They may be using LINQ, for example, or an ORM. Ruby, Python, Perl, ECMAScript, many other programming languages have internal and external DSLs for database queries, e.g. ARel in Ruby.

  • 7
    Wikipedia starts its article on NoSQL by talking about "A NoSQL database", as does pretty much every hit when I search for NoSQL. It's simply not true that "NoSQL is an approach to choosing database systems." at least in the normal use of the word NoSQL. – prosfilaes Mar 21 at 10:59
  • 4
    According to Martin Fowler's excellent introduction to NoSQL the term "NoSQL" started out as just a throwaway "hashtag" for a meeting, which people have tried to explain and rationalize afterward. I agree with your main point that it makes no sense to compare SQL, a language, with NoSQL, a kind of philosophical movement about databases. – workerjoe Mar 21 at 15:21
  • @workerjoe - I think the term Polyglot Persistence would be better as a generic (catch-all) term for non-SQL approaches - and/or even those which [have come | are coming | will come] late to the SQL party - i.e. sticking SQL interfaces on top of systems which were originally not SQL. Systems which started out as SQL dbs (i.e. RDBMSes) and have added other capabilities, could be terms SQL++ or similar? – Vérace Mar 22 at 18:30
  • @Vérace Interesting term, but that Wikipedia article could do with a serious rewrite; in particular the bulleted list "Relational; NoSQL; Graph; In-memory" is just nonsensical! – IMSoP Mar 23 at 13:54


NoSQL, imho, is a misnomer.

NoSQL is a schema-on-read data repository. The opposite is RDBMS, which is schema first. RDBMS puts the onus on the designer to come up with an efficient data structure and reduces the burden on the analyst, who has a defined schema and constraints to ensure data integrity. NoSQL, on the other hand, requires minimal design upfront. It puts the burden on the data analyst, who must deal with the data structure's flexibility by imposing their own structure and checks on the data.

SQL itself is a language. SQL can be used to query NoSQL repositories just as it is used to query RDBMS.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.