> A key value database stores a data record using one primary key. The key means the record is uniquely identifiable, and can be directly accessed. So, like th

> A key value database stores a data record using one primary key. The key means the record is uniquely identifiable, and can be directly accessed. So, like the primary key in a SQL database? Wouldn't just using a primary key in a SQL database give you much of the same performance if the key-value in question already needs ACID anyway? (I get that pure caching key-value stores are a different beast) > Unlike a relational database, a NoSQL key value database is not obliged to scale vertically. It can scale over several machines or devices by several orders of magnitude So, just like partitioning can do with a SQL database? > I came up with a strategy of having multiple badger databases, each representing a collection. This way, if I ever have a need to scale the system beyond a single server, I could isolate each individual database and it’s corresponding program logic into a separate micro-service. So, that's just a self-built partitioning system, right? > where it is lacking is in search, since you’re only able to query for items by their keys and key’s prefix. But when paired with an indexing engine like blevesearch in golang, or elasicsearch and lucene Doesn't the need for an external search index for even the most basic of queries negate the whole point? If you are going to set this up and push to two different datastores, keep them in sync, manually write microservies just to respond to db-queries and to get partitioning and also get none of the guarantees that a normal DB gives, what is the point? And all of this is before you get into any of the capital-h Hard problems that databases have been dealing with and learnt to solve over decades.