 Welcome everyone. As Dave said, my name is Ben Collins. I'm Project Lead for FoundationDB. So let me tell you a story. It's year 2010. I reconnected with some acquaintances from high school actually. And they told me they were starting a new database startup. So they were telling me all about it. They told me that it was going to be this amazing thing, this great project. And they told me they've been working on it almost a year and they've made great progress. It was really pretty far along. They've paid down a bunch of the technical risk and it seemed like a pretty sure thing. And that's what they told me. I mean I had a pretty good job. Honestly a great project. But I quit this job. I was going to join the startup. So super excited. First day. We're working in the founder's house. So I go there. I sit down and I'm like, alright let's get hacking. Let's get going on this. Super psyched up. And they look at me and they say, Ben, there's no database. So as you can imagine, I'm all taken aback. They say, but good news. We have a simulation of a database. So now I'm a little skeptical about what this might mean. And I'm like, well that's pretty cool. This is like almost a year. This is what you have. They're like, no, no, no. We actually wrote a programming language first. And then the simulation. So I feel pretty skeptical about that. But anyway, as you can tell the project has come a long way since then. We actually did build the database. So that's the story of how I got involved in Foundation EV. Let me tell you a little bit more. Like why was it that at that time we wanted to do that work, build those tools and look into where we've got data storage needed to be years from then. So this really gets us back to the in 2010 to the sort of whole sequel versus no sequel debate. I mean really this was like the beginnings of it, cap theorem, all that stuff, right? So the technology obviously leading up to this time, as many of you know, right, was the sequel database. Sequel database is super powerful. Obviously very mature technology around since the 70s, right? They did a very powerful query language. But also maybe more importantly, very powerful concurrency model. That is through asset transactions, it made it easy for developers to write correct and efficient code. It scaled well. But there was a fatal flaw, right? And that these databases did not themselves scale, right? And at that time it was becoming very clear that we needed scale. Really, you know, shops, projects of all sizes needed to scale past that single machine. And this gives rise to the whole no sequel movement, right? So no sequel is all about taking that one machine and scaling it out. So there were a lot of different projects in this area. And we got scale, right? We achieved this, but at great cost, right? These projects did away with a lot of the consistency that had made sequel systems so powerful. And in doing so, given up a number of the advantages that we knew would lead to easy programming against those systems. So when we set out to build this, we were trying to, we knew we needed the scale. We also felt strongly we needed this consistency, right? So we wanted to take a system that brought these many nodes and put them back into a consistent system. The question then was, what type of database would we build? Right, at the time there were graph databases and column family databases, document databases, all sorts of things. When we thought about it, we realized we didn't really want to be limited to a single data model, but instead we wanted to have access to many different data models, right? And so the approach that we took was to build a single simple API at the lowest level, this key value store API, with the option of adding on top of it layers that would let more advanced data models be built, right? So like graph or document, maybe even sequel itself, right? So that's sort of the design of the server layer. Now what does this mean for you if you're an app developer, right? This higher level of consistency means your app can be written in a simpler, more efficient way. And when it's on top of these higher consistency systems, it can be written in a stateless manner, so that it scales well, right? If it's some containerized environment or something like that, right? A stateless app is easier to scale. So that's sort of the philosophy of the FoundationDB ecosystem. You know, one thing I'll note before moving on, you know, when we started this project, there was a lot of skepticism about this approach at all. Really, you know, people actually said that it was impossible to build this distributed consistent system that was really a prevailing thought at the time. You know, we ended up being able to build this, but I think it's interesting to note that the community has really moved in this direction, the wider industry, right? Lots of systems are adding consistent features, and it's really interesting to note that a lot of the major public clouds are differentiating based on some scalable and consistent data store. So, you know, I think those years ago when we were planning this, you know, we looked forward and saw we wanted the scale and we needed this consistency. All right. So that's my intro to FoundationDB. So let's fast forward to today. Where are we? You know, Dave said a few of these things. We're super excited. Thank you for spending your Monday with the rest of the FoundationDB community. I really appreciate it. We are, you know, there's a lot of momentum eight months in. We have, as I checked the other day, 56 separate contributors to the Key Value Store. So some of those obviously are from the major production shops at FoundationDB, but there's a lot of new people in the project. A lot of folks who are just getting into the project and maybe even doing this on their own. So a lot of involvement. You know, I think at the end of the day, the thing that I really want everyone here to get out of it is to have some way that they can be more involved in the community and in the project, right? We're going to hear a lot of talks on different topics, and Dave touched on some of them, and I'm going to go a little bit deeper. But I think that, you know, it's a mature project, but it's still one that's just sort of starting out of the open. And there's a lot of great ways to get involved. So I hope that when we're done, everyone has some new idea in their mind about how they can make that reality for them. I want to talk about a couple projects that have made some, had some good movements since we open sourced. I can't mention all of them. Obviously, there's been a lot of different improvements, a lot of projects. Swift findings and, you know, improvements in memory storage and all sorts of things. But I've chosen three that I think really unlock something for FoundationDB today, but also like as we look forward going into the future, right? The first one I've got to mention is document layer, right? If you haven't seen already, please check it out. This went open source under two weeks ago. I'm very excited about it. If you're someone who is looking to get involved with FoundationDB as a user, it could not be simpler, right? Let me describe a little bit, right? The original theory what I talked about was that we would have this key value store as a base and it build layers on top of it, right? And the document layer exposes the MongoDB API. So this really makes it easy for folks to get involved in terms of using it. You can use stock MongoDrivers. But also, like I have to tell you, this whole layer is only 12,000 lines of code, right? That's not much given that it's an entirely new data store built on top of only a key value store, right? So the document data model, so it's a great place to get involved in terms of using, but also in terms of contributing to the project, right? Baskar is going to talk about that a little bit more later in the day. But I think this is a really exciting step for the project in the community because as I said earlier, kind of the philosophy was this key value store with data model layers on top of it. And I think this is the first one to enter the FoundationDB project. It's a real general purpose layer like this. So really exciting. The next is the Redwood storage engine. You know, it might seem like a storage engine is something kind of like at the back of the data, you know, something that maybe isn't too important in terms of how a database works for the user. But really, Redwood is going to unlock a number of things as we move into the future, right? So it's already an experimental version on master. So you can check it out and play around with it, right? There's things that it adds today in terms of prefix compression and other things. But as we look for it, I think it's going to unlock a bunch of performance. It's the first custom built storage engine for FoundationDB. So it's designed around the unique requirements. And Steve is going to talk some more about that later in the day. But I think it's going to unlock a number of things performance wise, but maybe even more importantly, if you're used to using FoundationDB, that read transactions can only last for a shorter period of time. And that means that what a client can read in any given transaction is limited by that. Redwood is going to add on disk versioning to data so that read transactions can scan through enormous amounts of the database at once. So it'll unlock a number of analytics type use cases where you can read through the entire database at a consistent version and get one picture of everything. So I'm really excited about this, right? There's new capabilities in a distributed sense, new performance that we're going to unlock. So this I think is a big deal. The next thing I want to talk about, if you saw the release of version six a few weeks ago, you saw a mention of multi-region HA. Really, this is a collection of features that went in. It's not really exactly one specific feature. But multi-region HA unlocks a bunch of capabilities of moving your database out of a single data center, right? The simplifying premise we're working under when we started the project was that every node in the cluster sort of had equal access to every other node. It was a homogenous network, right? And so these new features basically take it so that the database from a single region to multiple regions and add to availability, but also add to how your data can be accessed, right? So enterprises want a database that can handle region failures, but also want data closer to the edges to bring it closer to the customers. So Evan will talk about this later in the day, but it's not a fully finished area, right? There's a number of ways it can be used in version 6.0. But there's major new features like the log routers and async logs and things like that. And there's a number of companies that are working on FoundationDB that are adding features in this area. So I think multi-region and HA features are going to be really important over the next little while. So FoundationDB isn't really just about the code, right? As we've been mentioning already a bunch, it's really about the community. And the community is going to be evolving along with the code. One thing that we're going to be starting soon that I want to mention is having open developer meetings where the contributors and committers are discussing upcoming features. It'll be, I think, a window into the prioritization so that folks who are either looking to use FoundationDB in production or looking to contribute to it will have a better idea of what things are upcoming and the other priorities of people developing on the core. What should come out of that, I hope, is that there'll be some more open roadmaps, right? In terms of understanding the things that are how FoundationDB is going to evolve in the near term. So let me talk a little bit about, you know, these are the today's talks that, as Dave mentioned, fall into some categories. And as I said, I'm really hoping that these talks spark your imagination in terms of ways you can be involved, right? So there'll be talks about the key value store in terms of how it's actually built and how it scales and where it's going in the future. And so if you want to be involved in contributing at that level, these talks are going to be hopefully interesting to you. You know, the next thing is about layers, how to build them, how to do general data modeling. I think, you know, FoundationDB has a lot of room to keep being expanded into the future to be extended through layers. And I think if you're looking to be involved in the project, this is a really great area. So some of the talks will be directed at specific data modeling layers, but also some of them will be more general about data modeling on top of the key value store in general. So those could be good talks for you. And the last would be operations, right? So everyone at the end needs to run FoundationDB in production, right? So there's a lot of experience so far from a few places about this. And so I think that this will be something that will be pretty widely applicable. So there's obvious ways to get involved in terms of contributing code. I just wanted to throw out a few more things in terms of, you know, if you weren't ready to dive in and work on the code of the project, really like the community is bigger than just the things that compile into the binaries, right? So if you're running in a production, which I know a lot of people are, like writing up your successful experience with running it on a certain cloud provider or on-premise or what have you. However, the things that you've hit that have worked well or some, you know, pitfalls, that is always going to move the community forward. Some benchmarking, right? This is another thing. Benchmarking a distributed database is actually pretty tricky. So this is not something that I'm suggesting is going to be very easy, but I think it can move us forward, you know, when a lot of people are evaluating FoundationDB for their use case, that one thing they want to write away is is it going to handle the workload. So, you know, I think this is an area where people can definitely get involved, whether it's the key value store or one of the layers, but with some benchmarking. And of course, you know, getting involved in something like a document layer, but also just simply interacting on the forums, right? Like, you may not feel like you know everything about FoundationDB. I don't know everything about FoundationDB, but participating on the forums will help you learn some more and we'll definitely move the community forward. So, okay, thanks everyone obviously for spending your Monday with us. I know a number of you, please feel free to come and introduce yourself to me. I'd be happy to answer whatever questions you might have as you find your own. Thanks so much.