[anonymouzz]

Yup, see no reason why not. This is answered in the post:

> Any application state that can be recorded in a pile-of-files can also be recorded in an SQLite database with a simple key/value schema like this:

   CREATE TABLE files(filename TEXT PRIMARY KEY, content BLOB);

> If the content is compressed, then such an SQLite Archive database is the same size (±1%) as an equivalent ZIP archive, and it has the advantage of being able to update individual "files" without rewriting the entire document.

Also look at the related post which suggests doing precisely that - storing images inside SQLite blobs: https://www.sqlite.org/affcase1.html

[nodamage]

Is this really a good idea though? I thought it was generally preferred practice to store large binary files outside of the database. Otherwise the database file will end up growing pretty quickly.

[manigandham]

That's your call. If you're going to be storing 100gb of images then put them somewhere else, but this post is about using SQLite as a file format so storing binary files inside is not a problem.

[out_of_protocol]

Counterpoint: tiled maps, which are basically loads and loads of images, can be stored on disk as

- Direcory structure

- Zip file

- Tar file

- Sqlite db

Out of these, sqlite is the most compact, by far (also the fastest)

[fatboy]

We just transitioned our tiled images from using a directory structure to SQLite.

Having a single file per very large image (for mobile) makes transferring them to the phone over USB around ten times as fast. I wish I’d done it years ago.

[marcosdumay]

Creating huge files is usually a bad idea. It does not matter if they are a sequence of lines of characters, a gziped collecion of XML data, a binary format that requires 6000 pages of documentation, or a SQLite database.

If you can spread your data among many files, you probably should. Not everybody can.

[jamougha]

Storing large objects in database rows impacts performance and scalability but this shouldn't be a problem unless your files are extraordinarily large.