Hacker News new | ask | show | jobs
by tyingq 1880 days ago
I'm curious about the name. Putting "DB" in the name sort of suggests it might support persistence, more data than fits in memory, write-through, etc. Is that the case? Or is the "DB" some nod that clustering means that "in-memory" doesn't have to be ephemeral?

Or in short, where is KeyDB headed, longer term?

2 comments

We have our FLASH feature which gives us a baseline persistence story, you don't need RDBs or AOFs anymore. However there's a lot of work left to do in this area.

The long term goal of KeyDB is to let you balance your dataset across memory and disk in one database. In the future I think caches will just be a feature of a more full featured database and that's where we're heading with KeyDB.

I don't think more data than fits in memory is a requirement. An important innovation in databases has been the realization that there are important performance benefits from assuming all data can fit in memory even if you still provide persistence.

Even persistence isn't really required. A pure analytics view of another database is still a database by itself, but it doesn't need to actually persist anything. It seems like querying is more important to the concept of a database rather than actual storage.

I wasn't suggesting they had to, or should happen. Just trying to understand the future plans since the "DB" term is there.