I think what Richard is saying is that a fix making the returned filename meet your (per documentation) expectation will have a performance impact for users not even using the serialization API. (I suspect you have misread the thread structure to read otherwise.) As I understand your report, you get a functioning in-memory database after the deserialize call. The problem you report is only that sqlite3_db_filename() does not return something indicating it is an in-memory database. Richard's question, and now mine, is: What impact does this odd returned filename have on what you can achieve, relative to what you could achieve if it had conformed to the doc? It would be useful to know the answer when considering changes that would address your use case.