Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Your data is your most valuable asset, and by using this you're locking it inside Google servers. If they decide five years from now to discontinue it, or to raise the pricing 10x, you're screwed.

You'd be able to move your data off of firestore. And there's legal business contracts around pricing. Google can't just raise pricing 10x overnight.



Sure, you can move it, but how much code will you need to rewrite? How much effort to convert the data to a new database format? And how much more development time to migrate your data without taking your service down during the migration?

It's a very expensive move that I don't think people consider when choosing this kind of solution.


Maybe I'm naive but I think a lot of people consider this, but the benefits of development speed outweigh the risk for a number of cases.


how much code will you need to rewrite?

If you're concerned that a service might shut down then you need to architect your application with that in mind, in which case how much of a rewrite is necessary is essentially up to you. Usually there's a tradeoff between going fast and engineering solutions that will work in the long term. Most startups never get to the stage where they need to swap out a service, so closely tying your application to a service is probably OK at the start.

If the service that shuts down is reasonably popular though it's likely there'll be very little code to change. API-compatible competitors will pop up to replace it. It happened when Parse closed.


The thing is, oftentimes these closed source database solutions aren't appreciably faster than choosing a managed solution that uses existing technology, like a hosted Postgres / MongoDB / whatever provider. In those cases your switching cost is vastly reduced, it's essentially a purely operational concern and your code doesn't need to change at all.


Have you used Firebase before? In my (rather limited) experience, the development speed increases from not needing to manage your own Mongo store, not to mention implementing all of their real-time features on top of that, are quite valuable. At least for an MVP I wouldn't hesitate to do the first version with Firebase to test my assumption even if I knew I wasn't going to use it at scale. Plus you can always wrap Firebase in your own layer from the beginning.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: