[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.<p>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 over querying functionality. For more info, see this comparison between the two[2].<p>This is a open beta launch, so the product has limitations[3] you should be aware of. We’ll be working to remove/raise these before General Availability.<p>A note on naming: Firebase launched in 2012[4] with a single product, the original database. As we added products (Firebase Auth / Firebase Hosting / etc), we began calling the original product ‘Firebase Realtime Database’, or RTDB for short. If you haven’t followed us lately, we’ve grown to become Google’s app platform, and now have 16 products to help you build/grow apps.<p>We’re grateful for the support HN has given us over the years and we hope you enjoy Cloud Firestore!<p>[1] <a href="https://cloud.google.com/datastore/" rel="nofollow">https://cloud.google.com/datastore/</a>
[2] <a href="https://firebase.google.com/docs/firestore/rtdb-vs-firestore" rel="nofollow">https://firebase.google.com/docs/firestore/rtdb-vs-firestore</a>
[3] <a href="https://firebase.google.com/docs/firestore/quotas" rel="nofollow">https://firebase.google.com/docs/firestore/quotas</a>
[4] <a href="https://news.ycombinator.com/item?id=3832877" rel="nofollow">https://news.ycombinator.com/item?id=3832877</a>
We're one of the startups shown in the announcement (Crypto Portfolio Tracker [1] - bottom right logo). Firestore enabled us to build the first version of our app in under a week. We've been using the product for over two months now, and it's given us a competitive edge in being able to develop features rapidly and not having to spend time on operations.<p>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.<p>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.<p>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!<p>(disclaimer: this post isn't sponsored by Firebase)<p>[1] <a href="https://cryptoportfoliotracker.com" rel="nofollow">https://cryptoportfoliotracker.com</a>
I don't like this trend of creating new closed source database systems that only exist on a single cloud provider.<p>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.<p>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?
This is great. I had a feeling something like this was coming given most firebase people were pretty open about what the shortcomings of the Realtime DB were and AngularFire received some much needed attention to its database API last week.<p>That said, I really hope there are plans for some full text search ability beyond the current suggestions[1]. I would very much like to ditch Elasticsearch in favor of db engine provided search. Even a small subset of the Elasticsearch/Solr feature set (similar to the full text search capability now available for Postgres[2]) would be a very welcome addition.<p>[1] <a href="https://firebase.google.com/docs/firestore/solutions/search" rel="nofollow">https://firebase.google.com/docs/firestore/solutions/search</a>
[2] <a href="https://www.postgresql.org/docs/9.5/static/textsearch.html" rel="nofollow">https://www.postgresql.org/docs/9.5/static/textsearch.html</a>
Does any of you feel cheated by Google? Rather than improving the existing product and providing backward compatibility, Google has chosen to build a new product with its own proprietary API.<p>I have a client who has invested significant amount time and money in Firebase Realtime Database. Now with this move, I am not sure if Google will support Firebase Realtime Database for next 5 years. So a full rewrite might be needed.<p>Once more it seems that going Cloud Native on one of Google's proprietary tools is very risky. I know many of the readers will say that Firebase Real-time Database is still supported. But the main question is: will it stay supported for years to come?<p>Google please please make an announcement and make a commitment to keep Firebase Realtime Database alive for "X" years to come. Otherwise, you are just making us developers lose faith in you.
> <i>Document Database for Apps</i><p>From linked page:<p>> <i>designed to easily store and sync app data</i><p>Maybe I'm misunderstanding, but that's not what I understand a "document" to be.<p>For me a document<p>- is a file that can be stored on a file system<p>- can be send via mail<p>- is using a standard document representation so can be used by different applications, such as markup (XML, HTML, SGML), or maybe PDF
Sounds interesting, but is there any independent description of what it cannot do, or what would be hard to do?<p>I just noticed it's much easier to understand a new datastore by reading its limitations (usually carefully omitted from pr articles or documentation).<p>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.<p>Sounds amazing anyway, more datastorage choices is always better for the world.
The firestore security rules dsl [1] looks like it could become cumbersome as the number of edge cases increases. I've briefly used firebase realtime database json rules [2] in a side project, and while basic acl scenarios can be covered cleanly, rules quickly tangle without a full programming language. It's hard to check syntax, lint, test, and collaboratively edit.<p>I believe this custom auth layer is best handled by allowing code with restricted api access and time constraints. The technical approach cloudflare used to implement its edge workers by embedding v8/js [3] would be perfect here.<p>[1] <a href="https://firebase.google.com/docs/firestore/security/get-started" rel="nofollow">https://firebase.google.com/docs/firestore/security/get-star...</a><p><pre><code> example:
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if false;
}
}
}
</code></pre>
[2] <a href="https://firebase.google.com/docs/database/security/" rel="nofollow">https://firebase.google.com/docs/database/security/</a><p>[3] <a href="https://blog.cloudflare.com/introducing-cloudflare-workers/" rel="nofollow">https://blog.cloudflare.com/introducing-cloudflare-workers/</a>
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.<p>Someone tell me they’ve found the holy grail?!
This is amazing! I just spent yesterday writing a separate app engine service to use cloud datastore even though the rest of our stuff is on Firebase (RTDB wasn't a fit for us). Great to see this is out
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.<p>Do you think $0.18 per 100000 writes solves this problem?
Just <i>never</i> use Google for building applications.<p>They have invested heavily over the lifetime of the company in avoiding providing support. That reputation can never be revived.<p>Google does not have direct customer support in its DNA, it has the opposite, whatever that is.<p>They have not demonstrated relentless commitment to being available to resolve issues, and <i>nothing</i> matters more than this if you've bet your company on their platform.<p>If something goes really wrong. Amazon has your back and you'll find someone who'll listen who has the power to resolve it. Google, you're stuffed. If you've built you're business around that thing that went wrong, well time for regret.
A couple of questions:<p>What's the underlying synchronisation mechanism?<p>Is it based on CRDTs?<p>How does this product differ from Gun.js and realm.io?
Looks great, however, I still have hopes that something similar to a GraphQL interface for a SQL based database is coming.<p>NoSQL is cool, but ultimately GraphQL/Apollo serves many of the same issues but has the capability of a much richer, standardized and potentially lower cost backend.
Couple of questions. For the querying:<p><a href="https://firebase.google.com/docs/firestore/query-data/queries" rel="nofollow">https://firebase.google.com/docs/firestore/query-data/querie...</a><p>It seems as though there is just the capability for AND logic between the WHERE queries, is that correct. Is the any plans to add AND/OR and perhaps a concept for representing grouping like parentheses?<p>And for the data structures:<p><a href="https://firebase.google.com/docs/firestore/manage-data/structure-data" rel="nofollow">https://firebase.google.com/docs/firestore/manage-data/struc...</a><p>Is there any capability to perform joins or have the data populated at query time?<p>And for the last thing:<p>It is mentioned multiple times in the documentation that nested collections will not be deleted if the parent is deleted. I'm just curious why there isn't the capability to insert a document with options that would allow something like a cascade delete. Since you allow indexes on collections, there is obviously some sort of metadata maintained, why not just add an additional flag that could be set so that whenever a record is deleted it can optionally have its subcollections removed as well?
The offline database experience still looks really primitive compared to Realm, and all the documentation seems to purposefully avoid any details with regards to conflict resolution. Are there any plans to address this?
Having a consistent relational db background, I always feel a bit lost about the patterns provided to associate models in no-sql land. Firebase db was 'weird' when it came to associations, don't see that much changes here. The feature is available, but... Fire store provide 3 ways to do so, but why ? Going through the docs the results/benefits for each patterns remains unclear, the way to query each of those is not really understandable reading the docs. is this state will remains or is it a field that is potentially to be improved in the next releases ?
Looks very exciting! I've used firebase for some small weekend projects and it's been very productive for me.<p>I'm curious, what's the react native support like for Firestore / firebase in general?
So read through the docs, decided to give the free tier a go and of course they are punishing me for being an existing customer.<p>"The Blaze billing plan (pay-as-you-go) for Firebase is required for Google projects with billing enabled.<p>To use the free tier, you must first turn off billing in your Google project."<p>I don't want 15 "projects". I want to add this to my existing one. Why on earth is this not possible?
I do like the new solution more than the Realtime Database, but I see only this solution to fit smaller scale. Applications with heavy write could get really expensive. Also, the standard plan has only "Maximum write rate to a document 1 per second". The write is currently three times expensive operation as read hopefully, this would be lowered in future.
Cosmos DB from Microsoft Azure seems to be a much better choose, because it provides tons of useful features, but it also compatible with MongoDB, so if they decide to increase prices or shut it down some day, you will be able to use regular MongoDB instead. With Firestore it's not the case and you are locked with a proprietary solution.
Great update, congratulations. It sounds similar to <a href="https://deepstream.io" rel="nofollow">https://deepstream.io</a> records - small JSON documents that are stored and synced in realtime across clients and can be arranged in lists and reference each other.
Why anyone still uses firebase when there's trivial to get running OSS ways of getting this done I'll never understand. People think stuff like this makes time to development smaller, I say it increases it deceptively
Another cool Google tech which will SUDDENLY go extinct when you need it most and which will ignore all of you support requests if it doesn't work properly and which will block you from all of you stuff in Google's system if you break smallest shady statement line in the TOS.
Do you really want to base your business on top of Google's stuff? Come on, even MS is more trustworthy than modern Google.