

Announcing Lower, Simpler Pricing - mikexstudios
https://www.firebase.com/blog/2015-08-19-announcing-lower-simpler-pricing.html

======
Eridrus
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.

~~~
abeisgreat
(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.

~~~
Eridrus
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.

------
chrisfosterelli
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.

------
jenkinsj
I'm glad there is a simple $5 plan. This makes hacking on my small project
([http://fireform.org/](http://fireform.org/) \- plug) a much more reasonable
proposition.

~~~
listic
What is it supposed to do above Google Forms+Sheets?

~~~
jenkinsj
1) No Google branding 2) Email notifications 3) Use your CSS to customize the
look of your website's form.

------
listic
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?

~~~
chrisfosterelli
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.

[0] [https://www.firebase.com/docs/hosting/guide/custom-
domain.ht...](https://www.firebase.com/docs/hosting/guide/custom-domain.html)

------
buckbova
I just got this email too.

Price jumps from 5 bucks to 50. Still too pricey for me.

I did explore what they have to offer and it is fairly extensive. I'm not sure
about performance though. I did not test that.

~~~
inlined
Do you have a proposed model which is sustainable for both parties? What seems
both fair and reasonable to you?

~~~
buckbova
I can't speak on sustainability because I can't speak to cost to support that
much infrastructure.

Just seems a little low on storage and I think AWS's free tier offers more.

------
mozumder
Are they worried about competition from Apple's CoreData, which Apple
developers get as part of their registration?

~~~
dgoujard
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.

------
rco8786
What's the difference between the free plan and the $5 plan? They look exactly
the same, unless I'm blind.

~~~
spicyj
Paid plan has custom domain support.

------
teen
if only firebase could scale... they have so much downtime

~~~
abeisgreat
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.

------
sync
Summary of what's changed is available on their blog:
[https://www.firebase.com/blog/2015-08-19-announcing-lower-
si...](https://www.firebase.com/blog/2015-08-19-announcing-lower-simpler-
pricing.html)

~~~
sctb
Thanks, we updated the link from
[https://www.firebase.com/pricing.html](https://www.firebase.com/pricing.html).

------
CyberDildonics
Come on guys, this ad isn't even disguised as a wired article.

