Same as .zip, .xml, .json and many others.

Doesn't mean that whatever the app stores inside will remain backward compatible which is the harder problem to solve.

I worked @fzakaria on developing that idea. It actually worked surprisingly well. The benefits are mostly in the ability to analyze the binary afterward though rather than any measurable benefit in load time or anything like that though. I don’t have the repo for the musl-based loader handy, but here’s the one for the virtual table plugin for SQLite to read from raw ELF files: https://github.com/fzakaria/sqlelf

wonder if this would make hot-swap functions easier, if every function had its own section and every section was in the db

Forget elf, imagine having a SQLite file that stores elf, exe and DMG binaries. I would not mind working on something like this.

Or a replacement for Access

I've been pondering something similar as a modern approach to fat binaries, basically around a table like

    CREATE TABLE functions (name TEXT, arch TEXT, body BLOB);

The advantage would be that binaries could be partially fattened, i.e. every function would have at least one implementation in some cross-platform bytecode (like WASM), and then some functions would get compiled to machine code as necessary, and then the really-performance-dependent functions would have extra rows for different combinations of CPU extensions or compiler optimization levels or whatever — and you could store all of these in the same executable instead of having a bunch of executables for each target.

As a bonus, it'd be possible to embed functions' source code into the executable directly this way, whether for development purposes (kinda like how things are sometimes done in the old-school Smalltalk and Lisp worlds) or for debugging purposes (e.g. when printing stack traces).

Because Windows can view and extract them out of the box without installing any additional applications. If it supported anything better out of the box I'd guess people would use that instead.

It works well enough. What could, for instance, epubs gain by having another base format instead?

I think most format use "gzip" instead of "zip".

- archiver format to stow multiple files in one; your actual files (in your choice of format(s)) go inside

- files can be individually extracted, in any order, from the archive

- thousands of implementations available, in every language and every architecture. no more than 32KiB RAM needed for decompression

- absolutely no possibility of patent challenges

If all you need is a bag of named blobs and you just want quick reasonable compression supported across all platforms, why not?

If you don't need any table/relational data and are always happy to rewrite the entire file on every save, ZIP is a perfectly fine choice.

It's easier than e.g. a SQLite file with a bunch of individually gzipped blobs.

ZIP isn’t an application format, it’s a container, no? You store files with any format in a .zip, and that’s what applications do - they read files with other formats out of the .zip. What are your goals; what else would you pick, and why? What are the questionable choices you refer to?

AMD/Xilinx Vivado uses ZIP format to compress design checkpoints. They just give them a .dcp extension though.

It does, here's a schema from an image I just saved with the latest version. Pretty simple.

  CREATE TABLE image_attributes ( name text, value blob);
  CREATE TABLE layers (id text, parent_id text, sequence integer, uti text, name text, data blob);
  CREATE TABLE layer_attributes ( id text, name text, value blob);

Also, document-based apps that use Apple's Core Data framework (kinda ORM) usually use SQLite files for storage.

Messages uses it too on Mac; was using it to do some convoluted text search on my history

The only "downside" is that the format is an open spec, which allows anyone to modify the contents without going through the specific application. And it's only a downside if you are using the format as an obfuscation to prevent third-party compatibility/reverse engineering, or to lock in customers.

I think the developers had the same idea https://fossil-scm.org/

It can be compressed, see https://sqlite.org/sqlar.html

Sure. But if you have reasonably small files just compress the whole file, like MS Office or EPUB files do.

Or if your files are large and composed of lots of blobs, then compress those blobs individually.

Whereas if your files are large and truly database-y made of tabular data like integers and floats and small strings, then compression isn't really very viable. You usually want speed of lookup, which isn't generally compatible with compression.

You do know, that you can create more than one table in SQLite and have references from one to another? Even recursive references work

I had some json data that I wanted an annotation interface for. So I asked codex to put it into sqlite and make a little annotation webserver. It worked quickly/easily and without hassle. Sqlite supports queries over json-like objects.

Maybe a very simple document oriented db would have been better?

My biggest gripe is that the sqlite cli is brutally minimal (makes sense given design), but I probably should have been using a nicer cli.

Maybe not as obvious for those without formal education in """database normalization""" but it's pretty trivial to convert from a tree structure to a flat table structure using foreign key relations. Recursive queries aren't even that difficult in SQLite, so self-referential data can be represented cleanly too, if not a bit more difficult to write. IME most applications "tree structures" aren't self-referential and are better formalized as distinct entities with one-to-one relationships (ie. a subtree gets a table).

There's always the lazy approach of storing JSON blobs in TEXT fields, but I personally shy away from that because you lose out on a huge part of the benefits of using a SQL DB in the first place, most importantly migrations and querying/indexing.

I am not really classically trained on the subject but I think this is the idea behind relational storage, it is to have better extraction options, you don't have to treat your data as a single document at a time.

Naively, most data looks hierarchical and the instinctive reaction is to make your file format match. But if you think of this as a set of documents stacked on top of each other if you take the data as a bunch of 90 degree slices down through the stack now your data is relational, you loose the nice native hierarchical format, but you gain all sorts of interesting analysis and extraction options.

It is too bad relational data types tend to be so poorly represented in our programming languages, generally everything has to be mapped back to a hierarchical type.

absolutely adore the mbtiles format! thank you for creating that.

Also, tested .zip vs .tar vs sqlite vs file system. Of this bunch, sqlite was the most compact format with minimal overhead.

Is there a software solution to mounting any DB as a filesystem?

There's FUSE-using Sqlitefs & WebDAV-using Wddbfs.

Why would you want to do that?

Planning on putting a license on it? I habitually ignore repos without a LICENSE file in them.

Recently reverse engineered the Money Pro backup format, it's a binary file with SQLite with some additional XML information backed in. It feels like they're purposefully making it harder for users to export their data in a useful format, especially after the changes they made to their financial model.

Yes! Gus (the developer) also has made & maintained FMDB for many years, a nice Cocoa wrapper for the SQLite bindings.

https://github.com/ccgus/fmdb