I'm currently working on a mobile app powered by a web platform, and the mobile app will have some offline capabilities. The application has a small amount of DB entities, and only about 3 of them will be written by the mobile app, and not by the web platform.

Since Firebase provides a good solution for offline data sync, my plan is to use it only for the data that actually needs the sync, instead of using it for every data on my app. So, when a user logins to the app, it will load some basic info from my API, loaded from MySQL, and then sync the specific data from Firebase.

I'm sticking to MySQL in the web app because it has several relational data, such as user specific data, profile and reports, so I believe it fits better in a SQL database. Besides that, I don't need all of it to sync with the mobile app.

My question here is whether I should concentrate all my data on a single DB engine, or my plan to mix the two engines is a good way to go?

I never used Firebase before, although I've used similar engines such as Redis. It just seemed like a good option for the offline sync. I'm open to suggestions for this as well.


  • Hi I had a similar idea/question. Could you clarify what architecture you came up with? – Koen Jan 30 '17 at 14:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.