5 ms·

I don't like this trend of creating new closed source database systems that only exist on a single cloud provider. Your data is your most valuable asset, and b

I don't like this trend of creating new closed source database systems that only exist on a single cloud provider. 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. Are most developers only working on short term projects? Why would you put yourself in such a situation instead of using open source technologies that can be deployed anywhere?

cobookman 9y ago
> 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.
- stefano 9y ago
  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.
  - kerryritter 9y ago
    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.
  - anderspitman 9y ago
    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.
  - onion2k 9y ago
    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.
    - ryanbrunner 9y ago
      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.
react4 9y ago
To your point and for precisely this reason, we offer realtime capabilities but on top of the Elasticsearch engine[1]. We also have a cloud native version in preview (that we are actively developing) which addresses deployment flexibility[2][3]. [1] https://appbase.io https://appbase.io [2] https://store.docker.com/images/appbaseio https://store.docker.com/images/appbaseio [3] https://appbaseio-confidential.github.io/streams https://appbaseio-confidential.github.io/streams
jrowley 9y ago
How many of projects last 5 years? I'm notorious for short term thinking, but often times if pays off.
rothbardrand 9y ago
Plus Couchbase does the same thing, is open source, and has been in production for quite awhile. It seems a lot of developers use the HN stack: eg things thatvwent thru YC or that they hear other devs talking about a lot on HN.

cobookman 9y ago

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

stefano 9y ago
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.
- kerryritter 9y ago
  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.
- anderspitman 9y ago
  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.
- onion2k 9y ago
  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.
  - ryanbrunner 9y ago
    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.

react4 9y ago

To your point and for precisely this reason, we offer realtime capabilities but on top of the Elasticsearch engine[1]. We also have a cloud native version in preview (that we are actively developing) which addresses deployment flexibility[2][3]. [1] https://appbase.io https://appbase.io [2] https://store.docker.com/images/appbaseio https://store.docker.com/images/appbaseio [3] https://appbaseio-confidential.github.io/streams https://appbaseio-confidential.github.io/streams

jrowley 9y ago

How many of projects last 5 years? I'm notorious for short term thinking, but often times if pays off.

rothbardrand 9y ago

Plus Couchbase does the same thing, is open source, and has been in production for quite awhile. It seems a lot of developers use the HN stack: eg things thatvwent thru YC or that they hear other devs talking about a lot on HN.