Honestly, I'd agree with that, too, at least in a colloquial sense.

The most popular database where the number of concurrent users = 1

Excel allows you to perform queries for almost arbitrary data on a spreadsheet. I wouldn't doubt for a minute that with sufficient time and motivation you could write a full sql engine with excel functions.

You're using the term "traditional database" two levels up. Whatever your definition of that is, it's their definition of "database".

Your initial post says "I have a different definition of 'database'", which is different than anyone else's, as you acknowledge when you refer to that common definition as a 'traditional database'.

Then, you fault them for making an argument that is invalid for your non-standard definition of a database!

You would like Kafka, the author.

Honestly, where I'd draw the distinction between a database and a datastore is the ability to do multi-statement transactions. So, a filesystem? A datastore. Some support fsync on a single file, but multi-file sync isn't usually supported.

MongoDB and LevelDB both support transactions, so I'd err on calling them databases myself.

I would draw the line at semantic indexing. If the data is only accessible through immediate metadata (filename, sequence number, datetime, etc) then it's just a data_store_. If the engine also maintains indexes derived from the data being stored, then it's a data_base_. In that regard, Kakfa would not be a database since it has no knowledge of what it is storing.