Database schema update in production

Question

I have an app installed on mobile phones where users read and write to a Firebase database. I want to do a database schema change from:

|-- \"app\"
|    |--          


        

Answer 1

Your only choice, if you want to preserve functionality on both old and new version, is to support both versions :

• Any data structure specific of a given user needing migration can be updated once by the new app version (detect if the old format still exist and write as new).

• If some structure has changed for global data used by all users, your database should keep data both in old and new format. Being NoSQL, this should only cause issues with write consistency (need to update all locations).

Firebase or not, you cannot be expected to support old versions of your app forever. If you decide to support up to X previous versions, you will need to keep X versions of your data structure in parallel (and all the added complexities in writes operations).

Answer 2

Another solution with pros & cons:

1. Let your database store what versions of your app are compatible with the current schema
2. First thing when your app is launched, query this information in the DB
3. If user A has a compatible version, congrats!
4. If user B has not a compatible version, invite him to update his app, which could suck for him:
   • Maybe he's not able to update the app for technical reasons (for instance, for an iOS app, you increased your deployment target to an iOS version that is not compatible with this user's device)
   • Maybe he won't be able to update the app for a while because he's having poor network reception, etc.

I think maintaining several versions of the DB on Firebase is kind of an overkill, especially if your app is somewhat social and all versions should keep being functional. If version 1.0 creates content that should be accessible to version 2.0 and 3.0, and if you repeat this constraint to all other combinations of versions, uuugh, it's going to be a pain to maintain.

I think that's one major drawback using Mobile backend as a service solutions compared to traditional backends where maintaining a legacy endpoint would be much easier.