Thanks, makes sense! I don't think much of that Dan Luu article applies to read-only files deployed with the application, which is often what configuration fil

Thanks, makes sense! I don't think much of that Dan Luu article applies to read-only files deployed with the application, which is often what configuration files are. Definitely concurrency control is an issue with mutable files, that would all by itself make me hesitant to use them as a storage solution if that were in play. But it's not when the changes to the files are being done outside of the app being deployed, and they are deployed as read-only, any changes require app restart to pickup etc. That is how I have usually experienced configuration and I have personally never run into any problem with having it in the file system. Most of the other stuff in the article also seems to me not to apply to the standard configuration use case. (And if it did... it would apply to your source files too, right? Whether ruby or python or even JVM bytecode. Yet we obviously can and do put those in the filesystem. Ultimately read-only configuration are just another kind of source file they don't really have any special problems). But "incremental remote update" (without requiring app restart especially!) is definitely not the standard configuration use case. I agree that a 'real database' seems reasonable for that use case, whether sqlite3 or something else. Whether you try to control the configuration (that will wind up in a db) in your version control system, or just use standard db backup/clone techniques instead.