The Changelog: Software Development, Open Source - Just Postgres (Interview)

Episode Date: January 20, 2023

This week we're talking about by Postgres with Craig Kerstiens, Chief Product Officer at Crunchy Data, and a well known ambassador for Postgres. Just Postgres. That's what this week's show is about.

Uh-oh, wrong track. Yes, that's more like it. Hey, it is not Monday, it is Friday, and this is the Change Log. And this week we're joined by Craig Kirsteins. Craig is the Chief Product Officer at Crunchy Data and a well-known ambassador for Postgres at large. So the title says it all, just Postgres. That's what today's show is about.

Huge thank you to our friends and our partners at Fastly and Fly. Our podcasts are fast to download globally because, hey, Fastly is fast globally. Check them out at Fastly.com. And our friends at Fly let you put your app and your database closer to your users all over the world. No apps required. Check them out at fly.io. Our friends at Sentry help teams build better software faster.

And you can try for yourself today at sentry.io slash demo slash sandbox. Try a live demo of Sentry right now. No talking to a salesperson. Just give it a try. It is a fully functional version of Sentry that you can poke at. And best of all, our listeners get the team plan for free for three months. Head to Sentry.io and use the code changelog when you sign up. Again, Sentry.io or head to Sentry.io slash demo slash sandbox. Well, Craig, last time we had you on the changelog, we were talking about what's so exciting about Postgres. And you and I both are excited by Postgres, but mostly about how stable and boring and reliable it is.

That being said, lots of people, I would say today, even more excited about Postgres. We had Nikita from Neon on the show, and he pointed out that of the top five databases on DB Engine's rankings, it's like the only one that's growing amongst the top five. So there's people that are using it more and more, getting more excited maybe about how boring it is. I don't know. What are your thoughts on Postgres of late adoption, interest, and what's been going on? Yeah, I think it's, I mean, that's spot on.

I love to usually reference Hacker News, who's hiring. So there's one site where you can chart who's hiring for some various technologies on Hacker News. And when you chart all the databases, Postgres is just like a runaway. It's like Postgres number one, then Mongo number two, and then the others. When you chart it over time, what's interesting is I think Postgres teeters back and forth between the number four and number five technology. And that's including things like, oh, JavaScript. I'm like, how in the top five language and technologies that people are hiring for? And I think most of us read Hacker News,

it's not the end-all be-all perfect indicator of technology, but it's a reasonable place of where things are headed, right? And so Joe Hellerstein wrote a book that was a tribute to Michael Stonebraker, who created Postgres. And he did a lot of research on, you know, like the work that Stonebraker put in and the origins of it. It's a great, I think you can go find it. I'll dig it up after and we can link it in the show notes. It's a great like 20 page PDF free book that's really great on the history and the origin of Postgres. And Joe Hellerstein, who's a professor at UC Berkeley, teaches databases there, did a lot of research on like, well, when did Postgres get popular? And like a lot of signs

pointed to Heroku and what we did way, way, way back. And so I was lucky to be there in those early days, right? I think we were lucky to pick Postgres, but it was a good decision and the right decision. It changed a lot of that trajectory, but since then, I think there's, you know, now there's no looking back. Everyone wants to do something with Postgres and be there. It's just a great database. It just works and it keeps getting better. And I think we're, you know, we talked a couple of years ago. It's like, oh, we're at peak Postgres maybe. It's like, no, two years later now we're at peak Postgres and maybe we'll talk to another too and it stays on that trend. Yeah.

Can you recall what made you choose or consider Postgres back in the Heroku day whenever you made that choice, that fortunate choice? I've heard a couple of mixed stories. And I think we tracked it down to the correct one. There was one SRE ops engineer that said, like, well i i heard it has a pretty good track record like it seems like it has a pretty good security story let's go with it and some other folks had used it and it seemed good it was pretty inconsequential it wasn't like we did this great business SWAT analogy right rds didn't even exist back then right so it wasn't like a

oh well if rds existed we would have just wrapped that and given customers that. But it didn't exist, and we had all these Rails developers asking for a database and thought, how hard could this be? Turns out it was a lot more work than we expected. But it was a pretty inconsequential yeah, it has a good track record for security. It doesn't corrupt data. All right, let's go with it. How do you think Heroku had an impact on Postgres over time? I know that the team got more formalized overwise. I know a lot of your career was built in Postgres and Heroku then. What do you think Heroku did for Postgres just as much as Postgres did for Heroku?

I mean, I had the email somewhere from the GM of RDS saying, you're the reason we shipped. We kept getting requests from RDS customers for Postgres. Heroku was the reason we shipped. Like, we kept getting requests from RDS customers for Postgres. Heroku was the reason RDS added support. And it was a couple of years after they wanted to. I mean, I should have, I don't know if I can dig that email up. I don't know that it's public to share, but like, you know, I think Heroku have put it on the map.

And then once it was RDS, it just cascaded. I mean, you two have used Heroku. Like, you've used Postgres. Like, how did you guys come to Postgres? have used Heroku. Yeah. You've used Postgres. How did you guys come to Postgres? Pretty much Heroku. So I was on Ruby on Rails, and the default database in test mode was, and probably still is, SQLite.

And the default database in prod back then was MySQL. And so I was a MySQL user, and I never really had problems with it, but I read a lot of blog posts that would point out it's data corruption things, or maybe it's not corruption, but coalescing, what's the word? Sometimes it would be too lax, and it would take things,

and instead of reporting, it would just turn it into something else, and you wouldn't find out until much later. And that always scared me a little bit. I don't think I ever actually got bit by it myself. And so I was a relatively happy MySQL user, but I was a happier Heroku user. And I saw the happy path on Heroku was Postgres. And the nice thing about Rails, even though I kind of decry this whole idea of like, you can just swap out your database thing, but especially when you're first getting started,

you really could pretty much just change the adapter as long as you're putting all your logic in your Rails code and not at your database layer, which I don't necessarily advocate for, but I was doing. It was pretty easy just to switch. And so when Heroku had Postgres, I just switched to Postgres and I started using it and I just liked it a lot. In fact, I never went back. I never had a reason to. And so that was my switching story. Yeah, I think it's a lot of folks. Like the popularity of Rails that Heroku made it the default. The Python and Django community kind of always recommended Postgres.

I don't know why. They just did. So I think like those two communities really, really helped to give the rise to it. You know, back in Heroku days, we also did a lot of investment on the JSON stuff and JSONB stuff and wrote some big checks for community development. I feel like before people were talking about sustainability and funding of open source that we thought it was important to improve the developer experience of it. And that was at a time where Postgres was good and stable, but it wasn't cool and sexy and user-friendly. I don't know. Can database's be sexy?

I don't know if they can. I don't know. But Heroku did a lot to advance that, and the rest is history. Now we're still kind of riding some of those great investments in JSON and other pieces. For those that don't go and read the PDF book you mentioned earlier, The Origins of, what's the origin story of Postgres? How did it become? What was the origin story of Postgres? Like why, how did it become, what was the landscape around that time?

Can you recall? So this, man, I've got to see how accurate I can get it. Postgres, you know, its name is Post Ingress. Ingress was one of the first two databases way back. So if you look at all major databases, they're one of two routes, right? So it's either like SQL Server. I forget if SQL Server has a base of,

hey, this came from that Postgres ingress route. I think so. I think SQL Server has an ingress base. Oracle does not. But it's kind of like you look at major databases and they're one of two routes. DB2, I believe, was ingress based. So its name came from Post ingress. At the time when it was first

released, it didn't have SQL support. That got added back a few years later and was this big deal. And they changed the name to PostgreSQL, which is now still lamented as one of the worst decisions they've ever made because no one knows how to pronounce it or spell it. It's like, how do you capitalize the SQL? Is it Postgre SQL? I joke with the community developers that I'm just going to call it Postgre until they change the name, and it drives people crazy. But I keep trying to see if it'll take off. Or you could just say Postgres. Yeah, exactly.

It's like just Postgres, just Postgres. Just skip it all together, the Q and the L, I guess. But it came out of UC Berkeley, and one of the core ideas that at the time was like heresy was this extensibility of a database. And now we see Postgres extensions like wildfire. But that was a core idea and philosophy that I don't see in any other databases that I only see in Postgres. But yeah, it was open source out of UC Berkeley. And it kind of was just there and good and worked for a while. And then fast forward 20, 25 years and it's really taken off, but it was just kind of a there good out of academia

thing for a long time. Are you involved in the core team at all or the core development or the steering of anything around that? Or are you just sort of ancillary to the Postgres world? Much more. I mean, a lot of them are friends a lot of them i'll have beers with hang out with so have over at my house for dinner so a lot of good friends there you barbecue right i've heard you talking about barbecue on on twitter quite a bit yeah yeah i have some opinions i mean i'm out in california so we don't most people out here don't know what uh barbecue is they're like hey i'm having a barbecue they're like show up at five o'clock and i'll fire up the grill i'm like, I'm having a barbecue. They're like, show up at five o'clock

and I'll fire up the grill. I'm like, you're not having a barbecue. Like, what are you talking about? We're cooking on the barbecue. I'm like, oh, so sorry. We can just just be the barbecue episode. I got I got an hour of that in me. We'll have to come back.

Actually, we should have you on backstage because we could talk barbecue. I would talk barbecue with you. That sounds legit barbecue. I live in Texas, so I got it down here. I would talk barbecue with you. That sounds fun. Legit barbecue. I live in Texas, so I got it down here. I would eat barbecue with you guys all day. I'm not sure how long I can talk it, but I can eat it. You can hang out while we cook, Jared.

I like that. We'll make you hungry by the end, yeah. Yeah, for sure. Where were we right before this? Well, you were saying you have barbecue with some of the core team. Oh, yeah, core development. Yeah, so I know those folks well. But, no, I'm not a C

developer. I've never contributed a line of code to Postgres itself. You know, I feel weird claiming any part of being, you know, part of the community, though I do a lot of content, engage with it. You know, I've run Postgres conferences before. So I've done things, but I do not contribute or commit code to Postgres at any level. So I can't claim any credit there. There's an amazing set of developers distributed around the world that really do the lion's share there. Yeah, well, when I think Postgres, I think your name. I think Craig. So I'd synonymize you, if that's the word, with Postgres.

To me, that's something you seem very passionate about, very excited about. Obviously, you're Crunchy Data now. Continue to work on Postgres in the many ways you do. So that's what I think of, at least. I think of you. I think of Postgres. Cool, thanks. Yeah, I mean, I've spent a good bit of my career on it.

I think I like DevTools in general as much as anything. Like, I think about, you know, that Heroku experience. I didn't join Heroku to focus on Postgres. I joined Heroku to launch their Python support and ran a whole bunch of other teams there. But the Postgres team pulled me in, and I kind of stuck for a little while. So I'm not going anywhere from Crunchy Data,

running Crunchy Bridge anytime soon. We've got a goal and a mission there. But I do hope at the next thing, I'll take a little break from databases and get back to that DevTools. But for now, it's still a thing that feels like there's unfinished business of creating an amazing developer experience for postgres well there's always dev tools around

postgres which i know you know of because that's kind of one of your focuses there at crunchy data is improving the dev experience of using postgres as the as the database you use so keep doing that around that at least if if not databases directly. Yeah, there was a big aha moment to me, I don't know if this was a year or two ago, where it's a good time to be a developer, right? And you can go to college for interior design, go to a boot camp, and then get a job as a software engineer. A good job, well-paying, hopefully it's interesting work, right? And you've got to go to a six-week or a three-month or six-month boot camp.

But there's this weird hole where the number of DBAs in the world is not really increasing. The number of people that are experts at databases, like it's not... There's more app developers in the world by a huge margin than there were two years ago. And then there were 10 years ago. And it's easier to become an application developer, but DBAs, I don't know where you go to become a DBA. There's no boot camps for that. So we're at an interesting inflection point where, as an app developer, it's probably your ratio of access to a DBA is less and less and less. So we're going to be looking for more services and

providers and tools to bridge that gap, right? I guess, pardon the crunchy bridge pun there, but it's that idea, that gap of how do we close that gap, right? It's super near and dear to my heart because I think of myself as more of a developer than a Postgres person, but also I can look at an explained plan and understand it. And I don't know if the average developer can, and you don't want to be dealing with your database, right? You want to focus on like, hey, I'm launching this new feature for customers. And yeah, I need to put data in there and I want it to stay and I want it to be retrieved fast. But I don't see either of you probably volunteer and be like, hey, I want to go write some SQL today.

It's going to be a great day, right? Probably not. No. probably not no and i think the longer i do this work the less patience i have for all of the periphery which i would consider like back-end storage to be like implementation details about that i must know and understand in order to accomplish what i actually want to accomplish which was for me you know almost two decades ago now the big big selling point of Ruby on Rails where it was like, look, all these decisions have been made for you.

Follow the conventions. Here's the happy path. Focus on what makes your app distinct. And that was a really big idea and delivered in a few ways for that. And we've been, in some sense, building from there ever since. In another sense,

having to rediscover that idea in different little ecosystems as application developers. But I do like Postgres mostly because I don't have to think about it very often once we're up and running. And that's really what I want from a data store. Now, there are other things that I want from it from time to time. But that's the big one for me. Yeah, I think it's a lot of people out there. And at some level, we were on that path with database innovation for a while, and it

kind of stalled out. I don't feel like there's been massive for a few years, there are massive innovation in that space. It was, you know, a major cloud provider would say install Postgres, and you're welcome. It's like, wait, but you didn't tell me how to use it. Like, that's still my job, right? We kind of paused and regressed a little, because Postgres is you're welcome. It's like, wait, but you didn't tell me how to use it. Like, that's still my job, right? We kind of paused and regressed a little because Postgres is a great database, but you still need just a little bit of that coaching, training, education type thing, right? And so it feels like we're picking back up there. I mean, Crunchy's focused on that. There's a few others, Supabase, Neon, others. I think what PlanetScale is doing is really exciting for the database space and everyone kind of has their own different approach like we're kind of having a renaissance and these things ebb and flow but how do we just make it a great

developer experience i think we stalled there for a little while so we're kind of picking back up from from uh leveling off there for a few years what What do you think caused the stall? Was it just, you know, shiny objects elsewhere or was it negligence? No sequel? There's a few pieces. You know, one, I think, so Postgres, jumping way back, right? We talked kind of about that origin of Postgres and one area, that origin of Postgres out of UC Berkeley and why Postgres is used all over and people don't realize it. Redshift was par Excel, which was Postgres.

So you take Postgres and you fork it. If you were building a data warehouse company 15 and 20 years ago, what you would do is you would start with Postgres. You would fork it and then you would go and make it MVP, like multi-parallel. And then you start to build in data warehousing features compression column restores those sort of things so you look at like green plum astrodata netiza like there's a laundry list of look at every data warehouse almost for the past 15 20 years and there was postgres at the core and so that's great then postgres kind of continued to rise and when you look at it there's other

people that are like, okay, Postgres is good, but we need more. We need to add on our special sauce. I think the major cloud providers started doing this first. Like you look at every major cloud provider and they have their flavor of, you know, air quotes, Postgres compatible thing. And I don't have a lot of love lost for them because it's not Postgres compatible. There is no spec for Postgres compatible. There is no, here is the doc. And't have a lot of love lost for them because it's not Postgres compatible. There is no spec for Postgres compatible. There is no here is the doc. And I have conversations with people every week where they're like, well, they told me it was Postgres compatible. And I migrated to it.

And six months in, I tried to do this thing. And they're like, well, no, that's in Postgres. What does compatibility mean then? And so I think we push these boundaries on like, hey, here's this shiny special thing. And it stalled us out a little bit. They're like, oh, now like Postgres, you know, hey, I'm going to take this, lock it in proprietary.

And that's what it is. And there was kind of this, it feels to me like there's this regression back to just Postgres. And like, actually, I just want this thing that is truly open source, that I know what it is. Like, I don't want this, like, no one's running a Ruby on Rails, like, massive fork that some consultancy, like,

shipped for 3x performance improvement, right? Like, why did we do that with databases? And so now we're seeing these things that were closed source and proprietary. Companies start to take a shot of creating open source versions of them, right? You look at PlanetScale, it's essentially Vitesse. You look at Neon, it is a open source version of Aurora. And those type of things take five to 10 years to mature.

Like a database, it's well regarded that a database typically takes 10 years to mature. Starting off with a Postgres base, you cut that in half. That's why most people started a data warehouse thing off that Postgres format. So I think we had it with a data warehousing phase, like it was Greenplum, AstroData, and Atiza. And then it's like, man, this is expensive.

This takes five years to build a business and a company. We don't want to do that. We can go and do a food delivery service in six months, and that's a lot easier. But then we had a drought of them. So I think people are taking another shot. I guess I'm the old curmudgeon that I'm just like, just Postgres. Like, guess what?

It's really good and just works. And I don't know a lot of people doing that. I see people now coming back to extending Postgres. So I think we're going to have exciting things come out of it. But I think for every five we have, like one or two survives, like you don't have to look at the long term picture of you to see that. So I'm a little bit on the curmudgeonly the I call like, you know, Postgres, Rails, or Django and like tailwind my like, you know, get stuff done, make money stack, Like I just want to build a business. I feel pretty good with that still. Yeah. In five years, that's a,

I just want to build products and ship them and build a business. Okay. So presents as Postgres, Postgres compatible, not really Postgres, correct? Yeah. There's a lot of that out there. Yes. Yeah. Are you generally down on that? I don't want you to stomp on companies and hard work because there's people out there doing things that are innovating and maybe it's just not something you value, but how do you feel about that world specifically, the compatible that presents us? I mean, I've worked at Citus, right? Running product there.

And it's an extension to Postgres. So it still hooks in, but it does crazy things with the planner, right? I'm not down on it, but it's not my go-to. And when I see that, it's like, what problem are you solving that existed in Postgres? And I mean, I've had people migrate over from one of those, you know, cloud Postgres compatible things that was supposed to be magic and cut their costs in half. And they were like, but this cloud provider told me this. So I've kind of seen it that the cloud providers went there first.

And now we've got some startups doing it. I think some are going to emerge with very interesting things. I think some aren't going to be around in five years. Now, which one am I going to pick? I'm going to pick open source Postgres because the track record is pretty... I think it's going to be around in five years, like knock on wood.

But I'm definitely excited for... People are talking about databases now, and I don't think they'd be talking about databases if it weren't for all these presents like Postgres, these Postgres-like things. Some kudos to PlanetScale. I take different views on there's technical decisions, but constraints are important and valuable,

and I wouldn't want a database without them. And we had them in sharded distributed situs in Postgres, so I think they can work. But I have a lot of friends over there, so I have contrasting views, but what they've done for excitement for databases is awesome. And, you know, most people aren't like, Craig, let's talk about this reliable database that doesn't lose your database and just has the functions I want. Let's talk about Postgres. It's

like, most people are like, yeah, I just want, you know, Jared, to your point, I want my database to work. Like, I don't want to think about it about it. Why do I need to talk about it or think about it? It just should work. It's a stalwart of that. This episode is brought to you by our friends at Postman. Postman is an API platform for building and using APIs. They are most known for API testing, and you may already use them, but they've built a full-featured API platform to help developers along each step of the API lifecycle. But what does it mean for Postman to be an API platform to help developers along each step of the API life cycle. But what does

it mean for Postman to be an API platform? Well, from API design, testing, monitoring, documentation, mocking, to the sharing and discoverability of APIs, they've built a full suite of tools to help teams build APIs together faster. Over 20 million developers use Postman to deliver their APIs. Plus they have a generous free tier. Start designing, developing, and testing APIs. Organize all your API development into workspaces and share those workspaces with other developers. You can create public workspaces to collaborate with the world's developers. You can back up your work to Postman's cloud.

You get their core tooling and collaboration for up to three users. Sign up and start using Postman for free today at postman.com slash changelogpod. Or for our listeners already using Postman, we encourage you to explore the entire API platform that Postman has to offer. Again, postman.com slash changelogpod. so when you talk about building things that are you know presents as or compatible it brings me back to the point that you made about the extensions so there's lots of different ways that you can extend postgres and change the way that it works. And it is amazing how many extensions there are. I was

just reading there was a post and Postgres Weekly of like what happened in Postgres land in 2022. And they went through and just listed out like, here's some extensions that were born this year. And there was like 18 of them all doing different things. And that probably was not a comprehensive list. I'm sure some were missed. Yeah, I'm sure there's plenty that were missed, but the point still stands. It was an overwhelmingly long list for just like,

well, here's the new things. Cause that's not like new versions of old things. That's brand new things that happened just this last year. And we can talk about an extension ecosystem. I think I would like to talk about that, but in light of this changing Postgres, then you also have like backend storage changes. Like you can change the way it's storing the data, correct? Like that's kind of what Neon is up to. And then there's foreign data wrappers. It's not like there's a lot of them, maybe these things overlap,

but it's not like there's a lot of these different like modularity points or extension points. And some are more like changing Postgres than others. Can you give an understanding of like the different ways you interact with it to extend or to change how it works? Which ones are totally like straight line, safe, open source path? And like when you start getting into hairy territory, like should I swap out my back end or not? Help people understand like that whole deal. Yeah, so there's a few pieces, right? So today, most extensions are C extensions or maybe Rust,

but need to kind of be built against the instance that you're running on. And so, you know, a lot of people show up excited about extensions and they're like, hey, I want to do this on RDS. And it's like, nope, like here is the whitelisted available set of extensions, right? So for at least the next midterm, like there's some thoughts on how to make this, you know, extensions more extensible, where it's like, oh, you could bring your own, right?

But we're a little ways off from that. But I think we'll wake up in a world in a couple of years, we'll talk in two years, and like there'll be an app store of extensions possibly, right? Which just blows my mind of what you could do with Postgres. And I'm a huge fan of extensions. We've had some customers show up and be like, I want this extension, but I don't see it listed.

And I'm like, cool, give me a week and we'll have support for it. So extensions are the easiest way to advance Postgres. Under the covers, there's deep, low-level hooks that gets exposed in Postgres. So it's not like you can go randomly change a thing in Postgres without that hook being there. But what's happened, extensions have been there for a number of years, and what's happened is, as we've gone over 10 years,

bit by bit, more hooks, more hooks, more hooks. Citus, at the start of Citus, there wasn't every hook that was needed to do that low-level sharding. Plugable storage came in about two years ago, and everyone was excited about it. Like, great, we're going to have all these different storage backends, like Neon's doing.

These things take time and move slow. There's been two or three different pluggable storage engines that came and kind of are there, and no changes to them in 12 months came and kind of are there and you know no changes to them in 12 months and kind of bit rotted and so it's a changing the storage layer is a large effort like that's a non-trivial effort a extension that is i want an email data type right like that's one of those things that i've thought about for for years we talked about it way back at heroku like why isn't there an email data type that could validate emails?

Right. Like, how do you know if it's valid, right? Like, is a plus okay or a dot? What's the answer, Craig? Why isn't there an email data type? Apparently, the spec for what is a valid email is way more complicated than you would ever think. We thought about writing it, and I was like,

whoa, this is actually, yeah, pluggable storage seems easier than that, maybe. I believe that, actually. Someone looked at the spec and was like, ha ha, that's funny. Well, I actually wrote, I penned a post years ago after years and years of trying to do the best of reg X, you know, to get all email, to have every edge case accounted for. And my post was, there's only one way to validate an email address. And the, the way to do it is you send them an email and you make them click on a thing because there's no actual other way to.

I mean, it's just darn near impossible. It's like Turing or what's it called? NP hard. I don't know. It's ridiculous. Yeah, no, it was funny because like this logically in my simple brain, this makes sense. And then it's like you start to drill into how it actually works. So, you know, foreign data wrappers are an interesting one.

They're kind of their type of extension, but a special class that lets you connect from Postgres to something else. So Postgres is like the front end, but the back end is like could be like an Excel spreadsheet or something crazy. Like the actual place that the data is stored could be anything. I use the Redis one every so often. Like, hey, I just want to join data from Redis to Postgres and it works. There's not an easy way to say, hey, here's how one is safer or, you know, more risky. So if you look at it as a basic data type or some

lookup or some function, right, that's definitely lighter weight, simpler, easier, like safer. If it's doing things to the query planner, that's kind of next level, right? Citus does this. Timescale does this, right? Hey, we're going to rewrite this query and take different paths. Citus and Timescale, I don't know if they play well together. It's been a common, common question for years. And it's like, we both take pretty invasive hooks. Back when I was at Citus, it's like, maybe, fingers crossed, probably not, right? Because of some of the hooks, like which one do you put first? And which one takes priority? And how does that step on toes, right?

When you're changing how code works and say, I'm going to do this instead of that. And then another thing does the same thing. It's a little riskier, right? Not to say you can't run with one of them, but you're starting to change. And it's a little less pure Postgres, right? And you're relying then on that extension developer to say, yeah, our code is as tested and is rigorous and as solid as Postgres code itself, which some are, some it's Wild West.

And then when you get down to the storage engine, that's just next level. So I think that's a little bit of a framework of, you know, and I love the small ones. We were about to add support for one, HypoPG, which is hypothetical indexes. What would happen if I add this index to my database? You want to know the impact on queries ahead of time? Would this work?

Is it a composite index or like you can just add the index, but how do you simulate production on prod and staging and all like all those hard things that we deal with every day in software what if postgres can just hypothetically say yeah this would improve things yeah it's interesting yeah i've always used like the minus small ones i think the the most i guess i would guess lines of code sized extension i've ever used was the post gis where it's like adding the geospatial queries. And it worked as advertised. It ended up being a maintenance burden when it came to like upgrading Postgres and like data stuff.

I ran into troubles because I am very much not a DBA. I'm an application developer who does what he needs to do to keep the site running, you know, and make the queries fast. That one was, it got to be where it was more work than i think was worth it just because of my lack of touch i don't want to necessarily you know harp on the the devs of that particular i think it's a pretty popular extension isn't it the gis stuff massive it's um one of the most popular ones yeah people think of them as the same ecosystem and it's interesting because like you know the post gis folks know the postgres core folks really well and vice versa

but they're kind of two parallel ecosystems like they they interact and talk together but like post gis is its own thing and its own core developers and committers and and it's it's massive it is easily the most advanced massive massive, you know, extension that exists for Postgres. And it definitely had some bumpy years around upgrades. Like I lived through some of those. It's gotten a lot better, but it's its whole own massive ecosystem and a great example of a, you know, huge kind of value. It makes Postgres with PostGIS like the most advanced open source geospatial database. And it might be the most advanced, right?

I think it beats out Oracle. You might could argue like Esri has some stuff that's like very enterprise proprietary. But you look for open source or relational database core kind of geospatial and it pushes it really to that extreme. Is there any opportunities in the extension space to like build a business around postgres i i mean uh situs was acquired by microsoft there's one you know time scale building a big business i don't neon i'm not sure how much it's a pure extension versus i believe it's actually more of kind of forking away and tweaking the storage engine i'd have to go and check it's two.

It's both. We talked with them. It was both. Yeah. I got to pull up here. Oh, actually, I was thinking about that. Something Nikita said. He actually said they're stock-ish.

Are you running a Forka Postgres or is it stock Postgres? So it's stock-ish. I guess it's stock Postgres with a caveat. So what's the caveat? Well, we have to change Postgres in a very surgical matter and specifically where Postgres reads a page from disk. Instead, it needs to read a page from our remote storage by making an RPC call. And when a Postgres writes into disk and sends what is called a wall record, write ahead log record, instead of writing to disk, it needs to send it over the network into our service, into our multi-tenant service. Those changes are not huge, but they're there. We've split those changes into five separate patches that we are submitting upstream.

They have not been accepted yet, but we are working with the community for it to all get upstream. Are you Postgres or are you not Postgres? Because we're stockish and they layer on some of their own extensions internally that they want to go upstream and they've committed

but have not been accepted upstream yet. Yeah, I mean I can have some drinks with them. We can debate how stock is or not. I think they are. They have some core developers and they are working. And so of the people doing that sort of stuff I think they have a good shot of getting it upstream.

But it may not. So the reason they're not stock is they later on... I think some of the big clouds have come in before and been like, hey, we want to commit this to Postgres. And that's not how open source development works. You can't show up and say, I have my way of doing thing, add this. You build credibility from the ground up from, hey, how about the testing and the bug reports and fixing bugs before you say,

here's how I want to change Rails to run on Python. Like what? No. And so I have some good faith that I think they're doing that. But yeah, it's a little bit of patience to actually kind of get to that point. But Timescale and Cite is your two great examples that were on vanilla Postgres and pure extensions. And I think there's opportunities for more. I think we're going to continue to see it.

You know, Postgres doesn't have a great doesn't have a great graphing vector capability. That's an interesting one where it's got time series. It's got time series in native Postgres and timescale. Sharding, you can do with the Postgres FTW natively, or you could do it in Citus with an extension. It doesn't have an amazing graph story. So that's the one area I could see right off more columnar stuff, like columnar compression is great. Instead of kind of a row based kind of sorting, it's columnar, you get good storage compression for certain workloads, really, really amazing when the data warehousing kind of stuff comes in, or you know, you've got a lot of time series data, wouldn't surprise me if there's companies focused on just that.

You mentioned big players coming in with their large patches and saying please accept our code and that's not necessarily how it works how does it work like how would you describe postgres governance or the core team like what's the size who are the people how do they make decisions and how does stuff actually get in is it like out there on github with pull stuff? Or is there a different process? How does it all run? So it is Git, but it's old school Git. Like go read the Postgres mailing list. Like here's a patch submitted via email. And like there, nope, GitHub. I think there's a GitHub mirror, but it's like, no, you're not submitting issues on GitHub. It is old school Linux open source development. And so Postgres has a few commit fests where like, here's a window open

for commits to come in. There's kind of a, it's fascinating because people think of the core team as like what commits and controls Postgres. The core team, I believe it's nine people. It used to be seven. That's more like a steering committee. Like, all right, we're gonna, you know, deal with the code of conduct complaints. And we're going to, like, figure out the conference and, like, defend trademarks and just make sure people abide by that. And then there is a commit bit and a major contributor, minor contributor. Major, minor is a little bit of a legacy thing. I don't think they're pushing that quite as much. Like, you commit a major feature, like range types or JSON.

You kind of earn, hey, you're a major contributor, major feature, right? That was in the release notes. Your commit bit, you earn over time, over years. A few years ago, they gave them out to some people that were really up and comers like Jeff Davis, Neil Conway, I think were really, really early. I think Jeff Davis may have been the youngest to get his commit bit at like 18 or 19. I don't know if it was him or Neil Conway, but young. Jeff Davis back active in the community for a little while. He wasn't. Neil Conway went on to get his PhD and is doing other interesting database things, but not active. And so Postgres is really slow about adding new committers. It's fascinating to watch some people that get their commit bit and get excited and like i'm gonna go ship some features now and commit stuff and it was not as solid it was a little buggy and their next year

was fixing that stuff like there's kind of this unspoken rule of you did this you maintain it you clean it up so the community really watches itself right there's's kind of that peer pressure. You're not committing conflicting pain on the rest of us, right? So commit fests happen every few months. That's an open window where patches are submitted. People sign up in the commit fests app. There's an app. So if you want to start to contribute to Postgres or see how it works, it's fascinating sense of open source development. Go review some patches. Pull them down, build Postgres, test it.

Reviewed the code quality. I can dig up, there's a couple of presentations that were given and we could link and show notes to like, here's how to contribute to Postgres. The best way is just reading the PG SQL hackers mailing list. Like you want to become a, people ask me a lot of times, how do I become like a really senior developer how do i like get good at c how do i become an advanced advanced developer just read

the hackers mailing list it's fascinating how the conversation it's not a cordial i mean it's it's cordial enough but it's not always friendly and like as a beginner you show up there and ask a question like all right where's the the patch to repro this and the sample test case and all that. But it's an amazing quality development that happens right there. So patches get submitted, pulled in during the commit fest. People sign up to review patches. Once enough review happens and people feel good, a committer picks it up and says, all right, I'm going to commit this. Even if they didn't author it, they'll give it a run through. They'll see the reviews of it and they commit it.

So there's a review process essentially community-wise that sort of layers on some desire for it to be Postgres native. Yeah. Anyone can come in and review it. You can sign up. You can hop on the CommitFest app. There's an open CommitFest right now and say, I'm going to help review this patch. It's kind of amazing that something like that works isn't it yeah it

seems so friction it's like it's like absolutely don't want anything stay away like completely autonomous organism of people just like organizing themselves over years and years and years right with a few like key players nine now who are like steering a direction but like so many perhaps conflicting ideas probably argumentation hopefully in the best sense of the word like all pushing this giant thing in a direction together it just seems like it would be so fraught with trouble but you know continues to stably move in a positive from the outside at least direction of improvement. I've had a lot of people ask, like, how can we replicate Postgres? I have no idea. Like the fact that it works, right? It's a

complete anomaly to me. There's not, I mean, the Linux kernel is maybe the only other similar example of that size and code base. And, you know, people talk about open source a lot. They're like open source databases. And Postgres defies that even like most open source a lot and they're like open source databases and postgres defies that even like most open source things are run by one company like there's one set of primary i think rails is a good another counter example of that right like hey large kind of community base but you know system stuff is usually not trivial and so so when people say, oh, there's open source databases, like MySQL. MySQL is primarily developed and maintained by a single company.

And Postgres, the core team cannot be comprised of more than half of one company. You look at the committers, and it's very distributed across... Is that written into the rules there? They say that's the case? I believe that is... No, I don't know if it's in distributed across, you know. Is that like written into the rules there? Like they say that's the case? That's in the, I believe that is, you know, I don't know if it's in the core, I don't know if I've read the core bylaws,

but it is at least a very unspoken rule. So when one recent acquisition happened, the core team grew from seven to nine to add two new people. I see. So like it's, if it's not in the bylaws, it's an unspoken one. And on the committers, it's the same thing.

It's not going to be 50% of the committers are at one company. People view that as unhealthy. And it's open source in its purest form, which I don't know that we see a lot of in the world. But it was started so long ago, back when open source community was smaller and simpler and grew to this i wonder if you could start fresh today not necessarily a database but a large open source thing that could grow into a similar form like you said you wouldn't know how to do it but even

could you do it maybe you can but it seems like it'd be harder today than it was back in the 90s or whatever. I don't know. I'm sure it's possible. I don't know if you started with that goal, right? Like, I, you know, I hope I'm around 25 years and can like go and see, right? Like, are there other examples of this? It's a great question we could wax poetic about and wonder for a while.

Well, let's get back to practical things here for those who are using Postgres or perhaps interested in it. What has been going on? I know 15 was a big release in 22. And surely there's things that are upcoming for the next major version. What's new and interesting, of course, with the disclaimer that it's all about being boring and stable. So it's like asking what's interesting about a boring thing, but we're interested and we know you are. What's on your radar, Craig, that people are working on in the community? Yeah, I mean, we hit on a lot with extensions.

I think extensions are, you know, going forward, we're going to talk about extensions as much as we talk about core Postgres. And I don't think it's a bad thing. I think it's just that line of how much of it goes crazy with Postgres versus is simpler. And I don't think it's a bad thing. I think it's just that line of how much of it goes crazy with Postgres versus is simpler. And I don't think going crazy is bad. I think we'll see a lot of innovation there.

I do think core Postgres keeps just getting better and better. You know, I think it was, I think it was 14. We had like refreshed materialized view. So like if you're using materialized views, like how do you refresh them, right? How do you reload the data? Like I want this snapshot of a materialized view and I do you refresh them right how do you reload the data like i want this snapshot of a materialized view and i want to refresh it it may have been that it was refreshed

concurrently i forget but it's like great this is a nice just simple thing that i had to work around before right logical replication we got a number of years ago now you can actually filter logical replication used to be the whole database now you can can apply like a, I want a logical stream of just these five tables. So way easier to, you know, kind of move data around from an ETL's perspective. To me, that was a huge one. That was like small and, you know, like usability that just when you need it, it's there.

There's a few things on like internal kind of sort performance and compression it's like every postgres release you you're like what's new and it's like just upgrade and you get better performance like that's just a nice thing to do every release now pretty much is just some better performance and the common questions will i be impacted by it will it will i get that performance uh just upgrade it can't be worse right it? Will I get that performance? Just upgrade. It can't be worse. It's really pretty good and stable about that. It can't be worse.

Well, surely there have been at some point some performance regressions, right? Like things have to slip through. It could be worse, right? It doesn't happen very often. Like Postgres is really. No, Jared. No, it can't be. I guess by the time they do a major release, they're ready for it. What's the cadence?

Is it like every set time or is a certain number of features when they decide this is a major release? So we have major releases every year and then there's five supported major versions at a time. Point releases come out every, I believe it's every two months. It might be every quarter. You have to double check that. But every so often for, hey, here's fixes, patches,

you know, that sort of thing. Usually the major release is every fall, like it kind of was a variable time from July to December. Usually now it's pretty close to that October time frame each year. I recommend waiting for the first point release always on a major version. When Postgres 15 came out, we supported it within five hours on Crunchy Bridge on day one. We have people that want it and that want to run Wild Wild West. Like, let's go. I want the new features. I'm ready for it. I recommend for that first patch release that's usually a couple months later. Postgres is really solid. It's good. It's not terrible to run, but you may find a bug in that first point release. So if you really want to care about stability even more, that waiting two, three months is not a bad thing to do.

Let's see. I'm trying to think of the other ones. A lot is performance. JSON stuff got a little bit of improvements. It continues to get just a little more bit by bit, which is nice. Some of the, just the functions around querying JSON, multi-range types and that sort of thing was pretty great. I'm looking at a list here, SQL merge command. That's not

something I'm familiar with. That was the top thing on 15. What is that? So it's a thing that's, I would not use it. I would actually use other things in Postgres. Like, it's so funny. Like, the broad set of user bases, like, look, it's finally getting merged. And it's like, here's other ways to work around and do this. What does merge do? Like merging two records? Yeah, it's a SQL syntax thing. So it's specific to, I believe you would probably want to like, most people would recommend

like a lateral join instead, or like traditional Postgres upcert. I think it hit the front page of Hacker News and every Postgres developer was like, please don't use this. Like use this other path of it. How do I get in then? Shouldn't the hive mind have rooted that one out before I got in? It's in this, I believe it's in the SQL standard. So it's like pushing like, okay, to be.

It's a compatibility thing. SQL standard and complete. And it was with some caveats. It's, I think it's one of those things. I should go back and see how much contention there was among core developers and committers of like, should this actually be in or not? It took a few years to make it in.

So it wasn't one of those runaway things, but it's like, cool, now we have complete compatibility with MySQL from that SQL perspective. Gotcha. It's kind of like the money data type in Postgres. It's in there, but you should never use it. Like, it assumes so many things about money and currency that just don't make sense that it's like, never use the money data type.

So how should you store currency inside of Postgres? What's the best practice? With a numeric data type. Okay. So why doesn't the money type just get removed? No code is the best code, right? I mean, isn't that the old adage? Yeah, because applications rely on it.

So that's why, I mean, that's why the bar is so high on Postgres, right? And people complain, it's like, go faster, add this feature. It's okay, you can change it later. And the community is great about this. It's like, you know, Postgres has managed to deprecate things. Like it really has, but it's like you know postgres has managed to deprecate things like it really has but it's it's a slow process and they want to make sure they're not subbing people's toes and give warnings and yeah is the money feature an old feature yeah it's been there for yes okay so it's dated it

assumed a lot of stuff yeah is there a book or a resource similar to javascript the good parts that somebody has written like Postgres, the good parts, because it sounds like there's areas, Greg, that you'd say, let's avoid these sections of Postgres. But here's the good stuff. The art of PostgresQL. It's by a good friend, Dimitri Fontaine. Yeah, it's and it's targeting app developers, too. It's not the DBA stuff. It touches on, here's how to do this in SQL, right? Things like common table expressions and window functions, which are scary, I think,

app developers, when you're like, whoa, what are we doing now in the database writing these sort of queries? When I talk to a lot of developers, if I'm giving a talk at a conference, ask them to raise their hand of who likes writing SQL? And I'll see, if there's 100 people, I'll like five hands and i'll follow that up with like who likes

reading other people's sequel and it's like no one because everyone writes like just bad sequel and it's like this string of unreadable mess but with like common table expressions you can construct really readable sequel where you're like, oh, this is like logical. Like I would write Ruby code and I can follow it. And so I think his book is really good for both the application developer stuff. Here's how to use JSON. Here's how to use range types. Here's how to like, you know, take advantage of this stuff. But also here's how to take advantage of SQL without it being too scary.

Love it. We will link that one up for those interested. The art of PostgresQL. For sure. It seems like the path to committing, though, is pretty narrow. That's why I'm like, well, just get rid of some of these features. If it's so narrow to get a feature in, you know, it seems like, you know, you should be quick to bounce

as slow as you're to take, so. Maybe. I think it's, you know, Postgres, especially with the rise in popularity, people are like, well, why can't Core just do, so maybe i think it's you know postgres especially with the rising popularity people like well why can't core just i mean we mentioned you know the postgres ish of neon right and well they're they're trying to build like it's easy to say why aren't they postgres no you can just be postgres and it's like but they've got to upstream this and they've got to wait for a year or two or three to keep that quality up. That quality. I think it was the geo stuff though.

It was mainly around the geo. Like the other stuff, it seemed like, I'm trying to recall the conversation though. I'm not trying to defend, I'm just trying to clarify. I think their intention is to be as Postgres as possible. Now, obviously presents as and Postgres compatible sounds very similar to that, but it sounds like they're trying to be Postgres and they want that to be given to the community. I think so much so that Jared, you're like, can we run Neon on our own? And Nikita's like, yeah, you can. You can take our patches

and recompile Postgres yourself and get to the same Neon we're at today and do it yourself. That's what I recall from that conversation. I think it's a big step forward from you know i would describe neon as an open source aurora i think that's fair you talk to amazon uh i think i think you you could ask nikita and be like that's probably a fair assessment right and you go talk to amazon saying well why haven't you open sourced aurora and they're like well it has all these amazon specific specific things and it wouldn't be good to the community. So I think this is definitely a step in the right direction.

But Postgres at its core, you put that in there and it breaks something or has this edge case or and then the whole set of community, a lot of volunteer on their nights and weekends developers, some of them

are paid full time for this, are now supporting this thing for a company that is like, you know, supports their mission. So at the core, right, you want a database to just work and not lose your data. And Postgres holds that bar really high. Not every database actually does. Some play fast and loose there. So it's a thing that if you want that, you've got to take that trade off of it's going slow, and things get deprecated slowly, because they made it in because we thought the quality was there. It's a thing that if you want that, you've got to take that trade off of it's going slow and things get deprecated slowly because they made it in because we thought the quality was there. It's a little slow and steady,

but it's the tortoise that's won the race so far. So what Neon is trying to do, take Postgres serverless, has two facets. You have the separation of the data storage from the compute layer, which they seem to have accomplished. Then you have the replication or the distribution of the database

all around the world to these different edge nodes. And it seems that there's a part of the industry that's going that direction. It's the edge of the industry. It seems like it's being very much bleeding edge or maybe being pushed by people who have reasons for that. But I wonder if the core team from your interactions or anything like, is there discussion of the Postgres developers of like, we're also headed in this similar direction or is that not something that they're interested

in building into Postgres? These kinds of, it's kind of re-architecting to a certain extent, which is why Neon has to patch and extend and do a lot of things in order to get it done. But as Postgres core, are they moving that way or are they just moving down the road of slow and steady performance improvements? Everything's extensions.

I think more of the latter. And I would say Postgres probably does better of all that shiny stuff than people realize. I've got a customer that looked at, they were on Heroku and thinking, okay, I'm thinking about what I do after Heroku. And ran this app that benchmarked on all these providers. And I'll send the link so that we can post it to the show notes. This is their benchmark. And Crunchy has geo-replicas today

and connected their Fly.io app, which Fly is all about run the app on the edge everywhere. And this is vanilla Postgres. There is no special proprietary anything. Vanilla Postgres, just running geo-replicas, we're faster than like fly native things so like Kurt's over there like you want to manage postgres run on crunchy bridge and like guess what postgres is really good and it doesn't get talked about because it is

boring and stodgy and not shiny new we did this advanced thing but guess what like vanilla postgres geo replicated reallyplicated, really fast. It works really well. I was kind of surprised, but I was surprised that we beat fly native ones. Like, wait, huh? How are we faster than fly on, like, when we're not even on fly? This is an AWS instance, you know, geo-replicated, and

AWS or Azure or GCP not on fly hardware. That it's actually a better performance latency time. Well, that's cool. Well, the one difference, I think, is that it's actually a better performance latency time well that's cool well the one difference i think is probably it's not managed and it's not serverless right there's there's two kind of key parts there which is part of the the neon story because you got to manage yourself and it doesn't spin down to zero yeah i think that spin down to zero is is a fair one and you know that's a great question i To me, I usually think of serverless is

more of a business thing. Like, are you do you actually care that it spins out to zero? Or you just don't want to pay for it when it's not in use? Right? I think, you know, you even look at that spin down to zero and look at an Aurora, there is no like zero cost Aurora anymore. It's now a minimum like, hey, we'll idle it. But still, there's a minimum, you we'll idle it but still there's a minimum you know budget account for your database yeah surely yeah i mean there's a business challenge there too because i remember one of jared's questions was like okay so you're footing the bill to that spend on the zero you're going to hold that data for how long because that zero may never come back to a one because the customer left or they no longer are interested in neon and you're sitting here with this data on a

disc and you're you know and he talked about the tiers of data and stuff like that. So there's definitely a business challenge there when it comes to affording that long term and enabling that forever zero feature, that spin on zero feature. It's an interesting world. Yeah, Heroku, I mean, look at Heroku as the perfect example of this. And, you know, the articles that are written of like, you know, this is why we can't have good things and is this the end of free for the internet for developers? I don't know. I think there's

ways to do that sustainably. For us, if you use your database for less than $5 a month, we don't bill you. I want it to be accessible to students and hobby developers. Use it, idle it. And you're just paying for the storage there. And we have people that every month just develop and work away and learn and that sort of thing.

But at the end of the day, how do you do that long-term, right? Like I'm sure they're going to grow and eventually someone's going to come in and say, oh, look, look at this line item here that we're footing the bill for. How do we reconcile that? Precisely.

Yeah, does that turn into true business and i and even with like heroku which i don't want to get too deep into that that set of weeds there but like you got to imagine the fraud waste and abuse in that free tier like it's a great enabler and i'm cool with that i love that but as a business that's trying to sustain and grow i'm sure sales Salesforce is a very large company, et cetera, whatever you want to attach to that. But there's a lot of security vulnerability in that free tier. There's a lot of fraud, abuse in that free tier that just isn't their core business.

Nothing that's more their argument than the free tier at large's argument because there's so many customers that could be a paying customer in that free tier if you just farm for them and educate them. But they've got to be real customers, real possibilities, not those there to just simply abuse the system. This is over 10 years ago, but I was the first product manager that handled fraud and abuse at Roku way back. So it wasn't a new thing. It's not a thing that started with yeah blockchain it

was uh the very first case uh yeah i mean i don't want to go down too deep too far down that rabbit hole because we don't go too deep but sure go one more we'll allow it we can talk about barbecue for an hour we can talk about heroku for an hour oh yeah i do actually love postgres but those things are fun too but um yeah the very first case was in korea you had to have a reservation to buy an iphone and so this app was spinning up connecting out to apple and making all the reservations and then reselling them so not even reselling an iphone like changing the name of the reservation and selling it out to people. Now, we were playing chicken and mouse with this. So like we would, they just kept pushing up the same slug, right?

So we could just look at the Git shot and be like, oh, it's okay. Then they started adjusting the Git shot of like, oh, I'll just add an empty commit. So they can't easily find it. We actually found this person. I think enough time has elapsed now their git commit had their name and like googled them had their linkedin had their like i like their name their where they were we coordinated with apple sent it over to them and they're like okay thank you we'll take care of this and like we know like it just went away after that don't know what they did but that was the

very first case of like what is going on why is all this traffic going to apple what what purpose do you have to make a reservation for an iphone like i never knew this was how in demand they were and how it worked there and so tim cook made that guy an offer he couldn't refuse it's true good one jared that or broke some kneecaps i don't know which i don't like it's a i'm gonna say he woke up with a horse head in his bed or something, right? Like come work for us or, or,

you know, or the other option, but it's nothing new. Run our reservations team. Yeah. I'm sure it's not any better with, you know, coin mining and other things like it.

Yeah. Well, there's another factor there, which we had a decade of hyper growth, you know, zero percent interest rate based investment. And the free tier for a startup is a epic win for growth. I mean, it's a massive way to get lots of people.

I think, was it Jason Bosco from TypeSense, Adam, that we talked to about how they didn't have a free for open source or a free for whatever offering with their cloud and how that is one way of going about getting a whole bunch of users that you could just buy them because you have investment money

and those times are changing. I think that's more of the, I don't know if cynical is the right word, but maybe the hairier side of what those things are. Of course, we want to always just be like, we love developers, we love open source, and we want to see people tinker and have fun, and here it is.

And I do believe that's sincere in many cases. It is also a hyper-growth strategy that's afforded by large investments and continues to run based on larger investments which eventually run out or need their money back. And so, like you said, eventually Salesforce is like,

this doesn't make sense for Heroku anymore. And so we're not going to do it. I think it's a little different there. And I like to think actually Crunchy has some of the same philosophy and ethos as the early Heroku. Like it's not free as a business piece, right? We want you to come to, I want you to learn Postgres. I want you to get experience with Postgres.

I want you to be able to build your side project and it not cost you $1,000 on the weekends. Come bootstrap a thing, right? But when you're up and running in production, if you're getting value out of it, you should pay for it, right? And Heroku very much was that, hey, developers should learn here. Like the amount of like Rails girls camps that ran there and PyLadies and all that sort of thing. I think some of that ethos got lost.

I don't know if you guys saw, we shipped Postgres in the browser, but it's a whole playground. Instead of us running databases and connecting to them, it's running locally in your browser. You want to learn. You don't have to install postgres and we have like apparently now like some university courses like basing stuff on that like oh cool like you don't have to installing rails is still hard installing postgres is not always trivial so how do we make it easy for people to learn get started and then when you get value yeah go pay for it right totally yeah that postgres in the browser thing is so cool. Yeah.

What was involved in getting that in the browser? What's the backstory? That was an engineer that showed up on a Monday and said, I did a crazy thing this weekend. Like, I've been playing with Wasm and I just put Postgres in. He's like, yeah, I know it's crazy. It's a stupid idea.

I'm like, actually, I wonder, can we do this? And so our whole playground, there's a Notion database I'm like, actually, I wonder, can we do this? And so our whole playground, there's a notion database we have that we just go and add tutorials. So it's bootstrapped by like markdown and then a SQL file. And that loads up a whole new tutorial. So we have like marketing folks that like don't have to deploy any app change to just like edit a mark a, you know, notion file. And now we've got like new tutorials for people pretty ad hoc. It's been amazing that we've got a ton of internal folks that are like, oh yeah, I wrote this blog post, and here's a tutorial that you can follow step by step, pretty marked down with images and etc., and it's just

bootstrapped by your own SQL file. Then we have an Easter egg in there as well, where you can just append to the URL to Playground, like SQL equals, and then give it a URL and it'll load your own SQL file. So if you wanted like internal training with sample data, you can just, it'll boot up the browser instance, download that SQL file, like create tables, load up data, all just right there for you.

That's cool, man. So what lives in Notion specifically? So if you go to our playground, you'll see like the title of a tutorial, the description, the SQL, and then the markdown. And that's like, so we're hitting the Notion API to basically render all that. Think of Notion as our CMS for the playground.

We use Notion internally to essentially run our entire schedule. We do a bunch of interesting things. I'm just curious what you put in there. So it essentially gets consumed by your website via the API. It's not actually Notion, but what is there for each tutorial lives in Notion probably as its own page or document or whatever. Yeah, exactly. You also totally do a blog post about that. I'm super curious because our events page for our website is powered by Notion and all that. So now I'm curious

to see. I mean, sounds like we're using some things in similar ways. It's a love-hate relationship with Notion. I like it. It's very heavy. I did say one time, Jared, it was super fast and it's gotten slower. So sad. But it's a love-hate relationship.

I never experienced that. He's like, Notion's super fast. I'm like, it is? Is it? Maybe it was temporary. But still, yeah, an amazing tool. I love it. Love Notion. It's just, it's kind of bulky.

But in terms of giving access to people who are not, they don't have to query a SQL or Postgres database in order to add tutorials to the Postgres playground. It's super cool for accessibility to your guys' teams. I love wins like that. We used to use Trello in a similar way as a CMS for our newsletters. And so just, I think people,

I think Notion has become kind of the new build your own integrations that team members can work on kind of thing. People are starting to whip out some code and glue together some really interesting solutions to their problems. it is slow yeah i agree with that i agree with both points right there's a lot in there is there too much in there is it that curated clean cut product i'm not sure anymore but yeah you can do some cool stuff with it to create that kind of you know cms flexibility accessibility stuff all right craig anything left unasked, untold?

You dropped this cool playground on us, which I had heard about, but didn't realize it was you and your team that put it together. That's a super cool nugget here at the end. Anything else in the Postgres world? We know there's Postgres Weekly for those who want to keep up, which you're also involved in. That's a Peter Cooper joint. What else to say before we call it a show? Probably the final thing is just

JSON, JSONB, and Postgres is awesome. It's hard not to mention. We've made it an hour and not talked about JSONB, which everyone is like, it's awesome, and I use it. Man, maybe everyone knows it and is aware, but I still see people every so often and they're like, wait, Postgres can do that?

And it's full. JSON came in, which was just cheating. It was just text validation on JSON and threw it into a text file, text field. And then JSON B came in. One of my colleagues says B stands for better. So I continually, you know, steal that from him. It's binary JSON on disk, rich indexing, searching. It's really, really great. So, I mean, I think that, you know, you think of postgres is this stodgy relational database we're i think past that but if you weren't aware that we're past that like the json b stuff in postgres i think highlights it and we're coming up on on 10 years of json

and postgres so um i'll leave with that it's like it really is a pretty sweet database we talked a lot about extensions like when you think i need need a Postgres-like thing, no, maybe you just need Postgres. Just Postgres is pretty cool by itself. There you go. Well, JSON beat it up. I remember when Douglas Crockford said that JSON would never have a version. Is that kind of like a slap in the face? Is he involved in JSON? I don't know. What's the story there? No, not at all. I mean, it's JSON, but it's, yeah, it's... But it's better. Exactly.

Exactly. And instead of a JSON2.io, it's just JSONB, so it's the final one. It's the better one. It's the better one. There's no JSONC, Adam. There's not going to be a JSONC. It's just... No JSONZ or Zed. Or JSON++. Our only option now is like JSONB++.

That's right. There you go. That's the way to do it. It's better. Craig, thanks for coming on last minute, too. Appreciate the... Appreciate catching up. I appreciate being here. I wasn't here for two years ago when you were here, so hopefully I'm here two years from now

when you come back and we talk about... I think two years ago, you're like, I'm not really a Postgres guy. I don't really do that. I don't have opinions on it. I think you were like... Honestly, I don't really do that. I don't have opinions on it. I think you were like... Honestly, I don't know what happened. It was October when that was recorded.

It wasn't like it was June, Jared, when I would take vacation or something like that. I'm trying to consider why I wouldn't have been available for that call. I've met that guy in the beer line, and I don't want to talk to him. Yeah, I don't like that guy. I met him 10 years ago. He's got a terrible barbecue.

Okay, so we do have to come back. We have a show called Backstage Craig, and we'd love to have you back. Jared, you can join to sniff or partake, not to cook, and we could talk about rubs, timing, temperature, you know. That sounds awesome. Let's do it. How posh you may or may not be.

Is it mill scale for life or is it something else? You know, what do you do? Did you have yours custom built? Do you build them custom yourself? Of course, I'm talking about the steel around a barbecue, which is the barbecue itself

and your process. But let's do that on backstage. Thank you for all your passion in Postgres. Thank you for all the work you're doing at Crunchy Data and the work you're putting in there and for coming on the show.

It's been a pleasure. Yeah. Thanks, folks. I'm glad it worked out last minute. I was like, I think it was last week, like I was on the Django chat, you know, at the end of the year. I'm like, oh, this is fun.

I should actually do some more of these. So it was a nice, you know, opportunity. I'm going to go retrieve a kid from school. Do it. Awesome. Thanks, Craig. Thanks, folks. That Do it. Awesome. Thanks, Greg. Thanks, folks. That's it. Okay. So just Postgres, is it enough? We think it is. Just Postgres,

not Postgres compatible, not presents as Postgres. Not that those are bad things. It's just not Postgres. It's like saying open source, but being BSL. It's not open source. So don't call it open source. A big thank you to our friends and partners Fastly and Fly. And of course, thank you Breakmaster Cylinder. Those beats are banging. We love them. Keep them coming.

Okay, this show's done. Thank you for tuning in. We will see you on Monday. day Thank you.