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