No, seriously, what is with you kids and your databases these days? Modern database systems are fabulously complex and powerful software tools. However, I think a lot of maturing developers see DBs as a hammer, and once they get one in their hands, everything starts looking like a nail -- even if it's actually a banana. Databases have, I think, three main broad categories of features that interest people: the claim of atomicity and durability, the ability to apply relational operators to datasets, and the impression of efficiency over flat files. I'm going to discuss each of these motivations for databases (in reverse order, because I'm that kind of guy), and then put in it context of doing the same thing with a flat file configuration system like YAML (which seems to be the main competitor around here; I'm a fan of JSON, myself, but they're essentially the same). 3. Databases are essentially designed for situations where you have to deal with significantly more data can fit in the RAM of a machine. That's the number one rule behind their development. And if you have data that is several gigs in size, then a database suddenly becomes a hugely awesome tool for helping you get the most out of managing your data without burning your disk drive on seek operations. However, that condition -- if you have data that is several gigs in size -- ought to be heeded! If you DON'T have data that big, bringing a relational database system into the works is using a nuclear bomb to kill a housefly. It's just not necessary. A developer of even a few months of experience in his language of choice should have absolutely no difficulty beating the performance of a database when it comes to configuration data that is only kilobytes or even megabytes in size -- you simply have to remember to cache the data in memory after you've parsed it and not load the whole file again every single time you want to query something. 2. Relational database systems have all of these cool operators like "SELECT" and "WHERE" and "AVE" and "MAX" and "COUNT" and so on and so forth as a direct result of the fact that they're intended for use with massive datasets that can't all fit in RAM. It's utterly trivial to implement all of these operations if your data can fit entirely in RAM! All of the questions that relational operators let you ask of a database can essentially be implemented by nested loops -- and that's just what the databases do on the inside. The reason the databases offer these operators instead of making you do it yourself is because many of them can be implemented more quickly on data that is maintained in a sorted way, and sometimes by only accessing small disk regions instead of reading entire files (i.e. you only have to read the end of a dataset to find the max if you know it's been sorted). But if you can fit all of your data in RAM, why bother using the database as a heavy-weight intermediate between you and your data? Sort it yourself -- it's a one-line call in java, for Christ's sake -- and then this again becomes a situation where even a very mediocre developer can easily beat the performance of a database. The absolute BEST performance a database could offer in a situation like this is by simply loading all of your data into RAM in one go, and thus serving as nothing but an extremely fat middleman between you and a simple read of a single file. 1. The atomicity of operations and the durability on the filesystem that databases offer is, indeed, formidable. But if you can hold all your data in RAM, you can write it all out in one file by yourself too... and while file writes are impossible to make atomic in the presence of machine failures (which IS a valid reason why databases can be valuable)... it IS possible to get yourself cheap atomicity anyway. Write your updated data to a new, temporary file. MOVE the temp file where the old/main file was. That move operation? Atomic. I'm tired of seeing database systems thrown at every little problem. There ARE situations where databases can be indispensably valuable tools, yes, but it is not EVERY situation -- databases come with a cost. One cost in particular is very visible in a community like this one: you're taking control away from your clients, because they are no longer able to use plain text configuration. That's big. That's so big that if you don't immediately understand the seriousness of that issue I'm not even sure how to begin to explain it to you. If you're a young developer just getting your feet wet and starting to flex your creative muscle, it can feel like you're facing a massive series of hurdles before the results you want even come near being in sight... been there often enough and I think that feeling never really goes away for good. But none of your problems are ever solved by using "uber" tools with heaps of buzzwords attached to them like "scalable atomic durable consistent database!" any more than waving of a magic wand, and just because some dude in a big company jismed on a blog once about how cool it is doesn't mean you need to go out and base your life around it from now on. Good solutions to problems come from good thinking, and the first step in good thinking is realizing what your needs really are. Stop hammering my bananas.