(Full disclosure, ex-Firebase employee and I make my living building Firebase powered apps) In response to your issues... A) If you really wanted, you could m

(Full disclosure, ex-Firebase employee and I make my living building Firebase powered apps) In response to your issues... A) If you really wanted, you could make HTTP requests to the REST API (https://www.firebase.com/docs/rest/api/ https://www.firebase.com/docs/rest/api/) and that would not force you to use any long standing connection or any more battery life than other options. B) I think this is a matter of preference. Firebase chooses simplicity over power in this case. The vast majority of developers and applications don't call for custom conflict resolution strategies. Firebase lets you focus on your app, not on these fine-grained details. C) The SaaS-only argument is valid if you have a huge ops team who you can dedicate to running a complicated, stateful, realtime system like Firebase. However, 99% of the time, we don't have this luxury, so we pay the Firebase team to do it. I look at the SaaS-only aspect as a big plus. I know they're running Firebase in an ideal situation on ideal machines and I don't have to think farther than that. Once again, it just lets me focus on my app, not the details. I can't disagree, if you have very low-level / complex sync needs, Firebase probably isn't a good fit for that app, but in terms of upgrade path, it doesn't have one because it is unique and exceptional. It's a little crummy that there aren't competitors you could hop to if Firebase went away, but Firebase doesn't have many competitors because they do such a good job and blow others out of the water when they pop up. Regardless, I don't know your app, so it could very well not be a great fit, but it definitely has legions of benefits over Pouchdb/etc/etc in a huge number of situations.