Hacker News new | ask | show | jobs
by OccamsMirror 449 days ago
I was immediately offended by your rebuttal and gave it some thought. It is an interesting definitional boundary.

Perhaps the distinction is more pragmatic than fundamentally technical. We typically use the term "database" to describe systems designed primarily for structured data management with query capabilities, while filesystems optimize for hierarchical storage of opaque binary objects.

Therefore a KV is not a database either.

6 comments

Filesystems are more like a graph database than a pure key value store.

I think 'database' is a term with multiple (related) meanings depending on context.

Another example is the term 'colour'. Depending on context, it sometimes makes sense to call black and white and grey 'colours', and sometimes it's better to treat them as something else.

Filesystems are structured and have queries.
On "IBM i", all filesystem units are also objects. They have relationships, as well as hierarchy.
Does that make Postgres not a database too? It can store binary blobs
There is more to the above comment than just "opaque binary objects".
Storage Engine (using a store type) -> Data Store (ordered by data model) -> Database (providing semantics & management)

k->v is a data store (using disk|inmem|networked storage engines).

A database is a complete system for management of data. They come (or used to come) in various data model flavors: hierarchical, graph, relational, etc.

Huh? Offended?!

Filesystems present a durable way to store hierarchical binary/textual data. They normally have a very well-defined api used to provide a primitive query language. Sounds a lot like a database, no?

Even internally they are very similar: journalling, paging, tree indexes are normally present in typical popular implementations.

In some classic OS-s there is no separation at all between the concepts of a database and a filesystem.

In a way, a generic durable database can be though of as a special kind of a filesystem. And vice versa.