4 ms·

Having heavily used Firebase Realtime Database (firestore's ancestor), I think I will approach this one very carefully. Firebase Realtime Database was a nightma

by EZ-E 8y ago

Having heavily used Firebase Realtime Database (firestore's ancestor), I think I will approach this one very carefully. Firebase Realtime Database was a nightmare with frequent downtime, sometimes minutes, occasionally an hour. Also almost weekly, all clients sometimes wouldn't get notified of document changes which was crippling for our app.

jmvoodoo 8y ago
I've been using cloud firestore for 6 months now and haven't had an issue with it. Designing around their rules system has been annoying, and the lack of backups bit me once pretty hard (I built https://firesafe.app https://firesafe.app as a result), but other than that it's been great.
- thesandlord 8y ago
  I think one of the requirements for Firestore going GA was getting a b̶a̶c̶k̶u̶p̶ managed export system: https://firebase.google.com/docs/firestore/manage-data/export-import https://firebase.google.com/docs/firestore/manage-data/expor... Edit: As wsh91 says below, you are still responsible for the scheduling. (I work for GCP)
  - vira28 8y ago
    right, but didn't see anything mentioned about backup in the link. or am i missing anything?
    - wsh91 8y ago
      An export is one component of a backup solution. :) Scheduling is another (https://firebase.google.com/docs/firestore/solutions/schedule-export https://firebase.google.com/docs/firestore/solutions/schedul...). (Checking restores is critical, too; that's also feasible [managed import into a new cloud project] but requires a bit more legwork.) (I work on Cloud Firestore.)
      - jmvoodoo 8y ago
        FWIW, I'd love it if you made my app unnecessary. You can consider my site a list of feature requests :)
- vira28 8y ago
  Oh wow! I am just using this https://github.com/ChristianAlexander/FirestoreRestore https://github.com/ChristianAlexander/FirestoreRestore with cloud functions & cloud storage.
itcmcgrath 8y ago
Hi EZ-E - completely understand the concern. Cloud Firestore's architecture is very different and engineered to be an extremely highly available system backed by a 5 nines SLA. It has no scheduled downtime either.
pier25 8y ago
We once had a 13 hours downtime on our main product. It wasn't a fun day. We decided to move out of the Firebase RTDB because not only we weren't happy about it but it was unreliable. We still use it's static hosting and cloud functions.
bootloop 8y ago
Firebase Realtime was basically a Mysql instance which Google ended up with when they bought the Firebase ecosystem. Not scaleable at all. You see hints about this in some places when they talk about using it in production. I am sure some Google engineer went nuts when he saw what they have to support now. Firestore is a complete engineered Google solution based on the Google Datastore but with added features from recent years (spanner, cloud functions). This is very obvious if you compare the limits between Datastore and Firestore. IMHO they are not really comparable.

by EZ-E 8y ago

jmvoodoo 8y ago

I've been using cloud firestore for 6 months now and haven't had an issue with it. Designing around their rules system has been annoying, and the lack of backups bit me once pretty hard (I built https://firesafe.app https://firesafe.app as a result), but other than that it's been great.

thesandlord 8y ago
I think one of the requirements for Firestore going GA was getting a b̶a̶c̶k̶u̶p̶ managed export system: https://firebase.google.com/docs/firestore/manage-data/export-import https://firebase.google.com/docs/firestore/manage-data/expor... Edit: As wsh91 says below, you are still responsible for the scheduling. (I work for GCP)
- vira28 8y ago
  right, but didn't see anything mentioned about backup in the link. or am i missing anything?
  - wsh91 8y ago
    An export is one component of a backup solution. :) Scheduling is another (https://firebase.google.com/docs/firestore/solutions/schedule-export https://firebase.google.com/docs/firestore/solutions/schedul...). (Checking restores is critical, too; that's also feasible [managed import into a new cloud project] but requires a bit more legwork.) (I work on Cloud Firestore.)
    - jmvoodoo 8y ago
      FWIW, I'd love it if you made my app unnecessary. You can consider my site a list of feature requests :)
vira28 8y ago
Oh wow! I am just using this https://github.com/ChristianAlexander/FirestoreRestore https://github.com/ChristianAlexander/FirestoreRestore with cloud functions & cloud storage.

itcmcgrath 8y ago

Hi EZ-E - completely understand the concern. Cloud Firestore's architecture is very different and engineered to be an extremely highly available system backed by a 5 nines SLA. It has no scheduled downtime either.

pier25 8y ago

We once had a 13 hours downtime on our main product. It wasn't a fun day. We decided to move out of the Firebase RTDB because not only we weren't happy about it but it was unreliable. We still use it's static hosting and cloud functions.

bootloop 8y ago

Firebase Realtime was basically a Mysql instance which Google ended up with when they bought the Firebase ecosystem. Not scaleable at all. You see hints about this in some places when they talk about using it in production. I am sure some Google engineer went nuts when he saw what they have to support now. Firestore is a complete engineered Google solution based on the Google Datastore but with added features from recent years (spanner, cloud functions). This is very obvious if you compare the limits between Datastore and Firestore. IMHO they are not really comparable.