> * What sort of JSON "meta-formats" are the most important/common for you? E.g. in a file you could have object-per-line, [...] Yes (also known as jsonlines o

> * What sort of JSON "meta-formats" are the most important/common for you? E.g. in a file you could have object-per-line, [...] Yes (also known as jsonlines or line-separated JSON - .jsonl is the file extension). I think JSON should be thought of as a message format, and messages should be small. Messages can be sent over a stream, without having the "whole" data-set. You also get append-only semantics on files (saving disk-space and virtually creating a stupid write-ahead log become as cheap & hassle-free as it gets), and if you need it you get resumability (say binary search on a file with monotonically increasing ids/timestamps etc). Additionally, this format will work with minimal hickups when interoperating with other systems. YOU may have an advanced, efficient parser, but others may not. Most environments have a line-parser and a json deserializer. Large JSON-files become hard-to-manage and prompts for more and more complex query-like tools. And all of these good properties from such a ridiculously simple tech that it can be explained in a short sentence. Downsides: - Compression at the file level removes resumability (unless your compression is also resumable). - You may have to implement your own log compaction if you have many updates/deletes.