7 ms·

[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

• aphextron 9y ago
  Very exciting. I found this to be the one "missing piece" keeping me from being able to build a whole app on Firebase when checking it out earlier this year. One question though, will this support BLOBs like GridFS?
  • habosa 9y ago
    You can store Blob data, but the maximum size of a single document is still 1MB. If you need to store larger blobs check out Cloud Storage for Firebase.
    • e12e 9y ago
      Could you share some of the reasoning behind arriving at a 1mb limit (why not 10mb or 512kb for example)?
      • itcmcgrath 9y ago
        Hard to explain externally, but it relates to RAM size allocation + throughput in the underlying distributed database system.
• TY 9y ago
  Just read through your link #2 and was very impressed. Firestore addresses every single concern I had with RDTB and more and I'm looking forward to using it in my side projects. Thank you!
  • mayop100 9y ago
    That's great to hear! Our design for Cloud Firestore was based on years of developer feedback. Glad we hit the mark for you : )
• judah 9y ago
  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?
  • habosa 9y ago
    Cloud Firestore has support for transactions: https://firebase.google.com/docs/firestore/manage-data/update-data#update_data_with_transactions https://firebase.google.com/docs/firestore/manage-data/updat... So yes, if any of the operations in the transaction fails (and cannot be retried) the whole transaction will fail. It's atomic as you'd expect. If you've ever used transactions in Firebase Realtime Database you'll be happy to know that the transactions in Cloud Firestore are much easier to use since they don't require selecting a common data parent. Queries are always strongly consistent. If you do a write-read sequence you'll see the value of the latest write.
    • ibdknox 9y ago
      How do you deal with consistency in the offline case? E.g. If I make a bunch of edits while disconnected, and others have made edits while connected, how are the conflicts resolved?
      • mikelehen 9y ago
        This works similar to the Realtime Database in that it's last-write wins (where in the offline case, "last" is the last person to come back online and send their write to the backend). This model is very easy for developers to understand and directly solves many use cases, especially since we allow very granular writes which reduces the risk of conflicts. But for more complex use cases, you can get clever and implement things like OT conflict resolution as a layer on top of last-write wins, e.g. similar to how we implemented collaborative editing with www.firepad.io on the realtime database. PS: Hi Chris! :-)
• cfilipov 9y ago
  Regarding offline mode. How is sync done? Is this OT based? How are conflicts resolved?
  • mikelehen 9y ago
    Good question, and to answer this well we should probably do a blog post or something. In the meantime you could dig into the code since the clients are all open source. :-) But basically, sync is split into two halves: writes and listens. Clients store pending writes locally until they're flushed to the backend (which could be a long time if the app is running offline). While online, listen results are streamed from the backend and persisted in a local client cache so that the results will also be visible while offline (and any pending writes are merged into this offline view). When a client comes back online, it flushes its pending writes to the backend which are executed in a last-write-wins manner (see my answer above to ibdknox for more details on this). To resume listens, the client can use a "resume token" which allows the backend to quickly get the client back up-to-date without needing to re-send already retrieved results (there are some nuances here depending on how old the resume token is, etc.).
    • cfilipov 9y ago
      Thank you!
• wahnfrieden 9y ago
  Do you have a rough timeline on beta => General Availability?
  • itcmcgrath 9y ago
    Nothing we can share at this time. Really looking forward to the feedback we get now we're in beta as this will feed into our GA plans.
• sandGorgon 9y ago
  Do you see this as an equivalent to Dynamodb ? Very timely ;)
  • jaxondu 9y ago
    DynamoDB does not come with offline sync.
• gfosco 9y ago
  Awesome to see this. I couldn't get behind the RTDB structure, but Cloud Firestore I will definitely use!
  • inlined 9y ago
    Woohoo! Is this an official parse endorsement? (Hi Fosco )
    • gfosco 9y ago
      Hey Thomas :) I speak only for myself, Firebase just got way better.
      • inlined 9y ago
        I'm glad. Hoping you like cloud functions too!
• insomniacity 9y ago
  How goes the work to improve customer service and support? Thinking about https://news.ycombinator.com/item?id=14359801 https://news.ycombinator.com/item?id=14359801, what improvements have you made in the last 139 days that would make us want to build on this?
  • steego 9y ago
    For their own sake, I hope the team gives this question attention and respect. What sets Amazon apart from many other companies is their reputation for relentless customer service. Customers pay close attention to the quality of answer or lack of answers to questions like this one. Every cloud company that asks us to invest our time in their proprietary API is asking us to trust them. If you violate one vocal customer's trust, we're going to notice. If you don't make things right, we're going to notice. Even before I read the article, I first read the comments to gauge the reception because I care more about the perception of trust before I even consider using something like this. Customers don't always stop trusting companies for fair or valid reasons, but that doesn't matter. Trust is much more of a visceral thing than a cerebral thing. So here's my question to other HN readers. What would Google need to do to improve its reputation for customer service? What would they need to do to make that commitment resonate with you on a visceral level?
    • techdragon 9y ago
      For me it's pretty easy. I want to start hearing and seeing positive anecdotes about real time communication with Google Cloud support. That is to say, I want to hear people start saying things like "I rang them, and everything was sorted out" ideally with a platitude attached like "it was actually a pretty good experience". I hear this about AWS all the time, and I've even experienced it myself. One client some time ago had an AWS novice who was confident they could handle setting up the auto-scale groups. They made a small mistake, which lead to the scaling trigger being permanently on, and it auto scaling to 1024 ec2 nodes within the first half hour. Immediately after deploying a fix for the scaling trigger, I phone AWS to see if there was anything that could be done about the cost of this accident, and I had a small monthly credit to compensate, and a respectable discount on the next appropriate AWS training course so that the novice could learn more and hopefully avoid future mistakes. THAT is the kind of story I want to start hearing about Google Cloud. "I used it and did not have problems", and "It works and was cheaper than AWS" is just not enough.
• novaleaf 9y ago
  glad you mentioned Cloud Datastore. It seems that Firestore supersedes Datastore and Firebase. Is that correct? Any comparisons of Firestore vs Datastore?
  • habosa 9y ago
    It does not "supersede" Datastore or Firebase Realtime Database, neither of those products are going anywhere. This is a totally new product that builds on what we learned from those two products, sharing some of the best features of each and bringing in some totally new things as well. All three are (in my opinion) great choices for building a new app today so make sure you evaluate all options.
    • revmoo 9y ago
      You posted this after two controversial but fair questions has been asked. Please answer them.
• mjw1007 9y ago
  Can you provide anything to reassure potential users that this will still exist in five or ten years time?
  • mbleigh 9y ago
    The Firebase Realtime Database has been around for ~5 years (and is still fully supported after this launch). Cloud Datastore has been around in some form (started as App Engine Datastore) since 2008. Cloud Firestore was a massive multi-year joint effort between Firebase and Google Cloud. Google is investing heavily in both, and this is a big deal for our teams.
    • mjw1007 9y ago
      Perhaps you could consider persuading the powers that be to make a loud public commitment. After all, if they are truly confident, there should be little cost in doing so.
      • mbleigh 9y ago
        We announced the product, that's a loud public commitment. Once it reaches general availability, it will be covered by the Cloud deprecation policy requiring a minimum of one year notice for deprecation. I'm not sure what other guarantees would even make sense to offer. If anything, I'd look at this announcement as ongoing proof in the magnitude of investment Google is making in Firebase and Cloud.
        • Cthulhu_ 9y ago
          I'd guess a forward commitment, like a LTS version? That would probably have an adverse effect though, since you'd be the only provider that goes (e.g.) "We will support this product for at least three years from now", implying (to people making Decisions) you'd pull the plug after three years. Maybe publish a long term (5+ year) plan / roadmap? idk.
          • 9y ago
• jonasb 9y ago
  The enhanced query capabilities are very much appreciated. I hope full-text search is in the works, since adding a 3rd party FTS engine adds quite a bit of complexity.
• paulsharratt 9y ago
  Good work guys, sounds like good progress! I'm struggling to see what this is giving me that I didn't have with RTDB though The queries seem to be doing what orderByChild equalTo startAt endAt limitToFirst and limitToLast were already allowing. Is there mostly a performance gain, or am I missing something that I can do now that I couldn't do before? Cheers
  • paulsharratt 9y ago
    I'll answer myself here for anyone else trying to figure out what we can do with queries now: --- We can now apply a filter and sort in the same command We can chain filters, though they can only apply to one field if they specify a range We can make a query that will only return documents, not the subfield data (i.e. what a lot of us were doing with the deprecated REST interface shallow=1) Queries in large data sets will be faster I guess? Things it'd still be nice to see - References that allow you to pull down related documents with a single query OR queries --- It's been a bit of rollercoaster seeing this announcement.. "Oh wow we can do proper queries now! Oh wait no, the queries don't seem to allow more than what we had before.. oh wait there are some improvements, it's a bit better now.. oh the shallow querying will be super handy! and they do geopoints.. but don't appear to have any way of searching for radius.. but they say they will soon" Anyway, good work all the same :)
• ec109685 9y ago
  While I know this is a beta and you’re solving a difficult technical problem, some of the limitations are concernig. With a system like dynamo, you can in most cases pay your way out of bottlenecks. It would be nice to develop a way in Firestore for users to be able to pay for the number of shards assigned to their workload to reduce relatively artificial limits such as write limits within collections and index update rate. That way, developers wouldn’t have to plan to leave the platform if their app is successful.