 Thank you, Gabe. It's a pleasure to be here. Pleasure to actually be in a room of people for a change. That's a lot of fun. Thanks to the organizers, to Gabe and the whole team for just an opportunity to share a few words with you guys. Yeah, I'm going to give you a little bit of an overview on how to run what we call your favorite open source database, which is Postgres at Enterprise Scale. Thank you. I was looking for the clicker and appreciate it. Thank you. Good, OK. So just very briefly by me, I joined EDB just about a year ago. Prior to that, I worked in the industry for many, many years. I worked in UBS for a long, long time, done a whole bunch of roles in tech over that period of time, and then ended up in the database space, setting an open source agenda and introducing Postgres to my previous employer, and then building a kind of private and public cloud implementations of that database. I made lots of mistakes along the way, learned lots of things. Hopefully some things that we can share with you guys as we go through the course of the day. Who is EDB? EDB is Enterprise Database. The short version of EDB is we are, to Postgres, what Red Hat is to Linux. So we are the single largest contributor to the open source project, both from a code perspective, but also just from a community perspective. Our teams run Postgres user groups all over the world. We do lots of education events. Our goal in life is to expand the footprint of Postgres and for financial services companies to enable folks to do that at scale, to do that efficiently, reliably, and securely. So Postgres support is our business. That's what we do. We're the guys you call whenever things go bang in the middle of the night. We, in that pursuit of enabling kind of larger companies and financial services companies to run Postgres at true enterprise levels, we have a whole kind of ecosystem of tools, some open source, some proprietary that we can then deploy along with decades of expertise in Postgres to help you guys get to the next level. So the rise of open source software is pretty obvious. I think to everyone in this room, that's not something that's new. But what is perhaps interesting for you guys is what we've identified is we're pretty much at a tipping point right now where the usage of open source databases is just about superseding the use of kind of traditional, more traditional proprietary databases, which is very exciting for us as a Postgres provider. Postgres always comes out as kind of up in the top in terms of most wanted, most loved database. I think there's a number of different reasons for that. Cost is certainly one I think Dave mentioned it earlier on. Cost is one. Talent, attraction, and retention is another one. We see a lot of our customers. People are interested to kind of leverage some of the newer tech. You can guarantee that anyone that's just come out of college hasn't been developing on Oracle or Sci-Vice or DB2. They've been working on open source technology so that's almost second nature to folks. The other big thing that I think attracts people to Postgres is portability. So breaking that kind of vendor lock in, giving yourselves the flexibility to optimize your commercial agreement, optimize the level of technical expertise you get from a provider. And if you decide to switch from one to the other, it's largely a paper exercise which is significantly different if you're on a proprietary database and you wanna move somewhere you typically gonna impact your entire application estate and require lots of extra development work. So with that, while we all love Postgres and Postgres is great, spoiler alert, it's not that easy just to run vanilla Postgres at enterprise scale in financial services institutions. So we typically look at it from four angles. Reliability is key. So I can guarantee most folks in this room are gonna be running in multiple locations at once, multiple data centers, availability zones, probably cross region, you're gonna need some degree of high availability. So one of the things that's really important is make sure you understand what your SLAs are, make sure that you've got technical solutions to manage things like automated failover whenever things break. We have a whole bunch of tools. That's our business. We can talk about those offline. I won't bore you with the details just now. Performance, also critical. So I think there's a perception around Postgres that Postgres is just for development or low tier applications. I have run it very successfully for mission critical applications. But to do that, you need to understand the ecosystem that you're running your database in. You need to understand how to get the best out of your compute and storage infrastructure. So my advice there would be work with a partner who's willing to really understand your requirements and help you optimize that implementation. Scalability, again, my previous life, we ran an estate of around 15,000 databases. There is simply no way that you can deploy those manually and manage those manually. So orchestration and automation is absolutely critical. You need to be able to deploy these things repeatably, reliably. You don't wanna be in the situation where it worked in UAT and it doesn't work in prod and it's because the system administrator configured something different in the production instance. So really think about building automation, designing patterns that map to your SLAs, your recovery time objectives, et cetera, and then automate the hell out of those at the back end. That's the real key that we find for large scale deployments. Other thing sounds very obvious, but make sure you've got monitoring in place. You don't want your application teams to call you and say, hey, is my database down? You need to be ahead of that. You need to be proactive in that. You need to be in front of those things and making sure that you've got full visibility of your estate. So we talked about Log4J before. So we all were running around like headless chickens this time last year on Log4J. You need the ability to have a view across your estate and understand, okay, well, I'm running a version 1.1 on these 1,000 databases. I need to upgrade those to 1.5 or whatever it happens to be. So having those kind of tools that aren't automatically part of the open source stack is important. I think we find it's important to help our customers be able to operate at the scale that they would like to. Security, financial services, no big surprise. This is kind of front and center. Everything from encryption. So encryption in transit to encryption at rest. Those are critical. Data access is another key one. So understanding who's got access, having kind of control over your role based access control models, being granular about who gets to see data. So exposure data on a need to know basis. Those are things that we find kind of repeatedly that are very important to financial services institutions. And equally so, just on the right hand side, I listed a bunch of those. So for any of you guys that operate in multinational environments, I can guarantee you will have your own internal control framework, which is the amalgam of the multiple regulators that I'm sure you're facing off to. So things like strong authentication requirements, central identity management, backup and restore backup, integrity checking, disaster recovery checking, all of these types of things are key things that we understand. And again, if you wanna deploy an open source database at scale, those are the kind of things you need to be aware of. You need to be building a kind of holistic database solution. So I think that my lasting message for the day is, depending where you are on the Postgres journey, you're either beginning or you're running in dev and you wanna scale up into a production environment or you wanna move from lower tiered applications to mission critical applications, you probably have a multitude of questions. My overriding message is find a partner, find someone to work with who's done this before. So in my previous life, we thought we were super smart and thought we could build everything ourselves, which we did, but it took us a long, long time to do it. So if I was doing it over again, I would absolutely go and take a shortcut and find the partner who knows what they're doing. Find someone who's willing to look at your database solution as more than just a database engine. Look at it as understanding the holistic database solution. So how do you make your database available to your developers? How do you improve their agility by improving provisioning times, ease of deployment, et cetera? How do you integrate with your identity and access management systems? How do you get the best out of your compute stack? Make sure you've got backup and monitoring, obviously. Make sure you train your operations staff. I've fallen into that trap where we built the most shiniest, beautiful implementation. I think we had provisioning down to like four minutes from click of a button to running database, but we didn't train our operations staff well enough. So the problem was that something went bang in the night. Our ops guys didn't know the run books, they didn't know how to fix things, and as a result, our service got a bad reputation. So easily remediable. There's lots of companies who can help with training. We try to help with that stuff as well, of course, but that's a key one that isn't perhaps obvious, but something that we find very important. And then actually the last one, make sure you've got some kind of patching and upgrade framework. We are, as an industry, probably not well-renowned for keeping on top of our end of life of software versions. So that's something I always encourage customers to kind of build in from the beginning. So yeah, we are here all day. We are just in the hallway outside. If anybody's got any additional questions, I'd be more than happy to talk to you guys in a little bit or a lot more detail. But my message is we love Postgres. Postgres is the lifeblood of our company. We're trying to promote Postgres, but please get a partner, work with people who really know what they're doing to help you kind of move that forward and do that efficiently and safely. Thank you.