[manmal]

Why is such a JSON file too big to use if it’s only ever handled by streaming parsers? SQLite would be a better backup format ofc.

[vbezhenar]

AFAIK SQLite field limit is 2 GB, so if you're used to storing Blurays in your password database, that might be a limiting factor as well.

[weaksauce]

the maximum file size is smaller than 500MB so that's a moot point and not many people are going to be hitting that size limit in the first place... it is a password manager after all.

[mdaniel]

Can you explain how sqlite is a better container for arbitrary binary files than zip?

I mean, I know "INSERT INTO files ('my-file.bin', X'CAFEBABE...')" gets it into sqlite, but how would a sane person get that content back out?

[onetom]

Well, you can just get BLOBs out of an SQLite DB with SELECT. Also: https://www.sqlite.org/fasterthanfs.html

Not that performance or file size would matter in this case, BUT what using SQLite would allow is to use a single format for persisting all aspects of the password database, with immediate, programmatic, random access to all fields, including attachments.

But I also agree, that for this specific use-case, even SQLite is a bit of an overkill probably.

Finally, there is always https://www.passwordstore.org/ :)

[mdaniel]

Right, but I feel we're having a miscommunication about the level of effort one should expend to recover the payloads; your mental model is that this:

    sqlite3 -noheader -newline '' export.db "select data from files where filename = 'my-file.bin'" > my-file.bin

is more user friendly than:

    unzip 1PasswordExport-ILESALYKVFDNJH3K24FEO3QRHM-20220611-100457.1pux files/my-file.bin

[manmal]

This discussion is about Base64-in-JSON vs SQLite, not binaries-in-ZIP vs SQLite.