There is something i don‘t understand about Firestore: If you use the web client your javascript code is directly communicating with the firestore database, you have no control about some user specific limits. How do you prevent some rogue actor from effectively doing billions of reads or writes.
With server side logic you can implement rate limits but not with a fire store web client. The only thing you can do is to limit your monthly budget? So one bad guy can burn all your money for a month without you having any possibility of limiting it?
For a subscription based Chrome extension (<a href="https://www.checkbot.io/" rel="nofollow">https://www.checkbot.io/</a>), I use Firestore, Firebase and Cloud Functions to handle subscription activation and login/authentication. I use Paddle for payments which fires a web hook to a Cloud Function when a purchase is made.<p>Works great so far for no cost and it hasn't required a single bug fix or any maintenance since launch. Firestore definitely has a lot of surprising caveats though and you need to design your app and data around this to avoid trouble later.<p>Does anyone have any stories to share about when they outgrew Firestore, what they migrated to and how? I wouldn't be keen to use NoSQL if my data became more complex.
Paying Firestore user here.<p>1. Disappointing that it has gone to GA without providing proper search (after a long beta). Can anybody explain why a service run by the worlds #1 search company continues to point users to third party services if you want to implement a basic text search in a database? I genuinely don't understand that.<p>2. Feature requests (or complaints) re backup, queries and documentation are not new. Nor are the answers (or excuses) we see here, which revolve around scalability and (until now) being in beta. BUT all users I have ever heard say they use the product for speed & ease of setup & convenience - for MVPs, not for massive googlesque data. It almost feels like the product market fit is not quite right. So, forgive my technical ignorance here, but worst case scenario, why not provide the features with the caveat that they are slow or expensive or won't work above a certain size of db? Isn't half a solution better than no solution?<p>The database and whole Google/Firebase app suite thing has some strong points. But to be frank, and I'm sorry if I'm being dismissive of hard work and technical wonders here, from the perspective of a customer and outside observer, a number of things smell quite off.
Been loving Firestore! It has been my first real experience w/ NoSQL in an MVP to production-ready quickly. It's been SO easy to experiment with and learn. Community has been great.
Anyone with inside knowledge of Firestore care to comment on the ETA of more advanced query functionality?<p>We have played with Firestore quite a bit, but rely heavily on the ability to do aggregate queries. Reading all of the documents and performing this on the client side is nowhere near good enough. Nor is triggering functions to update a "count" or "sum" property on a doc.<p>Edit: Looks like a PM answered on another thread...<p>"It's a point of internal discussion on scalable ways to achieve this, but nothing we can promise. We definitely see the need for it."
Why isn't there a hosted, easy to use relational version of Firestore? I'm using Firestore right now and it's absolutely frustrating in the lack of relations, the lack of accumulation queries (COUNT, MAX, MIN) and in general the limitations of storing what's essentially arbitrary JSON. How is it that to count the number of entries you either need to build in a counter on your own (which can cause race conditions because counters are hard) or manually go through the entire collection and count?<p>Another option would be a typed JSON db, essentially you could store JSON that corresponds to typed structs a la serde. Would't solve a lot of my problems, but at least I'd have some built in validation.
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.
I still haven't seen a great reason to go NoSQL over, say, Postgres. I'll think about a good application but then realize that it'll be a PITA to do something slightly different than what I first imagined.<p>What are good reasons to use NoSQL over SQL?
"More features coming soon. We're working on adding some of the most requested features to Cloud Firestore from our developer community, such as querying for documents across collections"<p>Looking forward to it. If this comes in, pretty much it removes the need for creating top level collections or am I missing anything?
I've been using Firestore in a React app and I love how it has simplified everything. There's no need to have redux or even an in-memory store in the "context". I just wrap my components with a withFSQuery helper and it automatically updates even when the state changes "server-side".
A months ago I published a write-up of building our our cloud sync in Polar:<p><a href="https://getpolarized.io/2019/01/03/building-cloud-sync-on-google-firebase.html" rel="nofollow">https://getpolarized.io/2019/01/03/building-cloud-sync-on-go...</a><p>Polar is basically a document management and annotation platform. You put all your reading in it and maintain it long term along with annotations, highlights, etc.<p>Firestore is really nice in that you can target multiple-platforms pretty easily. There are SDKs for basically every platform.<p>It's definitely not perfect but I'm pretty happy with the decision.
Will there ever be support for aggregate queries? Or queries for non-existent values?<p>I have a rather large dataset that's tough to scan over and I find the functions/transactions to build my own aggregates not entirely accurate enough since a document has rate limits for writes.
The issue we had with cloud Firestore is the inability to _really_ query documents through the Firebase console. It’s very basic and there is no third-party tooling available yet.<p>To run any kind of specific query you’d need to handle that application side. Just something to consider.
This service feels pretty shoehorned into the rest of GCP. There are little connectors everywhere for Firestore specifically, and they don't fit in cleanly with the rest of GCP offerings. Why is Google so bullish on this thing? I must not be seeing the appeal.
I find the limitations of their query language interesting, no way to test for undefined properties in a collection (the client libraries just give up, and I don't see a workaround); and no way to match on inequality rather than equality. This exists in some other odd database engines, but it's frustrating in general use scenarios (where, in this case, I don't exactly see how performance is a limiting factor).