Is a single-table relational database similar to a simple NoSQL database?

One advantage touted for NoSQL databases is the lack of a schema. In the case of a single-table relational database, there are no relationships between multiple tables, and new columns can be easily added to the single table. It seems like it is just as good as a NoSQL database, since there is no need to design a schema. So, is a single-table relational database similar to a simple NoSQL database?

Are there good reasons to use NoSQL databases if single-table relational databases are good enough, given that relational databases like SQLite are better tested and likely more stable?

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
databases.

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!

IBM says:


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 here:


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 here:


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 here:


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!

StackExchange Database Administrators Q#266727, answer score: 15