I spent a little bit of time examining different options in this space a few weeks back, I found these options:
Firebase
Couchbase Mobile Sync Gateway
CouchDB
PouchDB
Amazon Cognito
Azure Mobile Data Sync
Cloudant
My main issues with Firebase (in order of importance) were:
a) Uncontrollable sync. It seems to always use a web sockets/long poll, and count how many connections you have. Which is not appropriate when data changes infrequently and you're concerned about your users battery life. Mainly, I wanted to be able to do push using GCM/etc.
b) Single unmodifiable conflict resolution strategy
c) SaaS-only
It seems very polished and easy to get started with, but since there was no upgrade path to anything else, the fact that it really wasn't a good fit for my sync needs made it seem like a bad option.
I'm not a huge fan of these systems in general since they have you connecting to a dedicated database that you plug code into (eg as a sync function), rather than exposing building blocks for you to build a sync service.
But I'm still using pouchdb on the client for the moment, and I haven't fully figured out what the backend will be, but at least I have a few options in pouchdb-server/couchbase/couchdb/cloudant.
Firebase presents a last write wins sync on an unsecured database, however, because the security language rules are dynamically evaluated every write (with strong consistency), you are able to add other types of synchronization. For example, firechat[1] implements operational transforms, and this post[2] adds 2 phase commits. You have to figure it out yourself though which can be a fair bit of work.
regarding a) different types of sync, we recently added offline persistence, and there is also the REST API, but yeah, GCM sync would be nice to have and something we have been thinking about.
Thanks, I'll have a read over those two posts, I couldn't really find much discussion of conflicts when I looked.
If GCM/etc sync were available, I'd be very interested in using firebase, since I essentially want things to be offline-first with push messages when things get written to.
(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/) 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.
If I were making straight HTTP requests I don't see what benefit I would be getting from Firebase at all.
I'm not necessarily thinking of a wildly different conflict resolution scheme, but the fact that it is fixed means that if the behaviour is not quite what I want, I either have to just deal with it, or move to another system. In particular, when there are two conflicting writes to a string field, in scenarios where data loss is not acceptable, I would prefer to tell the user about it than just have the last write win.
I haven't run a sync service before, but I'm not really clear on what makes it require a huge ops team compared to any other high scale system.
Obviously piles of people are using it and are happy with it, it just seems like a pretty narrow solution atm.
It's a JS library and sync protocol between client and server. However, there is no official server implementation and as a result the library isn't tied to any particular database nor data model. We're hoping others will fill in the gaps on the server side.
I don't see rethinkdb in that list, admittedly you'd have to roll your own layer between database and user, but I think it might be a good option for a roll your own firebase clone.
In my opinion this makes Firebase way more approachable. Previously, their limited number of connections made it very, very expensive very quickly. Storage seems like a much more logical scaling factor.
What is the actual difference between the Free ($0) and Spark ($5/mo.) plans? I see the difference in custom domain, but it hardly matters with a backend service like Firebase, doesn't it?
Firebase can host your front-end content on its CDN, SSL supported, via their Firebase Hosting package[0]. This is the reason to use the Spark plan, so you have a custom domain for that, I believe.
I think there are a lot of flat file hosts that complete with Firebase Hosting for around $5/month and the Spark plan is just to reach feature parity with them by allowing custom domains.
You can't use iCloud as backend for other platforms. If you like to port your iOS app for android you cannot use the same backend. It's a major restriction if you wish to extend your app in other devices.
I know many people on the Firebase team very closely and they're definitely aware of the downtime issues and they're making it a top priority, I'm sure it will be improving very soon.
Firebase
Couchbase Mobile Sync Gateway
CouchDB
PouchDB
Amazon Cognito
Azure Mobile Data Sync
Cloudant
My main issues with Firebase (in order of importance) were:
a) Uncontrollable sync. It seems to always use a web sockets/long poll, and count how many connections you have. Which is not appropriate when data changes infrequently and you're concerned about your users battery life. Mainly, I wanted to be able to do push using GCM/etc.
b) Single unmodifiable conflict resolution strategy
c) SaaS-only
It seems very polished and easy to get started with, but since there was no upgrade path to anything else, the fact that it really wasn't a good fit for my sync needs made it seem like a bad option.
I'm not a huge fan of these systems in general since they have you connecting to a dedicated database that you plug code into (eg as a sync function), rather than exposing building blocks for you to build a sync service.
But I'm still using pouchdb on the client for the moment, and I haven't fully figured out what the backend will be, but at least I have a few options in pouchdb-server/couchbase/couchdb/cloudant.