 Okay, hello. I'm Steve from OpenLand. I'm founder and CTO. We are doing a messenger for startups and for professional communities. And we, about a year ago, started to use FoundationDB as our only database for everything. And I here want to share our experience. So in this year, we have about 30 seconds of downtime. Not that big cluster itself, but it's not that small. It's about 200 gigabytes. About 30 processes that connected to the FoundationDB. And we don't have any kind of maintenance. We don't have the DevOps team. We don't have anyone looking at our consoles. It just works for the year. We didn't touch it. So what's our deployment? We started from a very small deployment with five machines that basically was used for coordination. For the some issues with FoundationDB, we keep them as coordination because it's too hard to configure for us. We just didn't have time. So then we deployed about five machines for the storage. Unfortunately, we were forced to deploy the separate machine for backup system because FoundationDB doesn't support Google Cloud storage natively. So we have to some kind of hack it. And in the end, we just added locks machines. Every machine has about four processes. So it's quite a big cluster. Yeah. Why not JS? Because JavaScript is basically just like a toy language. It's not suitable for production for most of us. But it have a lot of very nice properties. The first one is it's very easy to use. It have very high performance. It's almost like a goal line and C++ performance. But you just have to write it in correct way. It's just not everything works fast. And well, it have very nice GraphQL library that actually integrates very easily with FoundationDB. Well, it have now, it have a decent language type script that it actually can be considered like more production language. Developer experience is insanely good. So and now there are huge issues with Node.js ecosystem. Node.js just doesn't have any kind of decent distributed frameworks to build your apps. It allows you to build like very simple apps. So it's not, you actually can build, there are not something like ACCA or whatever. So all libraries that works with SQL is insanely slow. They are barely, you can actually use them at any decent sized application. So here, and we decided to go into FoundationDB instead of rewriting our app to a new language. Well, I already built three different backends from my streams. And my two previous attempts was built on top of ACCA, Java, Scala, all the stuff. But it turns out that you wait too much weight, you put too much weight on developers, because all of them have to know what is distributed computing, how to implement this. It became almost impossible to implement. Even having like a team of ten very smart people, they still can handle it. So we found that in DB we actually made a step back. And now our application server is basically just a stateless that serves request in response style. And all this complexity is uploaded to FoundationDB. And we use just for message bus. That's all. We are not using anything for question. So unfortunately, there are no, there are no any kind of libraries for FoundationDB, for not just, even bindings are unofficial. So we decided to roll our own. It's basically the same record layer that you probably hear today at Cloud Kit keynote. So we support like indexes streaming, even sourcing. We have some kind of sublayers inside of it. And we implemented this like in a month, I think, maybe in June. It was in production for more than one year. It didn't fail us. So, yeah. So this is how improvement over the SQL libraries on Node.js looks like when we just replaced everything with FoundationDB. So when you download a big chunk of data from SQL in Node.js, it will spend about 800 milliseconds just to convert this data to an object. It's not because of Node.js is slow. It's just kind of a very old legacy from different libraries. And all these libraries are benchmark against each other. So they don't see how fast they actually can be. And this green bar, it's not a parallel. It's completely blocked to the backend. So we basically got about 10 requests per second per process. So that's, you know, it's, you can do like anything with this. Then we just rewritten everything with FoundationDB and you can see how small is this. And like this small blue part actually can be parallel, can be performant in parallel. It's like you can do about like 40k operations per second. And our Node.js will still handle it without an issue. Yeah, let's keep one. So, and one of the nice features that we got with FoundationDB is that basically we can allow our developers to make much more mistakes. So basically, we have a very small team. So one of them is basically kind of in turn, the second developer is mostly middle engineer. And that's all. I'm not involved in the backend development anymore. And we are still going strong. And how FoundationDB helps us, because it's so, it has so great performance. It allows us to deploy bugs safely that didn't affect our front end without any impact on users. Actually, we rarely take a look at the graphs and on the stats. We usually find these bugs like after a month without like ever noticing anything. You can see it's like, I don't know, like 10k per second, right? It's skyrocketing like over 100. Probably just some mis-delay or whatever. So we don't feel anything. This is not because Foundation itself is fast, but the client design, FoundationDB client, it can throttle very carefully and can schedule the work evenly across the clients. So it won't interfere with between different workers, let's say. It was a huge issue on SQL because SQL doesn't have any kind of such scheduling. So there are like little examples of how it looks like. So our stack, our implementation is very easy to use and nothing like no rocket science here. So any junior developer can actually understand how to create objects, how to store, how to find, how to search. And we opted not to do some kind of shady optimizations and not like SQL usually do. Like query plan and all that stuff. It's easily can become unpredictable, especially for newcomers. So we opted not to use auto-incrementing features or all other features that can be slow to implement. So we just have to implement them manually. This saves us from a lot of issues when engineers just put auto-increment fields everywhere and everything became so slow. So query, like finding all the, finding from the user collection is also basically very naive. So you have two options. So use like a full search and not, I would say, you know, it's naive. It's simplest way you can write to find anything in your database. But everyone understands that find all is probably not a good solution for everything. And like you can easily understand this by a good decision in a specific case. It wasn't the true for SQL because when you try to convert this to SQL query, you probably will hear, you will need to guess if they're like an index, right index or wrong index. So is it like, is it a big table or small table? It became very unpredictable. And I explained this to every engineer is a little bit hard. We just, I just don't want to manage development. It's just, startups, founders usually doesn't have focus on everything. We just doesn't have enough time. So the system and team have to work by themselves. So, and what this, if we will need something more performant, we can see that we have support for indexes and like have much high performance version of search. So yeah, one of the biggest issues and for everyone, it's probably the last one. The only one for working with foundation DB is the latency because like, if you were working for simple apps, you probably didn't think about this and working on SQL, you never actually hit the network latencies. Like never. And for foundation DB, it's kind of an issue. So for GraphQL, we have like, for example, this small query to fetch the user, my current user and his batches. It's like write something next to his name. So we basically have to do several queries. The first one will read the version, read version. It will take maybe up to 10 milliseconds. Then we will query the profile itself. Then we will read the batch info and this will all take about 60 milliseconds. It sounds not very big, but actually if we will try to read this for 20 users, it became one-third of the second. And this became very slow. So in some, but thankfully for the GraphQL, it solves for us for free. So it actually can do parallel stuff. But in some kind of mission critical parts, you just have to rewrite all the code. And this is the only way where you can use very naive, primitive approach to build your app. So you can just write and it will just work without learning SQL, probably without indexes and all that stuff. So, yeah, that's about the all. So in the end, I can say that FoundationDB turns out super fast, very reliable. And our platform allows our developer, even from 10 developers to write features for our backend without breaking anything. And we don't have much tests, I can confess. So it's miracle that we work like, I don't know, we have like 100% uptime in the last half year, I think. So it's like, how is it possible? Yeah. And it's, I don't know, it's very, it's really hard to shoot in your food. Because you can see all the complexity of all operations and you basically use the same language for everything and it works just fast. Because we basically, because how light our libraries are, we have a lot of room for all the stuff that you can do on JavaScript. So, in the end, we have basically zero maintenance. It's mostly just experiments. I do all my experiments on production system. So, yeah, it actually works. So because of this, we had like 30 seconds of downtime. It was just during upgrade for a new version. It's just the issue with unofficial, not just bindings. Yeah, that's all. Thank you.