In a server that I am writing, I am receiving a small uploaded database file, and I thought it might be a good idea to keep the uploaded file in memory, rather than saving it to disk. Can I open this sqlite database without writing it to disk at all?

I thought that perhaps using fmemopen to create a FILE pointer to the data might allow me to use the file with sqlite, but I am only seeing the sqlite open methods that take a filename. Is there any way to open a sqlite database from a FILE* or from a data buffer directly?

EDIT: it seems that files made with mkstemp() are not automatically deleted on program exit, as files created with tempfile() are, so I guess I am still curious about a solution more similar to my original thought.

Is there any way to open a sqlite database from a FILE* or from a data buffer directly?

You can do this with a custom VFS. It wouldn't be difficult to write one yourself (a lot of the methods would be no-ops), but it looks like there already is one that works with a memory buffer.

You can also use sqlite3_deserialize.

If your build does not omit serialization (with SQLITE_OMIT_DESERIALIZE), the memvfs Roy suggested comes bundled, as it is used to implement sqlite3_deserialize.

Good to know; thanks for the info.

See also sqlite3_serialize and sqlite3_deserialize which can be used for this purpose.

It seems that they require an active sqlite3* connection already so you might have to start by opening an in-memory DB to avoid touching disk; I'm not exactly sure of the correct sequence of events.

The serialize/deserialize interface was designed to be used for this purpose.

An example use case for serialize/deserialize is the patch command of the Fossil Version Control System - the software that is running this Forum and that was designed and written for management of the SQLite source code. The SQLite devs use "fossil patch pull" and/or "fossil patch push" frequently. For example if I'm making a change to SQLite, working on my Linux desktop, and I want to make sure the change works on Windows before I commit, I move to my Windows-11 machine and type: "fossil patch pull desktop:sqlite/sqlite" to cause all of the uncommitted changes at "desktop:sqlite/sqlite" to be "serialized" into an SQLite database, sent over an SSH channel to the Win11 machine, then "deserialized", interpreted,and applied to the local checkout, whence they can be tested.

It turns out that SQLite database files make an excellent wire protocol for sending structured data that is a mix of textual, numeric, and binary content. More conventional encodings like JSON or XML do not work directly with binary content. You'd have to hex-encode (or similar) your binary content for use with JSON or XML. But SQLite databases handle binary without issue. This is what makes an SQLite database such a convenient wrapper for sending patches.

Usage Hint: The size of an SQLite database is minimized by setting the page-size to 512.

In my case, I will be extracting the data contained in the database and using it in response to the upload request, so it doesn't make sense for the uploaded file to outlive the request. To ensure I am not leaving behind a file that is written to disk for every request, I thought it would be good to simply never write the uploaded file to disk.

I don't know why nobody has pointed you to

https://www.sqlite.org/inmemorydb.html

which seesm to to what you want.