Run MongoDB compatible apps on Firestore (Zero code changes)

Key Takeaways

I have heard that you can now easily swap between MongoDB compatible databases and fire store. >> Yes, you can. Let me show you how. >> Welcome to the show, Patrick. What do you do here at Google? >> I lead the engineering team for cloud fire store. I originally joined the team 12 years ago when data store was only an integrated database for Google App Engine. >> Oh, I remember using App Engine with a built-in data store back in the day. So your team Patrick, you guys broke out App Engine's integrated data store and made it a standalone product and the result is Fire Store. >> Yep, that's pretty much the origin story. The App Engine data store was great, but it was tightly coupled to App Engine. People wanted to use a high-erformance and scalable NoSQL database like that from lots of other places. So we modernized it and made it available everywhere. And that became Fire Store back in 2017. >> Oh, 2017. How time flies. I still remember the announcement. >> I I hear you. Now we see Fire Store used all over the place. Folks are using it for mobile and web apps for things like collaborative productivity tools, game backends, and even LLM context stores. Fire store supports direct connections from mobile and web using our real-time SDKs or from serverside code running on something like cloud run or kubernetes engine which talk to fire store to handle all the data. >> Now, how is it even possible to switch to fire store? I've always been told that the database is the hardest and most expensive part to switch in any app. >> Well, in the Fire Store team, we built a MongoDB compatible interface from the ground up directly into Fire Store. We recently released it to Google Cloud and Firebase customers as part of our new enterprise edition. >> Okay. Uh, that sounds good in theory. Uh, how would it work in practice, Patrick? Here is a simple e-commerce application symbol direct. Let me place an order. The application uses Cloud Run and a MongoDB compatible database. Here is the order I placed in the database. >> Okay, so far so good. >> Let's say I want to try out Fire Store. I've prepared a Fire Store database ahead of time. I'll copy the fire store connection string from here into my application's environment variables here. Then I'll deploy a new version of my app that uses this new environment variable. Now I'll place another order. Here we can see my new order in Fire Store. That's cool. I shot a video a few years ago about switching between MongoDB and Fire Store. And in that video, we had to modify code to make it happen. But now you don't have to do that anymore. >> That's right. Now all you have to do is change a connection string. >> I liked your demo, Patrick, but I have so many questions. >> Go ahead, Martin. >> So why would I choose to use Fire Store? >> Well, many developers love serverless for its simplicity and pay-per-use model. It's why Cloud Run is so popular. But you need a database that works the same way. [snorts] >> And that's Fire Store. >> Yes, that's Fire Store. It's a serverless database that works well for one query per day or a 100,000 queries per second without you ever having to provision capacity, patch servers, or worry about sharding. It just works. You only pay for the reads and writes you actually use, not for idle time. And since it's fully integrated with Google Cloud, your AM networking and security are all in one place. Paired together, Cloud Run and Fire Store create a powerful, simple, and scalable stack for your application. >> Okay. Uh scalability. Uh let's talk about that. How does Fire Store handle performance under heavy load? >> Such a great question. Remember that online shoe store I showed you earlier where we placed those couple of orders? >> Uh yeah. Uh, symbol direct, right? >> Exactly. Well, I actually ran a pretty intense load test on it earlier today. You might think Fire Store can only handle an order every few minutes. >> That would be a pretty relaxed shoe store, >> right? But it can do so much more. Let me pull up the dashboard for that store. If you look at the top left graph here at the start of the test, we're seeing a few hundred orders per second. Then, as the load tester ramps up, we hit a peak of about 40,000 orders per second. >> Whoa, that's a lot of online purchases. I wish I had an online store that popular. >> Me, too. And if you look at the top right graph, as those orders surge, so do the Fire Store inserts. We see a direct correlation hitting 40,000 Fire Store inserts per second, which is what we'd expect. >> So, the database is keeping up with the incoming orders >> precisely. Now while fire store is handling the data the application itself runs on cloud run. Take a look at the lower right graph. You can see Google automatically scaled up the number of cloudr run instances from five to 100 to gracefully handle that massive load. >> And how did you configure that? >> I didn't. I deployed my cloud run service and Google took care of the autoscaling. No pre-provisioning, no manual intervention needed to handle 40,000 orders per second. It just worked. Very nice. Uh, but what if someone wanted to control costs and prevent Cloud Run from scaling up like that? >> Very valid concern. You can set a maximum number of instances for Cloud Run for this particular test. I didn't because I wouldn't want to turn away paying customers from my shoe store. And finally, to ensure our customers had a good experience, the lower left graph shows that the median latency for end users stayed around a snappy 18 milliseconds, even at peak order volume. >> 18 milliseconds. Not bad. Now, if I want to start using Fire Store, I'd have to move my existing data over. How would I do that? >> You would use data stream, Google's serverless replication service. It handles the initial copy of all your existing data and then uses change data capture to stream any new changes from your old database to fire store in real time. That way you can migrate with minimal downtime for your application. >> Great. Does this new uh compatibility support all my existing MongoDB queries? >> It supports over 200 of the most commonly used features and we keep adding support for more. Check the doc for details. >> Excellent. That was my last question. Uh, this was a lot of good info, maybe more than I can remember. Uh, what are the main takeaways here, Patrick? >> First, flexibility is good. Now, it's easier to switch between MongoDB and Fire Store in both directions. That's good for developers. Second, serverless is good. Fire store scales up and down with your needs with no need to provision ahead of time. And third, a single pane of glass is good. If you are using Google Cloud and Fire Store, you can manage your app and your database in one place. >> Good takeaways. Thanks for joining me, Patrick. >> Thank you so much for having me, Martin. >> And thank you everyone for watching. If you have any questions for Patrick or me, please add them in the comments. Also, let me know what you thought of this episode. I love hearing from you and I read every single comment. Can't wait to see what you build.