No - a single table relational database is more akin to a spreadsheet than a NoSQL database. NoSQL is not about having no schema, it's more about having a flexible schema!
Wikipedia puts it very well when it says NoSQL:
provides a mechanism for storage and retrieval of data that is modeled
in means other than the tabular relations used in relational
The key (pardon the pun) word here is
modeled - i.e. there is a model, it's just not a relational one!
As an aside, it's well worth reading the entire article - it's detailed and well written!
It's important to emphasize that the "No" in "NoSQL" is an
abbreviation for "not only" and not the actual word "No." This
distinction is important not only because many NoSQL databases support
SQL like queries, but because in a world of microservices and polyglot
persistence, NoSQL and relational databases are now commonly used
together in a single application.
And indeed many NoSQL systems (it's difficult to say "vendors" since many of these systems are Open Source) are scrambling (or have scrambled) to put SQL interfaces on top of their systems because so many programmers are familiar with that paradigm (and it's one which has worked well over the years).
One could write entire essays (as indeed I have in College) on NoSQL vs. the classic RDBMS, and I'll go no further down this avenue other than to urge you to read around the topic.
It's fascinating to watch the evolution of the database ecosphere - new SSD chip technology, and for me, the most interesting development is the recent focus on LSM (
Log Structured Merge tree) which is widely used in NoSQL systems and also
NewSQL ones. IMHO, these NewSQL systems are the way of the future and I expect to see Oracle, SQL Server &c. to adopt many of their paradigms (or
embrace and extend them to coin a phrase).
Again, it's a complex technology about which reams could be written, but from
At the heart of the LSM algorithm is a rolling merge process:.... LSM trees cascade data over time from smaller, higher performing (but more expensive) stores to larger less performant (and less expensive) stores.
Instead of updating in place, data is "chunked" and from
Once the in-memory tree reaches a threshold size, a new in-memory tree
is created and the old tree synced to disk. Once written to disk,
trees are read-only, though they are merged in the background with
other on-disk trees to reduce the cost of reads.
You mention SQLite in your question - it may surprise you to learn (it did me) that there is a
Key-Value "version" of SQLite that was developed between 2012 and 2014. From
Lessons learned from SQLite4 have been folded into SQLite3 which
continues to be actively maintained and developed. This repository
exists as an historical record. There are no plans at this time to
resume development of SQLite4.
I'll leave the last word to
Brian Aker, former Director of Architecture for MySQL who presents his amusing take on NoSQL which is available on YouTube
here. I think his views can be best summed up by a cartoon which he presented during that talk:
+1 for an interesting question (which I hope won't be closed!) and welcome to the forum!