4 ms·

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

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).
- nmfisher 6y ago
  > 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`. I didn't miss a step, because until you have paying customers (or at least, some other indication that you have a product that people want), there's zero data to migrate. If someone isn't paying, just blow away their data. If they are paying? Congratulations! You have a product that might be worth migrating to Postgres. > 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). I think you're missing the central point, which is that until you have paying customers, you don't know whether you're even building the right thing. There's usually no way of saying "I'm sure we will need powerful querying" because you have zero clue whether there's any demand whatsoever for the idea you have in your head. In fact, 90%+ of the time, there isn't, which is why we fail so often at it (including OP). Everything you do in the early stages must be geared towards proving whether or not you're actually building something people want, not getting sidetracked by non-core technical issues. That doesn't mean I think you should never use Postgres straight up. Sometimes an RDBMS is so integral to your idea that it's actually easier to use Postgres than a NoSQL DB (like a GIS application or some such). But more often than not, it's not, and you need to be ruthlessly honest with yourself about what you actually need to build to validate your concept.

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

nmfisher 6y ago
> 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`. I didn't miss a step, because until you have paying customers (or at least, some other indication that you have a product that people want), there's zero data to migrate. If someone isn't paying, just blow away their data. If they are paying? Congratulations! You have a product that might be worth migrating to Postgres. > 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). I think you're missing the central point, which is that until you have paying customers, you don't know whether you're even building the right thing. There's usually no way of saying "I'm sure we will need powerful querying" because you have zero clue whether there's any demand whatsoever for the idea you have in your head. In fact, 90%+ of the time, there isn't, which is why we fail so often at it (including OP). Everything you do in the early stages must be geared towards proving whether or not you're actually building something people want, not getting sidetracked by non-core technical issues. That doesn't mean I think you should never use Postgres straight up. Sometimes an RDBMS is so integral to your idea that it's actually easier to use Postgres than a NoSQL DB (like a GIS application or some such). But more often than not, it's not, and you need to be ruthlessly honest with yourself about what you actually need to build to validate your concept.