I think the way you'd have to do it is to effectively publish new database versions to their own path. Symlinked as much as possible, so they can back onto the

I think the way you'd have to do it is to effectively publish new database versions to their own path. Symlinked as much as possible, so they can back onto the same database, but you'd do something like this: http://host/db/1.0.0 http://host/db/1.0.0 is your original database. http://host/db/1.0.1 http://host/db/1.0.1 is what you publish when you fix a bug. http://host/db/1.0 http://host/db/1.0 could be a redirect to /1.0.1. http://host/db/1.1.0 http://host/db/1.1.0 is what you create when you add a new column. It's backwards compatible with /1.0.*, so you can either leave those paths working or you can redirect them to /1.1.0, depending on what guarantees you want to be making to your clients. http://host/db/2.0.0 http://host/db/2.0.0 is the version with an old column deleted, but you'd want to check in your access logs that nobody was still requesting any 1.0 version before publishing it. Either way, when this gets published you want to stop serving the /1.0.* path because 1.0 and 2.0 now can't come from the same backing file. But 1.1 and 2.0 can come from the same file if you've given everyone time to stop using the deleted column. It's not a great scheme, but it does give you a way to get new client connections onto the right version. For clients that have a session which lives across database upgrades, I think what you'd need is a `schema_version` table the client could check however often makes sense, and let themselves get reset if they find there's a new version available.