Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cloud Firestore: A New Document Database for Apps

firebase.googleblog.com

Post reply on HN
Print view View original

31–40 of 174 posts

Re: Cloud Firestore: A New Document Database for Apps

#31

Post by [deleted] »

judah wrote: post #21
jamest wrote: post #2

[Firebase founder] This new database has been in the works for 2.5 years, since shortly after we joined Google. It was developed in close collaboration with the Cloud Datastore[1] team, and uses Google’s core database infrastructure. We built it because we know it can be challenging to build complex apps with our original database -- Firebase Realtime Database -- where we optimized for ease-of-use & real-time sync ov…

What's your story on ACID, particularly on transactions? Transactions: If I want to insert 2 documents, but zero if either fails, what does that look like with Firestore? And if I store a document and run a query milliseconds later, will the query include document I just stored? Or are queries eventually consistent?

[deleted]

Re: Cloud Firestore: A New Document Database for Apps

#33

Post by hmexx »

joking wrote: post #27
hmexx wrote: post #22

I’m still looking for a product that provides firebase-levels of ease of getting up and running (no API to design, rule-based authentication, etc) , but runs on your own infrastructure, off of a traditional RDBMS. Someone tell me they’ve found the holy grail?!

You can use Apache usergrid or the open source version of parse for example.

I believe usergrid runs off of Cassandra and Parse runs off another NoSQL DB. Maybe Mongo?

Re: Cloud Firestore: A New Document Database for Apps

#35

Post by itcmcgrath »

irfansharif wrote: post #29
itcmcgrath wrote: post #16

Earlier quoted context omitted.

Sure, it's strongly consistent on the server-side part (strict serializability), whereas for the mobile/web clients we make sure we move you through consistency snapshots with the real-time sync functionality.

Congratulations on the release! > multi-region replicated database [..] once data is committed, it's durable [...] > strongly consistent on the server-side Do you mind elaborating a bit more here? Around perhaps what happens underneath the hood when failing over, etc. Do you have a single "co-ordinator" of sorts ensuring strict serializability, if so what do you do when failing this over? Or is it a quorum based appr…

Quorum based (Paxos)

Re: Cloud Firestore: A New Document Database for Apps

#36

Post by tannhaeuser »

sametmax wrote: post #23
tannhaeuser wrote: post #17

Earlier quoted context omitted.

> Why the downvote? Smells like ring voting: 4 downvotes in < 0.5 min? @dang?

French person here. What's ring voting ?

> What's ring voting?

Coordinated up- or downvoting from multiple accounts

Re: Cloud Firestore: A New Document Database for Apps

#38

Post by tannhaeuser »

staunch wrote: post #20
tannhaeuser wrote: post #17

Earlier quoted context omitted.

> Why the downvote? Smells like ring voting: 4 downvotes in < 0.5 min? @dang?

Any post having to do with YC, Google, Microsoft, Facebook, Apple, etc are voting ringed to hell by their thousands of employees. As the site has grown, HN has become a bit of a mouthpiece for large organizations through these de facto voting rings. Best idea I have is for HN to add a profile field like: "Organizations: [google]" which would prevent voting on any Google-related submissions. It could also add a discla…

> HN has become a bit of a mouthpiece for large organizations

In don't mind (in fact, appreciate) this aspect of HN as long as it's done openly and civilized.

> Best idea I have is for HN to add a profile field like: "Organizations: [google]" which would prevent voting on any Google-related submissions. It could also add a disclaimer in each comment these submissions, so users wouldn't have to remember to do that.

That's a brilliant idea.

Re: Cloud Firestore: A New Document Database for Apps

#39

Post by habosa »

adamonkey wrote: post #30

How is the pricing? Firebase Realtime Database is fairly expensive ($5/GB of storage per month), so it makes economic sense for developers to migrate to their own backend once they hit a certain scale. This is why third-party mobile backends are nowhere near the popularity of non-mobile backends with Google Cloud / AWS. Do you think $0.18 per 100000 writes solves this problem?

As you've noticed, the pricing model is totally different for Cloud Firestore. Link for others reading: https://firebase.google.com/docs/firestore/pricing

If you're concerned about price per GB stored, Cloud Firestore will be much cheaper than Realtime Database (0.18/GiB/month). We evaluated many use cases when deciding on prices and we believe developers will be happy with the new model.

However since Cloud Firestore charges by operation, it's important to evaluate your use case when thinking about pricing. For example if you're running a fleet of IoT devices checking in a few times per second with very small payloads, you'd be doing a lot of write operations with very little storage and Cloud Firestore could be more expensive in that case.

Re: Cloud Firestore: A New Document Database for Apps

#40

Post by deepsun »

Sounds interesting, but is there any independent description of what it cannot do, or what would be hard to do?

I just noticed it's much easier to understand a new datastore by reading its limitations (usually carefully omitted from pr articles or documentation).

For example, I suspect that Firestore must be built on top of Spanner infrastructure, as it's the only way to get usable cross-datacenter many-row transactions. And Spanner's limitation is it's high price. And if it's not Spanner, but more like Cloud Datastore or the old Megastore, then there should be limitations on transactions.

Sounds amazing anyway, more datastorage choices is always better for the world.

Post reply on HN