> But even using SQLite can be significant over-engineering. Running migrations? Writing SQL? That's too much effort for me. Key-value stores are not a replace

> But even using SQLite can be significant over-engineering. Running migrations? Writing SQL? That's too much effort for me. Key-value stores are not a replacement for SQL, they solve a simpler problem. If you actually can do with a key value store I would argue a SQL table with two columns key and value with key being a primary key will do just fine. And using it needs simple select and 'insert on duplicate key update' statements. The effort for migrations won't be higher than whatever you had to configure for your key-value store. However, if you can't actually do with a key-value store you will end up writing a lot of the features SQL provides in application code. Indices, joins, grouping, ordering, etc. You might not notice it at first, but you will blow up complexity in your business logic reinventing existing SQL features and chances are high you're doing it worse and less performant than what e.g. Postresql offers out of the box. SQL is just such a powerful tool that is at the same time incredibly easy to use for simple scenarios. Added benefit of using SQLite, you can migrate to a more powerful SQL database later without having to reengineer your whole data layer.