 Anyway, so the funny part is I get to start this off by saying hi, my name is Mitch and I'm a recovering Mongo master. So at least a couple of you laughed, that's good. So I didn't completely face plan on the punch line. I've been waiting two months to use that punch line. And now my wife is texting me, perfect timing. So yeah, let's get started. So this talk, well first about me, so I've been known for more than two decades as Space Monkey Online. I go way, way back in the Postgres community. I go way back before to this web server called NCSA, which we covered it with patches and then it was later named the Apache server. So I've been doing this for a lot longer than I probably look. I met Capital One, which is kind of interesting. I just spent like 30 years making fun of companies just like Capital One and now I'm in it. So now I get to walk the walk, right? That's actually what makes this such an interesting talk because I'm coming in, having spent five or six years, very active in the MongoDB community and having spent, I don't know, since 1994, December of 94, I believe, was when I said that's it. I'm gonna be start-ups and web only from here on out and here I am at Capital One. So I am walking into this with a pretty fresh perspective. I'm not someone who's been using nothing but Postgres for ten years and only working in a bank for ten years. I'm brand new to a bank and to this day, I'm like stymied by a lot of stuff that most folks take for granted and I still can't figure out cuz I'm just such a start-up or an open source type. Let's see, I've been starting companies, like I said, since December of 94. And I am what we call a polyglot programmer, right? Hence the title of the talk. A polyglot programmer is someone who prefers to carry a really, really big toolbox around and use the right tool for the job. Whereas a lot of programmers will master a particular language, be it Java or Python or whatnot. And then say, this hammer is awesome and every problem seems to be a nail, right? So I've been a big advocate of polyglotism from a technology standpoint. Yeah, and I do a bunch of strange things on the outside as well. I managed to turn into a football coach, which nobody would have guessed in a million years. And I will play a mean base and I also write, sorry? Both. I started class, I'm devolving just really quickly. I'm devolving as a musician. I started, I was born as a classical musician, and it's just gone backwards. Now it's like white noise with screaming on top. It's really curious. So this talk, what is this talk about? First off, let's talk real quickly about what this talk is not. This is going to be a challenge for me as a speaker. Because every talk I've given for probably 15 years always starts. And around 10 minutes or like slide eight or nine, I say, I'll screw it. Everybody want me to go to the command line and everybody goes, yeah. And this talk is just not one of those talks. So I'm gonna focus on what I've learned, both coming in as an open source contributor and as a start-up, and from being inside of a very large company, roughly 50,000 people, 6,000 of which are frantically writing codes. So we have a very large college dorm room of code and data to deal with. And that last line is absolutely true. There's some very good talks here specifically about DevOps and clustering in extreme scale. So please don't let my talk think that these other talks are not valuable. They're very valuable. The enterprise, wait, the enterprise, no wait. The enterprise, how do I start this? Let's go straight to the next slide. So how did we get into this mess, right? First, we started off in the glory years, right? When you went into a large business, that large business was basically completely bent on a particular type of technology or a technology stack, right? So you had companies that did nothing but write C code and they use site. I'm in New York, so I'm gonna say side base cuz everybody was using Transact SQL, right? It still do. So there are other companies that, but the farm, I actually, when I lived in Seattle, got sucked into the phone companies at Telco. So I know just how many billions of lines of code of cobalt they're stuck with. And I always, I'm kind of being glib when I put this slide together cuz it's kind of long enough ago that half of you probably don't remember being there. But ultimately, yeah, that's pretty much what enterprise computing used to be. It was a very safe, slow, predictable environment, right? Of course, the pay was terrible and you always had to work in the basement. But other than that, it wasn't bad. Speaking of the giving all your money to Oracle and IBM, they had to take a dig cuz this was a famous quote, right? Nobody got fired for giving money to IBM. But that same anonymous then got their budgets cut or they got laid off or they got downsized or they got moved to upstate Wisconsin. So, meanwhile, the interwebs happened. And what used to be a scale issue of, well, we have 200 concurrent users on the system. That turned into 200 million concurrent users on the system, right? It changed all of our problems. Another problem was the technology started moving extremely fast, right? We didn't just come up with new standards. We came up with new paradigms. We changed everything and it seemed like it was happening on a daily basis, right? People ask me, how do you keep up with all of this change, Mitch? And I laugh and say, every Monday, I'm a sophomore. I don't even know what my classes are gonna be this week. And that's just how it is. By Friday, I've spent all week killing myself, which back then was like 100 hours, building the most beautiful, sophisticated thing. And by the next Monday, some 13 year old from Pookeepsie had turned it into a button and now everybody has it, right? So the churn of this technology was really insane. The scale, of course, was a very big deal. And I struck out the word different there. Each new stack required a different set of skills. It wasn't a different set of skills. It was a whole new set of skills, right? Yeah, backward compatibility. I remember when that was a big deal, I don't even know, nowadays people even think about what backward compatibility means, right? And thank you, Google, but it became the new stable. The stacks started to evolve and go in their own discrete paths, right? The Java crowd was like really big on Hadoop. They also liked bigger databases and bigger libraries to access bigger databases. Meanwhile, I was over in PHP world and everybody just assumed that MySQL was the only, that was a database. It was the database. That was actually how I got involved in Postgres, because I basically was standing around a bunch of PHP guys saying, please, please, can we use a real database now? Ruby on Rails was the one that actually got Postgres right and they were big on active record, which I'm still kind of chewing on. Python Cloud kind of cracked me up. I remember dealing with Python, I got into Python very early on. I'm in the digital creations years. And I remember they had a database called the Zope Object Database, ZODB. And it was really cool because it was the only database to this day that I know of that will do acquisition. So you can store something called logo.png somewhere in your database. And when you look for it, the database will say, is the logo.png here? Nope, it'll back up a level. Is the logo.png here? Nope, and it'll back up all the way to the root of your database before it finds it. It was totally cool. It also needed a supercluster to support a simple corporate internet. And then go, which is where I've been living for probably a year and a half. Actually, no, I would say two, two and a half years, just not full time. And it's true, the go, the go way, databases are just databases. They get and set data. Do we need to choose? Meanwhile, we got cash flow, right? With web scale came challenges to solve your database issues, right? Some of the challenges were how you access the database. I remember SQL Relay. I don't even know if SQL Relay is still around. I was using it when I was at Viacom here in New York. And SQL Relay was this like evil, diabolical trick to fool your client into thinking that it was talking to a database server when it was really talking to a proxy. And then a proxy would turn around and decide where to send your queries to. It was neat, but it also segfaulted under heavy load. And when you're building a website for a bunch of teenage girls that go to MTV a lot, that's heavy load. Varnish and squid, I thought, was kind of a neat solution where you started caching your content at the edge. The problem is, web apps started becoming more and more sophisticated. And the ability to cache static content became less and less relevant when all of the content was dynamic. So why would you want to cache a bunch of stuff that says, hi, Mitch, here's your friends, and here's your profiles, and here's, well, that's Mitch's stuff. Why do we need to cache that when only Mitch is gonna need to see it, right? So we've seen problems come and go, and they tried to solve different problems. But of course, the GoPost kept moving, right? It's almost like dealing with scale issues and building apps for the web in particular. You looked up and you saw the GoPosts were here and you lowered your head and you started pushing and pushing and pushing. And then you look up and the GoPosts went that way and you're like, gosh, and you turn and you go this way. And then Monday comes and you start all over again. Elasticsearch is one of my favorite tools that I'm still using, same with Redis. And my beloved MongoDB, which actually serves a very good purpose. Now, I'm also one of the founders of the Joomla Content Management System. So, apologies. And so I'm coming to a database from a very content-specific view. So for me, looking at data as a JSON document, it's like putting a fish in water, right? So for me, a document database makes perfect sense. So for me, I ended up launching the first e-commerce website that used MongoDB, for example. And met a lot of the founders behind MongoDB early on and was a bit of a play thing for them and had a lot of fun. The most unpleasantly named Project Voldemort is actually one of the coolest key value stores I've ever worked with. It's Java-based and it must not be named. I guess, awful name for a project, huh? They did something even worse. Their architecture was brilliant and they gave it an even worse name. Their deal to solve scale problems in the event of failure, right? For resiliency, they called it a hash ring, which made me feel like I was doing business with drug lords from Afghanistan. Hash ring basically says, I'm gonna spread the load of my cluster around a ring. And what happens with normal database size clusters is that if node four goes down, for example, well now node three just doubled its load. And node five just doubled its load, they go two. And there goes node two and node six and then node one and node seven. And then boom, your whole cluster's gone, right? So the Voldemort team came up with a really smart idea of saying, hey, we're gonna spread the load across all of the members of that ring. So if node five goes down, all of the nodes share that load. So everybody gets a 10% increase and not a 200% increase, right? Another thing that that solves is, say you have a node that fails and you wanna bring it back online, well when it tries to bring itself consistent with all the other members of the cluster, you knock them down again, right? So that was actually a really smart approach. Now, we've talked about, it's kind of funny, my display got messed up in between so I don't know what's next. Yeah, DevOps, have any football fans here? Yeah, so you'll get this slide. DevOps? Anyway, so while we were at it, we started automating our deployments, right? Cloud happened. I don't know about you, but when the cloud first started, the hype was so bad that it was just like, really, seriously? And what we have now in 2016 is what they were selling to us back in 2004, right? Some of you remember, that's why you're laughing. It's absolutely true. They were like, just push a button and scales. Yeah, two weeks later, you're still fighting with config files. You can't even fire up a node. So now we actually have come out of the stone ages of cloud and we have far too many tools to figure out. I've actually been playing with Terraform lately and Cloud Formation. I'd like the two that I've been playing with the most. But at Capital One, for example, we're using all of these. Actually, all of these in different groups and some of these groups don't even know about the other groups that are using it. So we have all of these toys. Everything that I've mentioned in all of these slides are in use one place or another, and that's actually the gist of this whole talk. So how long can this go on, right? You've got all these different languages, and all these languages have started to pair up with different databases. And on top of that, you have all these different systems to get around the performance and scale issues of each one of these different tools and each one of these different stacks. On top of that, we have all these different tools to automate provisioning all of these things. Hence the college dorm room reference. Then this starts to happen, right? Someone inside of the company says, hey, our competitors are about to launch product XYZ. We have got to get this thing live, right? So now you've got pressure to put something new up. And of course, then you've got the front end hipster, right? This is one of my favorite slides because I used to be the front end hipster. And then he says, wait, I wasn't actually ready for that. I'll start. We need you to do this for us. And then he says, well, actually, we can't even figure out how to use this. So we need to put something else up. And he says, okay, let's just start all over again. And then the marketing guy says, hey, it's gotta be web scale. And you're like, web scale, really? Did you see that video? And then sales comes in and says, well, we just need to plug into a couple extra things. Not an extra work. We're not changing the scope of this project at all. You just need to plug in a couple things for us and you're sitting there looking at all this stuff going, yeah, all right. And then the executive team really lowers the boom. And I had this last sentence, because I actually quipped about this. You know what, I've done this about every two or three years, I'll tweet or blog post or something along the lines. And I say, you know what, rock stars destroy hotel rooms and overdose on drugs, typically dying at a young age. Ninjas sneak up in the dark and kill people. I don't want either on my team. Thank you very much. And then there's Postgres. The reason I'm saying this is because the thinking behind this talk was what happened to me when I started working at Capital One. My first question, which is comical, was who's using what? And I've been there seven months and I'm still answering this question, right? And a large organization, this kind of stuff, happens. Now, Capital One is unique in that when it chose to reinvent itself as a technology business from the inside out, and that's exactly what's happening at Capital One. It's a really beautiful thing to watch. It's a lot of fun to be there. I feel like Forrest Gump really do. I'm just standing on the street corner watching everything going. But when you take this approach, they did something that I thought was genius. I'm not smart enough to have thought of this on my own. They said, you know what, we don't know enough to say what standards we're gonna use. So just go, do, learn, and play. The good stuff will bubble to the top, the stuff that's not so good. We'll hire somebody or bring in a consultant or buy a book. We'll do something about it, we'll fix it. And so you really do have a hodgepodge of technology inside of this company. You'll have a group out in San Francisco, because the resources they have access to was all JavaScript, right? So they're Node, Angular, actually they're not even Angular anymore. They've moved on, they're doing a bunch of flex stuff. And of course, they're using Mongo on the database. But then here, for example, where headquarters is, you've got some of the old school folks who are heavy languages, heavy tools. So they're using Hadoop and Java, and some of them are using Postgres for their data. And then you have this gamut of, I hope I'm pronouncing that word right, the gamut of all these different types of tools and tech, all of the other stuff that I've rattled off. And I thought, okay, how am I gonna get all these cats to start running in the same direction? Cuz the thing it is, we got 6,000 engineers. That's 6,000 people sitting on 6,000 islands inventing something called a canoe. Why don't we find those who make the best canoes, and show everybody else, or have them make everybody else canoes, so they can go do something else like make huts, and Postgres ended up becoming an unlikely surprise enter into that thinking for me, mainly because of a couple different things that the latest generations of Postgres have brought out. So one of the things is getting access to all the things. And part of DB Link, which I think is interesting inside of an enterprise, is that what happens is you can actually use, it's doing it again, isn't it? No, you're taking pictures, you got a flash? Okay, yeah, it's interesting bridge, they're never done painting. When they're done, they start painting all over again. It's kind of an interesting deal there. But there was some subtext in that picture. But back on the talk, so DB Link makes it possible for you to say, this whole group of apps, this whole family from this, maybe it might be a division inside of your company, there might be a particular product team, or might be just an office full of developers who sit next to each other. Can all start accessing the same source of data, and that database in turn becomes a gateway to external systems. Now that doesn't mean you're gonna be able to run any and all types of commands on any of the databases through DB Link. That's not the point of DB Link. And this talk is not about to go into in depth about how DB Link works. It's more to suggest this is one of the ways that you can use Postgres to give a more unified access to data from different sources. One thing that we have to overcome as a challenge in a regulated industry is that we have data that we can't access, right? No humans are allowed. So we have to figure out how to run our code. So we write our code, and we test it against Lorem Ipsum. And it looks great, right? You've heard this phrase, I have works on my laptop. And then we go live with it, and the sixth customer to hit it and ask that funny character in their last name or some strange email address or something, and there goes my code. And now I'm learning in a very embarrassing public Ben Stiller-like way that I didn't test my code well enough. So finding ways to get access to this data for automated test and build so that we're not breaking any rules. But at the same time, we know that our tools not gonna get broken when it goes live is important. This is one of those tools that you can use to get access to that environment. Another thing is the JSON-B. I put JSON-B in autocorrect, fix it to JSON, which is actually kind of funny. I think JSON-B is probably one of the most important features Postgres has added in a real long time. And of course, I'm coming from MongoDB, so I'm a little biased. And I'm also not happy that they didn't just choose the BSon spec, cuz I need access to dates. I don't know about you, but dates are just kind of important to me for some strange reason. But as I was teased by the Python guys out front, you can always just use your next timestamps, right? It's not that big a deal, Mitch. You can put the paper back down now. JSON-B means that if you start your project, you're starting a project anew, and you know that you can have relational needs. And you're thinking about prototyping rapidly. Squeaking's making me nuts. If you know you're gonna be doing really rapid prototyping, and you're gonna have some unstructured data in there, JSON-B lets you have your cake and eat it, too. Now it used to be, and up until probably, actually, I'll say it. Up until about six months ago, I had my holy trinity of databases, Postgres, Mongo, and Redis. And it didn't matter what problems you threw at me. If I used one combination of these three, I knew I could solve just about anything that would happen. So, gremlins, that's my job at Capital One is being a gremlin, too. So I should have expected this. If you're starting a project, and it's all unstructured data, then I don't think this is a good idea. So this is, I'm looking at this through clear glasses and not rose-colored glasses, right? So again, my thinking with the JSON-B is you can start out with a relational data model, add a JSON column to your tables, or your table, wherever you're having this unstructured data, and start using it and working with it. If you get to a point to where you reach pain because either there's something lacking in JSON-B that you needed, right? JSON-B, for example, only supports strings, integers, bullions, and nulls. And I'm spoiled from the Mongo world. So I'm expecting dates and all this other stuff, right? So I was a little frustrated. The flip side of this is that there's a surprisingly high amount of really solid functionality hiding in JSON-B. I don't know if there's any talks about just JSON-B here. They should have if there weren't any, because I think that's the talking itself. It lets you store data as an embedded document inside of a row and you can reach into these documents. So okay, how many of you are familiar with JSON and what JSON looks like? Okay, so most of you will understand what I'm saying. So imagine that you have a document. I just lived in Italy for four years, so I'll call it gelato. You have a document called gelato. And in each gelato document, you have a flavors. And flavors could either be a string, chocolate, it could be an array, chocolate, vanilla, or it could be an embedded list of other documents, right? Now something that Mongo used to do, an only Mongo, which was something that I thought was like a killer feature, was that the query planner was smart enough that if you said, find me all gelato that have a flavor of chocolate, it could look in the documents that had a string set, it would look in the documents that had arrays, and it would look through documents that had documents in them. And it just transparently managed that and figured it out. JSON-B does that too. So it's a pretty, what I thought was like a super cool feature of MongoDB is actually available in JSON-B now. Let's see another one. Another one is that you can reach into and into and into a document, so to speak. So you might have a property called address, and in address you have another property called state, and or I don't know, locale, that might have an embedded property called state, and that might have an embedded property again called county or something like that. I'm just making stuff up. But you can index that property, that's JSON-B property, and search based on the values of that property, which is a big deal for me. So again, coming from a content management side of things, I'm looking at a bunch of data. Okay, here's another way of looking at it. It was the reason why I was able to just walk away from relational databases altogether for like five or six years was I stopped and I looked around and I realized every single major framework and toolkit for building web apps out there uses something called an ORM, Object Relational Mapper, and I thought, oh, maybe we're not using the right tool then. I don't wanna have to use an Object Relational Mapper. Maybe I should just stop using something that needs to map anyway. Cause I felt like in my language and in my framework and in my application logic, everything was a document or an object, but then I had to chop it up and then flatten it and then shove it into a bunch of different corners and then match them with a bunch of IDs and nobody but the computer cared about the IDs. So that just made things worse. So for me, being able to live in a document world was like, duh. And so for me, JSON-B is like a really big deal. I'm gonna hop back up on my squeaky stage and go to the next slide. Another thing, so how many people here have worked with HStore? One, okay, you should. HStore is basically a Postgres storage engine for key value. So if you need to store named things and you don't know what the thing is, but you know that it has a name and you're gonna need it later and you will always ask for it by name. Basically memcache, right? That's exactly what HStore can do. If you set it up right, and this is something I wanna validate myself, I'm being told that if you set an HStore table upright, you can actually get it to run faster than something like MongoDB that supposedly cheats and does everything possible to be as fast as it can be. So I really wanna know personally what that kind of scale could be. Now one of the systems that we're using inside of Capital One with pretty strong regularity is Kafka. And the reason being is because some of you probably heard the phrase big data, right? It's kind of like a marketing, yeah, I saw some chuckles good. It's kind of like marketing speak for just really big databases. In the finance world, that term is given away to something called fast data, which is kind of the modern problem version of big data. Instead of just accessing lots and lots of data, I need to access this data while it's changing fast in real time. Say a thousand things a second fast. So that's what fast data is. It's streaming, dealing with data streams. So databases now are starting to look at as more a place to collect information, transform it and do whatever analysis you wanna do on that data and then drop it and move on about you and do your day, right? So you have this like infinite transaction log in Kafka that's just boom, boom, boom, boom, boom, and it's just filling up with all of this data. It's not actually a database per se. You don't say, hey, Kafka, show me all of the users who bought a plunger yesterday on Amazon. But what you can do is you can say, I'm gonna build a job that replays every transaction in this whole log, get that data, plop it in a database somewhere. Postgres will be really good for that. And then chew up that data, do that analysis and then drop it and move on. And that's a real sweet spot for Postgres. NHStores is exactly one of those things. I'm gonna go to the next slide, but we're not actually there yet, funny enough. I wanted to bring one of the things, actually a couple of things. So with that shift of mentality, right? What's happening is the people on the application side of the fence don't care what engine we use. They don't care where the data is going. They just need somebody to take this data and get it out of their app because they gotta move on and do the next thing, right? And then you have the concept of, I have so much data coming in that I can't just hammer a database, right? And expect this one database to keep all of this stuff in sync. I have to have some kind of history of these changes as atomic things. And then I can go back out of band outside of real time and those real time constraints and chew this data up as a separate process. All of those things combined puts you in a situation where you can say, all right, everyone's gonna be running around and using different databases and different stacks. But if I have a sort of gateway where all of this data change is taking place, then I can consolidate what's running on the backside of this and keep this data in a consistent format or a consistent environment. Because another problem with this is that, and Capital One's really awesome in this regard. They've gone really, really gung-ho in the cloud technology, right? I think they were the first sizable finance company to say, that's it, we're all on AWS, we're doing it. And they're really serious about it. But you know what, you still have to have people inside the company who manage all these systems. Just because the servers aren't physically in your offices anymore doesn't mean they're not running somewhere, right? So if you have a fixed number of people who can babysit all of these systems, but you have an infinite number of different combinations of sizes and shapes and colors and forms that are gonna be babysat by this fixed number of people, you're just asking for trouble. So my approach here, and the reason why I offered to give this talk is based on the learning that I've had while I was there, Postgres is one of those really nice tools where you can try to consolidate that. In a sense, Postgres is gonna let you straddle defense between different types of database engines and not just say everyone has to use this tool, everyone has to use that tool, or continue just letting everybody run whatever they wanna run. So I'd like to ask for questions at this point. I kind of went fast through my slides because I was hoping, this is an interesting talk for me because usually the talks are very technically specific, and so 10 minutes into the talk, I'm always on the console and everybody's just watching me build stuff, right? And I become a plaything of the audience, which is fun, it's one of my favorite games. But this talk isn't really about that, it's more about strategy and experience. So I thought let's go to the questions faster than later. So is anybody here, yeah? Yeah, it's actually two things about that, and I'm glad you asked that question because I wanted to make those slides and forgot, which I always do. One is generally speaking, I remember it was pretty much 2005, 2006, being a polyglot programmer was like a cool thing. You wore it like a badge, right? And in 2016, people started to get tired of this, right? The churn. I won off this treadmill, right? I wanna deal, I'm tired of dealing with this mess. And there's a valid need inside of a large organization to say, hey, listen, we got thousands of engineers. Why are they all inventing this thing called a wheel separately? Why don't we put them together, let them work as a group, share that knowledge so that the really good ones can bring the not so good ones with them up to the next level, right? You can't get that extra value of scale, mass, if everyone's doing their own thing, right? Hiding off in their own little TP, yurts or whatever they're called now and doing their thing. Also, Capital One as a business, and I think I can share this, the philosophy of Capital One when it was born was a pure finance company, right? So it was kinda like a buy all the things type of business. And then one day they're like, you know what? I'm kinda tired of being addicted to somebody else. I wanna do this myself, right? And they became, they went from one extreme to the other, build all the things, right? And so you still have developers saying, look, I call it the wheel. And I think that a lot of companies that need to go through this process, so this is sort of learning, sort of evolution that happens, and then you get to a certain point where practicality takes over, and you're like, oh my god, if I have to make one more database class, I'm just gonna throw myself out of the window. Of course I'm only on the second floor, so it wouldn't hurt too bad, but anyway. Go with me. So you get really frustrated with dealing with this kind of, I keep saying churn because it really does feel like that. You feel like you're just running, running, running, and you get absolutely nowhere. So, and if you're, you know, you get to a certain point to where you have a 30% of your team is building stuff that you know you could be using. And actually, this is something that I'm really proud about. Capital One is super aggressive with their, not only with their adoption of open source internally, but their support of open source externally, and they actually have open sourced some of their own stuff. One of the first thing that they open sourced was, actually it's kinda cool, for college hackathons, it's called Nessie. So if you go to the public GitHub, it's called Nessie Israel is the org name. And it's basically an API system done in Node for hackathons. So whenever we would go to a college to do a hackathon, we'd say you can use the Nessie API framework. We got a data service up and running, just hammer it and build whatever kind of crazy prototypes you want. So I think they get it. Now there's some other companies out there that are still and build all the things mode, and they haven't had that moment, that aha moment of, you know what, this could be a toaster. I don't wanna know how this works, and I don't care, right? I just need it to burn my bread, thank you. So I think that moment of practicality needs to sit in before that pendulum can swing back. The important part about all this is that you gotta catch that pendulum before it keeps going all the way back to buy all the things, right? Cause some of us probably remember what it's like to live in a buy all the things world. It's not fun. Yes, another really good question. One I've brought up with some of the core contributors of Postgres. For me, one of my number, I've been saying this for a while now too. Maybe I need to just go on vacation and build it myself. But for me, one of the things that would be fantastic for Postgres, if I could just app, get, install Postgres, PSQL, my test DB, boom, I'm in. That would be the shizzle, right? But instead, it's app, get, install Postgres, okay, now I gotta edit a pgconf.file. Okay, now I got it, wait, I can't initial, oh, wait, okay, I gotta run this script first. An hour later, I'm still trying to set up a database. Of course, me personally, it's, cause I've done it a billion times. But to someone who's a developer, who's new to databases, and they just see a database as a place to store information and that's it. Actually, that brings up another really important point. Back in the enterprise years, when someone came to me and said, okay, we're starting a new project. It's called, you know, whatever. A couple of us would huddle over the corner and say, okay, we're gonna design the database first. What's it gonna be, right? And when you looked at your budget for a project, like 70% of the budget was back in. And today's world, 70% is design. There is no back end budget. Front end developers actually do everything from their console and that's it. So the approach of developing apps is completely different now. And so we discovered back then that putting all the logic in the database, which of course made Larry super happy, was perfect because in a practical way it was great, right? Because didn't matter how you access the database from whatever language, if you're calling the same stored procedures, you always get the same data. It's really consistent, but it couldn't scale. So we started pulling that logic out of the database so that it was just getting in setting for us and then suddenly we could scale everything, right? That was really my SQL kind of pioneered that by saying, forget data, we're just gonna be wicked fast, right? They're like, we're the AC Cobra of databases. There's no heater, we don't even have a roof, but man, we're fast. And Mongo basically did the same thing, right? You could just install Mongo, boom, you're in. So I think that one of the things that you can do is to try to automate that onboarding for developers as easy as possible so that when they start building an app, they don't spend two weeks configuring different drivers and all this other stuff just to make it work locally. Another thing is take advantage of Clown Toolkits that let you build your app with deployment and CI CD from the start so that for me, the process as a developer is, I write code, I commit my code, I get push, and then get says one minute, Mr. Pirtle, I'll be right back. And then it goes over and it fires up a container on AWS, it runs its test suite, it comes back, says all right, you passed, you're good. Happy green text in the Slack channel. Mitch just added something new. Updates the dev server, now everybody that wants to go look at the dev server to see what's happening, you can see that for me, it's like breathing. I don't even know how to teach this anymore, it's so natural for me. 10 years, I've been doing it this way. Yes, I really feel strongly that one of the main reasons why Mongo did so well was because when Mongo was getting started, it was really the only database where you could app get install Mongo, Mongo, whatever your database name is, and you're in, right? It was that simple onboarding process. There was zero friction. Now of course, nine months later when your app has been in production, you look back in your user collection, you're like, oh my God, there's 12 different kinds of user documents, right? And a team of six people spend all weekend fixing all this old data. That's when you're like, I shouldn't have done this. But generally speaking, I think that that was one of the things that made Mongo so quickly adopted was it was extremely fast. It promised the ability to do stuff and some it did really well and some it did not so well, but ultimately it promised sharding and a bunch of other things, right? I was talking with Bruce about sharding and he says, yeah, I think that sharding in Postgres is actually one of our killer features right now. A lot of people are taking advantage of it. What, the document, the no SQL stuff? I know, I used to be, I'm, yeah. I will, well, don't forget the buzz. We have kind of like a new mentality. There's like the weekly hotness, right? It depends on what you want out of a database, right? Because seriously, I feel like there's been a real big shift in what we expect out of a database. Because back in the old days, databases needed to be acid compliant. I want SQL 95, ANSI compliance, I want standards, I want all this other stuff. And again, that kind of type of control and power is great when you're behind the corporate firewall, when you're in front of the great unwashed masses and you're getting hammered with 2 million requests every five minutes, that's not gonna work. You gotta do something else. And when I was at Viacom, the solution there, because we had, it was a website for teenage girls. Very demanding crowd. And the video music awards were happening and that means 60 million page views in one week. And I remember going to the morning stand up saying this isn't gonna work, this isn't gonna work. Because one of the features of this website was the girls would friend each other. But there was a different kind of relationship level based on who was friending, who. If I friended you, that was one thing. If you friended me, that was something else. If we friended each other, oh, this is BFF time, okay? So this would happen and we would cash it for like an hour. Meanwhile, those two girls got into a huge spat in the cafeteria over lunch and unfriended each other and started saying some really mean things. Problem is, there's still BFFs on this website. Oops. And I'm like, guys, people are gonna die over our cash strategy, man. And my boss blesses his heart and he laughs and I remember his face to this day. He would, he'd sit in the corner, he'd shake his head and he'd say, man, we're not banking niche. This is not a banking app. It's all good, it's cool. And that was the only way we could make this, this type of approach of building a database where all of your logic, all the things that are controlled in the database could handle the load. And what ended up happening, which I didn't like taste of was we put these caches in front. Actually, it's the same thing I learned when I was at Yale, right? They started out as a rail shop. They had a Postgres database and they had Ruby on Rails around it. And what they ended up doing was layering and layering and layering until you were doing all kinds of stuff and none of it was actually touching the database for quite some time. They had completely written logic outside of the database to protect the database from the actual real-time demands of a website that has six million people going in at 11.59 every morning hammering that reload. Because they know they got approximately 45 seconds to add whatever they might want in their cart before it's gone. So, yeah, I think that there's a big difference in how people look in a database. It's the whole new generation thinks memcache with a persistent disk store is good. That's all I need. Yeah, well there's two things. One is, okay, actually there's three. And the first one is very specific. I'm inside of Capital One. So, data being there when it's supposed to be there and actually be correct, it's like a big deal in finance. If we wanna have the right to call ourselves a bank in the future, we need to have real databases and stuff. So, there's a lot of pressure. One thing I've been telling individuals that I've been talking with is that at Capital One, it used to be you needed a database. Oracle was the default. And if you wanted to use Postgres, you had to ask for permission. And it's kinda funny because now it's changed. Now the default is Postgres. And if you need to use Oracle, you have to justify the cost. So Postgres has reached a certain level of maturity and features and stability. I mean, cause that's something I remember back in the lamp years, cause you know, MySQL used to run circles around Postgres with web apps. Problem was that was when you were using MyISAM, right? When you turned on NODB and row-level locking and actually made a relational database out of it, it fall over with the tiniest bit of effort. And a lot of really high-profile websites had to switch from MySQL to Postgres just because. They're like, yeah, we know MySQL is fast, but when you turn on all the relational stuff and integrity stuff to make it reliable and secure, it can't handle the load. Meanwhile, Postgres, you could just hammer on it, hammer on it, hammer on it, like Rocky Balboa and Rocky One, right? And it just never went, it might go to one knee, but it isn't going all the way down and it sure as heck isn't gonna lose anything. So that's a big win. No, no, and that was one of the things I meant that maybe I should be clear. There are situations where you start using Postgres saying, okay, I can use the h-store stuff for key value and I can use JSON-B for my unstructured stuff and then get to a certain point and say, okay, I need to spin off this document stuff in Mongo proper because I need more features than what JSON-B can provide. I might need to spin off this key value store to totally different infrastructure. And while I'm at it, I'm just gonna migrate to some other platform that specifically solves this problem. You need to find that balance, right? There's somewhere in this application's lifespan is gonna be a line where you end up saying, okay, can I continue using, as you said, like a jack of all trades type of solution or am I gonna have to break out and bring in very specific tools to solve very specific problems? This is the world I've been living in, but I'm realizing that the vast majority of stuff I've done could have been done in this environment and would have saved me a heck of a lot of time in the market and would have been a lot easier to maintain in the long run once it goes into production because now I'm only worrying about a particular stack and not opt-in stacks, for example. Well, if you think about this, a lot of emerging tech, if they're smart, they'll answer the same questions the same way, regardless of whether it be a programming language or a framework or a database or a cache engine or distributed build engine or whatever. They basically say, listen, play with it, kick the tires and you're gonna, you'll see for yourself where this works for you and where this doesn't. And the only person that can decide how far on the dozen this puts you in your app is you, right? But I think that this is a mature enough tool that it's a pretty safe bet to say, I'm gonna start with a relational database. I'm gonna start with a relational database that's open source, free, has a vibrant community, great documentation and a lot of features. And if I get to point to where I need to spin up my own separate Mongo node or Redis or XYZ, thank you very much. Then I'll do it at that time. But we talk about premature optimization, right? This is that question. And I feel like maybe the KISS principle is the smart approach. Cause I feel like every time I veer from the KISS principle I find myself getting humiliated in the most gruesome fashion, right? And it's usually very public. So this is a very smart approach for me at least is to keep it simple. And that means fewer moving parts, simpler deploy scripts, right? Cause that's something else to consider. How are you gonna build an Ansible tower that has to support eight languages, five databases, three caches and a bunch of other hybrid weird stuff, right? Or you can do three languages, one database and one or two caches and you're done. Your deploy scripts can be like this or they can be like this. It's a pretty big difference. Yes. Are you talking about specifically inside of banking or inside of larger business or? No. Because for me it's not necessarily driven by expertise. A lot of times it's driven by practicality, right? She's the mother of all invention. And if you have a group over here who just happens to have a summer intern who's been doing nothing but react, well guess what? Your front ends are gonna be done and react. Doesn't mean it was a strategic decision. The CEO was asked what should we do and he's like let's just react. Each group might find themselves working in a totally different direction, right? I mean, cause Capital One's distributed, right? We got people all over the US. Actually we have people in the UK now too. So what resources are available is another question, right? And I've been asked that question about startups for years. So what tech should my startup be using, right? In the investment side, you get that, every single startup probably asks the same thing. So what should we do this in Java? Should we do this in Node? Should we do this in Rails? And I always tell them what access do you have to what talent, right? Saying we're gonna be the next awesome go shop and having nobody around you that knows how to use go is not a smart plan. So yeah, that's how I'd see that. Any other questions? No? Okay, cool. When I get to the next slide and then I'm done. Thank you all very much. You can email me with questions. You wanna hammer me or ask me on Twitter and say, oh, that's talk sucked. Go ahead. I'm growing up, I can handle that. But yeah, it was a pleasure to talk and I hope you find this useful. Thank you.