> You think a single file with potentially terabytes of content is portable? I think I was more excited about how storing everything in the database means better coupling, and better guarantees. E.g. any code related to handling missing files attached to sqlite rows just goes away if I have a foreign key constraint in my database. Likewise copying the database just means copying a single file, and insuring that the checksums match. This is in contrast to copying the database, then walking tens of thousands of files and insuring that their checksums match with the originals. > Decide: do you want the program to be fast to execute, or do you want it to be fast for you to write? You can't get both. Efficiency was never a large goal of this. Apologies for bringing up the "faster than fs" article. It was simply where I found inspiration for sticking a file system in sqlite. This will be a single-user local web application. That means low concurrent access to the database. What I need is fast IO and fast http transfers. Both of which are possible in javascript using libraries that leverage lower level C code. Javascript just happens to be a more agile and portable language (for me) for what I want to build. > So, you could chunk the files, storing 2 GiB or less per chunk. I'd actually suggest something more on the order of 1 MiB. Ok cool, this is definitely something I know how to build, but I feel like if theres a concern around indexing millions of _files_ in a database, then that problem is exacerbated by storing each file in 1MiB chunks in the database. In the case of an 8GB file, a single file would create 8000 rows. It would only take 125 files to reach 1 million rows. If sqlite row access speeds start to break down at around 1 million rows, does that mean this idea just isn't feasible at all? I do expect the number of files stored to be somewhere in the hundreds of thousands, and the total storage size to be hundreds of gigabytes.