> elaborate on this requirement I am at the design stage for an application which involves collecting measurements from various measurement instruments. There are several writer processes, recording new timestamped measurements from measurement instruments. There are several reader processes. Queries normally involve a large number of measurements from a single instrument, and rarely involve more than one instrument. I can see a design which puts everything in one database. This would be the one obvious design if using a server-based database. But sqlite's one-file-per-database model offers a spectrum of other design options. Maybe it could store all the measurements from each instrument in separate databases. Maybe it stores related instruments in separate databases. These options allow some application requirements to be satisfied in a (potentially) simpler manner, outside the database. For example, archiving a dataset and starting afresh could be achieved by renaming the dataset database file. File names can be data too. Ive got a good understanding of the relative advantages of all these options. The documented constraint is: > renaming an open database file results in behavior that is undefined Thats pretty clear, but I was hoping it was an oversimplification. I completely understand the problems caused by arbitrary renaming, but was hoping sqlite's existing locking mechanisms could be used to allow a safe rename in a controlled manner. Its not a big deal that this isnt possible. I can add either extra locking in the application layer, or an additional layer of indirection (symlink?) so that my conceptual "rename" gets implemented by changing the link.