Do You Even Need a Database? - DB Pro Blog

We built the same HTTP server in Go, Bun, and Rust using two storage strategies: read the file on every request, or load everything into memory. Then we ran real benchmarks. The results are more interesting than you'd expect.

At some point, don't you just end up making a low-quality, poorly-tested reinvention of SQLite by doing this and adding features?

Based on what's in the article, it wouldn't take much to move these files to SQLite or any other database in the future.

Edit: I just submitted a link to Joe Armstrong's Minimum Viable Programs article from 2014. If the response to my comment is about the enterprise and imaginary scaling problems, realize that those situations don't apply to some programming problems.

> Based on what's in the article, it wouldn't take much to move these files to SQLite or any other database in the future.

Why waste time screwing around with ad-hoc file reads, then?

I mean, what exactly are you buying by rolling your own?

You can avoid the overhead of working with the database. If you want to work with json data and prefer the advantages of text files, this solution will be better when you're starting out. I'm not going to argue in favor of a particular solution because that depends on what you're doing. One could turn the question around and ask what's special about SQLite.

If your language supports it, what is the overhead of working with SQLite?

What's special about SQLite is that it already solves most of the things you need for data persistence without adding the same kind of overhead or trade offs as Postgres or other persistence layers, and that it saves you from solving those problems yourself in your json text files...

Like by all means don't use SQLite in every project. I have projects where I just use files on the disk too. But it's kinda inane to pretend it's some kind of burdensome tool that adds so much overhead it's not worth it.

> You can avoid the overhead of working with the database.

What overhead?

SQLite is literally more performant than fread/fwrite.

That's exactly what I was going to say. This seems more like a neat "look Ma, no database!" hobby project than an actual production recommendation.
So you trade the overhead of SQL with the overhead of JSON?

> what's special about SQLite

Battle-tested, extremely performant, easier to use than a homegrown alternative?

By all means, hack around and make your own pseudo-database file system. Sounds like a fun weekend project. It doesn't sound easier or better or less costly than using SQLite in a production app though.