You are relying on disk io for each update, which can easily be slower than a web request. Either that, or you aren't flushing to disk, which could mean data loss. Modern databases use a write-ahead log to store data that hasn't been flushed to disk yet. If you aren't doing that, you don't have a database, you have a cache.

I'm writing to disk on every insert - mainly just for simplicity for this article. Same with semicolon delim string, normally I serialize to/from JSON. Normally, I only flush to disk periodically using setInterval.

I'll try and do a followup post with actual load tests. I load test using loader.io 35k requests total (increasing to 500 clients) in 20 seconds, I go from 50ms response to 200ms but no higher than that. I'd have to do more specific tests.

This is on a tiny $1/mo 128MB ram VPS but with SSD.

Granted this isn't your native-C powerhouse database, but I would bet 95% of websites get less than 10k requests a day and this could easily handle that load.

By this measure Memcached offers a greater feature set, an infinitely more robust parser, request concurrency, and doesn't really on a garbage collector. The very fact that this "db" relies on HTTP requests already makes me cringe.

If database/redis is too heavy and plain json too light then one could use something like Strata [1].

It stores json documents on disk using a b-tree.

[1] http://bigeasy.github.io/strata/

What you have here is a rudimentary persistent cache. "Database" is a bit of a stretch. Could you elaborate on what your production load is?

Dumping the entire database to disk on every write? I can't imagine more than 1 qps.

Hah, nice. But I do not see support for any form of escaping the semicolon, which might happen sooner or later with arbitrary data.

JSON on the wire would clean that up.