I think using flat file human-readable serialization for relational data is the real kludge, but I guess that&#x27;s just me.<p>But unknown numbers of captures indicates a non-regular grammar. You should simplify the grammar so you don&#x27;t need them. I&#x27;d have each line adhere to &#x2F;^(\w+) (.*)$&#x2F;, and use the first capture to determine which regex you use to read the rest of the line. But this will break if there are newlines in the input. Hopefully it will error out if it gets a bad line, and even if it does, it will pass bad data in that case.<p>&gt; Come on, what can you mess up splitting lines into fields?<p>Really depends on how clean your inputs are. A short list of things that can mess you up: newlines in your data, encoding inconsistencies, delimiters in your data. You have to handle all these manually if you write your own parser or risk unclean data entering the boundaries of your system. If you&#x27;re in full control of your input, sure, go nuts, but I&#x27;d prefer a more robust solution because you never know what you&#x27;re going to want to feed into it in the future.<p>A standard format may have inconsistencies in implementation, but the format itself bakes in the solution to these problems, and also tends to have somewhat-useful error messages when they break.<p>&gt; Yeah, sqlite3 is a popular option. But it&#x27;s more an alternative answer to the question of in-memory storage. It&#x27;s not particularly suited as a human-friendly data interchange format.<p>My suggestion would be to treat these as separate problems and not expect one solution to provide both of them. Why do you need human-friendliness? To me, the usual way to provide that is with an application and not a data format. I could knock one of those up pretty quickly with Rails and an admin backend, I&#x27;m sure you&#x27;d have your own way of doing that that you&#x27;re comfortable with. I will use command-line applications if Rails is too heavyweight, I do this for a lot of my utility apps.