4 ms·

I'll reiterate what I said the last time it came up on HN - this is exactly why I use Firebase, and why OP probably should have done the same. It's literally 1

I'll reiterate what I said the last time it came up on HN - this is exactly why I use Firebase, and why OP probably should have done the same. It's literally 15 minutes to configure/integrate, and you're done. You can then move on to building/iterating on actual features that matter to customers. Until you've proved you're building something that people want to buy, your data layer only needs to do the absolute bare minimum (store some data). It doesn't matter if it's not scaleable, performant, extensible, etc. 99.9% of the risk is that you fail because you're not building the right thing, not that you fail because Firebase wasn't appropriate. You have a limited number of hours in every day, and they are much better spent building features side-by-side with customers. You won't even know that Firebase is a bottleneck unless/until your platform is successful, and at that point you're in a good position to migrate/rewrite/whatever. A couple of commenters smugly pointed out that they were contracted to fix Firebase issues later down the track, and that's why they would stay away from Firebase in the first instance. First up, there's clear survivorship bias there - the fact is these businesses survived and were in a position to hire someone to upgrade their data layer. That's meaningful in and of itself. Second, don't pay too much attention to people who have never bootstrapped anything from the ground-up. What works in a mature, stable, well-funded organization is not what works in a solo, early-stage startup that's strapped for cash, time and equipment.

nicoburns 6y ago
Setting up postgres on heroku is similarly quick and straightforward, also comes with a free plan for when you're just starting out, and won't leave you with the headaches you'll almost certainly have later with firebase. Firebase is slower to iterate on, because you have to bake your query patterns into the schema (yes your data still has a schema even if you don't have to define it up front) Using firebase for auth and/object storage makes sense. But I don't understand why anybody would choose to use the database(s) except for a few niches where realtime is critically important and query flexibility / data integrity aren't.
- nmfisher 6y ago
  1) Firebase storage has the advantage of one-click integration with auth (Google Auth, Sign in with Apple, etc). Probably not difficult to achieve with Postgres on Heroku, but why waste a couple of hours on something when I don't need to? 2) My golden rule is to avoid anything that doesn't get you closer to a customer in the next 14-28 days. For some use cases, Postgres on Heroku might help you do that. For me (see next point), it's just adding another platform/service for no reason. That will only slow me down. 3) I disagree that "Firebase is slower to iterate because the schema is implicit" (at least, as a hard-and-fast rule). It depends on how complex the schema is. You iterate on implicit schemas by rewriting code, and you iterate on explicit schemas by rewriting code and the schema itself. This is faster for complex data models with strong integrity requirements, but for basic data models (think mobile game leaderboards, etc) it's just unnecessary. That's not to say that any of this is a huge amount of extra work. I'm sure a lot of people are reading this and thinking "Postgres will just take an afternoon to hook up, why not?". The reason is that spending that afternoon with a user is infinitely more valuable than spending it hooking up Postgres. You have to be ruthlessly focused on what moves you forward, which at an early stage is simple - features, customers, users. On any given day, there are literally hundreds of things you could do that "will just take an afternoon". If you allow them to distract you, you'll probably end up like OP - 2 years in with a well-architected system that doesn't have any customers.
  - nicoburns 6y ago
    > You iterate on implicit schemas by rewriting code, and you iterate on explicit schemas by rewriting code and the schema itself. You've missed a step: you also have to migrate the data. In my experience this is by far the slowest / most complex step. And it's much easier with SQL where you can `UPDATE WHERE` and `INSERT FROM SELECT`. If you want a flexible schema then Postgres has JSONB which is just as flexible and usually performs better than firebase anyway. Plus you can use all the querying power of Postgres, JOINs, etc just like typed columns. > For basic data models (think mobile game leaderboards, etc) it's just unnecessary. If you're completely sure that you won't need powerful querying, joins, etc for any of the data you'll be storing then sure. Otherwise you lose all that time and more the first time you need a JOIN or a query that firebase can't do. And you pay that cost every time you need to implement such a feature (or you end up storing that data in Postgres or similar and you end up with two databases, which is much more painful than having two platforms).

nicoburns 6y ago

Setting up postgres on heroku is similarly quick and straightforward, also comes with a free plan for when you're just starting out, and won't leave you with the headaches you'll almost certainly have later with firebase. Firebase is slower to iterate on, because you have to bake your query patterns into the schema (yes your data still has a schema even if you don't have to define it up front) Using firebase for auth and/object storage makes sense. But I don't understand why anybody would choose to use the database(s) except for a few niches where realtime is critically important and query flexibility / data integrity aren't.

nmfisher 6y ago
1) Firebase storage has the advantage of one-click integration with auth (Google Auth, Sign in with Apple, etc). Probably not difficult to achieve with Postgres on Heroku, but why waste a couple of hours on something when I don't need to? 2) My golden rule is to avoid anything that doesn't get you closer to a customer in the next 14-28 days. For some use cases, Postgres on Heroku might help you do that. For me (see next point), it's just adding another platform/service for no reason. That will only slow me down. 3) I disagree that "Firebase is slower to iterate because the schema is implicit" (at least, as a hard-and-fast rule). It depends on how complex the schema is. You iterate on implicit schemas by rewriting code, and you iterate on explicit schemas by rewriting code and the schema itself. This is faster for complex data models with strong integrity requirements, but for basic data models (think mobile game leaderboards, etc) it's just unnecessary. That's not to say that any of this is a huge amount of extra work. I'm sure a lot of people are reading this and thinking "Postgres will just take an afternoon to hook up, why not?". The reason is that spending that afternoon with a user is infinitely more valuable than spending it hooking up Postgres. You have to be ruthlessly focused on what moves you forward, which at an early stage is simple - features, customers, users. On any given day, there are literally hundreds of things you could do that "will just take an afternoon". If you allow them to distract you, you'll probably end up like OP - 2 years in with a well-architected system that doesn't have any customers.
- nicoburns 6y ago
  > You iterate on implicit schemas by rewriting code, and you iterate on explicit schemas by rewriting code and the schema itself. You've missed a step: you also have to migrate the data. In my experience this is by far the slowest / most complex step. And it's much easier with SQL where you can `UPDATE WHERE` and `INSERT FROM SELECT`. If you want a flexible schema then Postgres has JSONB which is just as flexible and usually performs better than firebase anyway. Plus you can use all the querying power of Postgres, JOINs, etc just like typed columns. > For basic data models (think mobile game leaderboards, etc) it's just unnecessary. If you're completely sure that you won't need powerful querying, joins, etc for any of the data you'll be storing then sure. Otherwise you lose all that time and more the first time you need a JOIN or a query that firebase can't do. And you pay that cost every time you need to implement such a feature (or you end up storing that data in Postgres or similar and you end up with two databases, which is much more painful than having two platforms).