130 karma · joined July 28, 2016
While I like self hosting (was previously a RethinkDB user), from a business perspective, it doesn’t make sense to spend time on operations if it doesn’t give you a competitive advantage. It’s going to be very difficult to outpace a business that only has to focus on development versus one that has to do development and operations.
One of the things we liked about Firestore is that it takes the best practices of Realtime Database and makes them more explicit. Before, your RD database structure would look like `collection/{id}` and `collection_sub_collection/{id}/{sub_id}` in order to avoid loading sub-collections in top-level queries. With Firestore, this collections pattern is now part of the API itself, and sub-collections aren't fetched when the parent is fetched.
Another feature we liked is that transactions are no longer limited to a subtree of your database. Before, you would have to structure all of your transactional data under a single path. This would sometimes lead to having to pile-in unrelated data into a single object, such as adding payment data under a users object instead of a separate collection, so that you could atomically modify both user and payment data. With Firestore, transactions are global, so this isn't a concern anymore - we are free to structure our data in any way that makes sense for our app.
Overall, we had a great experience with Firestore during the alpha, and we'll definitely be keeping it as part of our technology stack. Congrats on the launch!
(disclaimer: this post isn't sponsored by Firebase)
(disclosure: The cake is a lie)