If you have a tiny application, doing a tiny thing, do you need redis? Do you need sqlite? do you need to write some custom-text-file-ma-bob? nah. I feel like simple simple little tools like this are in short supply.
Use redis if you can. Use something like diskhash if you cannot afford the extra overhead of sqlite/redis.
In my case, the alternative we were using before is an in-memory hash table built at startup from a text-based representation of the data. It was pretty good and worked very well up to millions of entries, but at the current scale we work with, it takes least 10 minutes at startup were necessary to build up the thing and it used ~200GB.
They aren't in short supply, just about every shop I've worked at some tool decided to invent something like this instead of just using redis / sqlite.
Yeah but insofar as the article's author's revelation of how fast you can compile C code, maybe the correct answer is to use gperf?
If it's more dynamic than that I mean I guess it's cool to have a hash in a backing store that's dead simple.
But at sizes big enough and with enough dynamism that gperf or something similar isn't appropriate I think you should be considering dbm or SQLite, sort of by definition.
While I kinda agree, I also have found, most of the time, that by the time I finish building something that I thought didn't need a bigger thing...it actually needs a bigger thing, and I have to pull in SQLite or something else to make it all work reliably and fast and for all the data-related features that ended up being needed by the end.
If you have a tiny application, doing a tiny thing, do you need redis? Do you need sqlite? do you need to write some custom-text-file-ma-bob? nah. I feel like simple simple little tools like this are in short supply.