Announcer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.

Corey: This episode is sponsored in part by Honeycomb. When production is running slow, it's hard to know where problems originate: is it your application code, users, or the underlying systems? I’ve got five bucks on DNS, personally. Why scroll through endless dashboards, while dealing with alert floods, going from tool to tool to tool that you employ, guessing at which puzzle pieces matter? Context switching and tool sprawl are slowly killing both your team and your business. You should care more about one of those than the other, which one is up to you. Drop the separate pillars and enter a world of getting one unified understanding of the one thing driving your business: production. With Honeycomb, you guess less and know more. Try it for free at Honeycomb.io/screaminginthecloud. Observability, it’s more than just hipster monitoring.

Corey: This episode is sponsored in part by our friends at Jellyfish. So, you’re sitting in front of your office chair, bleary eyed, parked in front of a powerpoint and—oh my sweet feathery Jesus its the night before the board meeting, because of course it is! As you slot that crappy screenshot of traffic light colored excel tables into your deck, or sift through endless spreadsheets looking for just the right data set, have you ever wondered, why is it that sales and marketing get all this shiny, awesome analytics and inside tools? Whereas, engineering basically gets left with the dregs. Well, the founders of Jellyfish certainly did. That’s why they created the Jellyfish Engineering Management Platform, but don’t you dare call it JEMP! Designed to make it simple to analyze your engineering organization, Jellyfish ingests signals from your tech stack. Including JIRA, Git, and collaborative tools. Yes, depressing to think of those things as your tech stack but this is 2021. They use that to create a model that accurately reflects just how the breakdown of engineering work aligns with your wider business objectives. In other words, it translates from code into spreadsheet. When you have to explain what you’re doing from an engineering perspective to people whose primary IDE is Microsoft Powerpoint, consider Jellyfish. Thats Jellyfish.co and tell them Corey sent you! Watch for the wince, thats my favorite part.

Corey: Welcome to Screaming in the Cloud. I’m Corey Quinn. Today’s promoted episode is a treasure and a delight. Longtime listeners of this show know that it’s not really a database—unless of course, it’s Route 53—and of course, I don’t solve pronunciation problems with answers that make absolutely everyone hate me. Longtime listeners of the show know that if there’s one thing I adore when it comes to databases—you know, other than Route 53—it is solving pronunciation holy wars in such a way that absolutely everyone is furious with me as a result, and today is no exception. My guest is Ed Boyajian, the CEO of EDB, a company that effectively is the driving force behind the Postgres-squeal database. Ed, thank you for joining me.

Ed: Hey, Corey.

Corey: So, I know that other people pronounce it ‘post-gree,’ ‘Postgresql,’ ‘Postgres-Q-L,’ all kinds of other things. We know it’s decidedly not ‘Postgres-squeal,’ which is how I go for it. How do you pronounce it?

Ed: We say ‘Postgres,’ and this is one of the great branding challenges this fantastic open-source project has endured over many years.

Corey: So, I want to start at the very beginning because when I say that you folks are the driving force behind Postgres—or Postgres-squeal—I mean it. I’ve encountered folks from EDB—formerly EnterpriseDB—in the wild in consulting engagements before, and it’s great because whenever we found an intractable database problem, back at my hands-on keyboard engineering implementation days, very quickly after you folks got involved, it stopped being a problem, which is kind of the entire point. A lot of companies will get up there and say, “Oh, it’s an open-source project,” with an asterisk next to it and 15 other things that follow from it, or, “Now, we’re changing our license so the big companies can’t compete with us.” Your company’s not named after Postgres-squeal and you’re also—when you say you have people working on it, we’re not talking just one or two folks; your fingerprints are all over the codebase. How do you engage with an open-source project in that sense?

Ed: First and foremost, Postgres itself is, as you know, an independent open-source project, a lot like Linux. And that means it’s not controlled by a company. I think that’s inherently one of Postgres’s greatest strengths and assets. With that in mind, it means that a company like EDB—and this started when I came to the company; I came from Red Hat, so I’ve been in open-source for 20 years—when I came to the company back in 2008, it starts with a commitment and investment in bringing technology leaders in and around Postgres into a business like EDB, to help enterprises and customers. And that dynamic intersection between building the core database in the community and addressing customer needs in a business, at that intersection is where the magic happens. And we’ve been doing that since I joined EDB in 2008; it was really an explicit focus for the company.

Corey: I’d like to explore a little bit, well first and foremost, this story of is there a future for running databases in cloud environments yourself? And I have my own angry, loud opinion on this that I’m sure we’ll get to momentarily, but I want to start with yours. Who is writing their own databases in the Year of our Lord 2021, rather than just using whatever managed thing is their cloud provider of choice today is offering for them?

Ed: Well, let me give you context, Corey, because I think it matters. We’ve been bringing enterprise Postgres solutions to companies now, since the inception of the company, which dates back to 2004, and over that trajectory, we’ve been helping companies as they’ve done really two things: migrate away, in particular from Oracle, and land on Postgres, and then write new apps. Probably the first ten of the last 13 years since I’ve been in the company, the focus was in traditional on-prem database transformations that companies were going through. In the last three years, we’ve really seen an acceleration of that intersection of their traditional deployments and their cloud deployments. Our customers now, who are represented mostly in the Fortune 500 and Global 2000, 40% of our customers report they’re deploying EDB’s Postgres in the cloud, not in a managed context, but in a traditional EC2 or GCP self-managed cloud deployment.

Corey: And that aligns with what I’ve seen, a fair bit. Years ago, I wound up getting the AWS Cloud Practitioner Certification—did a whole blog post on it—not because it was opening any doors for me, but because it let me get into the certified lounge at re:Invent, and ideally charge a battery and have some mostly crappy coffee. The one question I got wrong was I was honest when I answered, “How long does it take to restore an RDS database from snapshot backup?” Rather than giving the by-the-book answer, which is way shorter than I found in practice a fair bit of the time. And that’s the problem I always ran into is that when you’re starting out and building something that needs a database, and it needs a relational database that runs in that model so all the no SQL options are not viable for whatever reason, great, RDS is great for getting you started, but there’s only so much that you can tune and tweak before you start to run into issues were, for particular workloads as they scale-out, it’s no longer a fit for a variety of reasons.

And most of the large companies that I work with that are heavily relational-database-driven have either started off or migrated to the idea of, “Oh, we’re going to run our own databases on top of EC2 instances,” for a variety of reasons that, again, the cloud providers will say, “Oh, that’s not accurate, and they’re doing the wrong thing.” But, you know, it takes a certain courage to tell a large-scale customer, “You’re doing it wrong.” “Well, why is that?” “Because I have things to sell you,” is kind of a terrible answer. How do you see it? Let’s not pick on RDS, necessarily, because all of the cloud providers offered managed database offerings. Where do those make sense and where do they fall down?

Ed: Yeah, I think many of our customers who made their first step into cloud picked a single vendor to do it, and we often hear AWS is been that early, early—

Corey: Yeah, a five-year head start makes a pretty compelling story.

Ed: That’s right. And let’s remember what these vendors are mostly. They are mostly infrastructure companies, they build massive data centers and set those up, and they do that beautifully well. And they lean on software, but they’re not software companies themselves. And I think the early implementation of many of our customers in cloud relied on what I’ll call relatively lightweight software offerings from their cloud vendor, including database.

They traded convenience, ease of use, an easy on-ramp, and they traded some capability in some depth for that. And it was a good trade, in fact. And for a large number of workloads it may still be a good trade. But our more sophisticated customers, enterprise customers who are running Postgres or databases at scale in their traditional environments have long depended on a very intimate relationship with their database technology vendor. And that relationship is the intersection of their evolving and emerging needs and the actual development of the database capabilities in support of that.

And that’s the heart of who we are at EDB and what we do with Postgres and the many people we have committed to doing that. And we don’t see our customers changing that appetite. So, I think for those customers, they’ve emerged more aware of the need to have a primary relationship with a database vendor and still be in cloud. And so I think that’s how this evolves to see two different kinds of services side-by-side, what they really want is a Database as a Service from the database vendor, which is what we just announced here at Microsoft Ignite event.

Corey: So, talk to me a little bit more about that, where it’s interesting in 2021 to see a company launching a managed service offering, especially in the database space, when there’s been so much pushback in different ways against the large cloud providers—[cough] Amazon—who tend to effectively lose sleep at night over the haunting fear that someone who isn’t them is making money, somehow. And they will take whatever is available to them and turn it into a managed service offering. That’s always been the fear, so people play games with licenses and the rest. Well, they’ve been running Postgres offerings for a long time. It is an independent open-source project.

I don’t think you can wind up forcing a license change through that says everyone except big companies can run this themselves and don’t do a managed service with it because that cat is very much out of the bag. How is it that you’re taking something to market now and expecting that to fare competitively?

Ed: So, I think there’s a few things that our customers are clearly telling us they want, and I think this is the most important thing: they want control of their data. And if you step back, Corey, look at it historically, they made a huge trade to big proprietary database companies, companies like Oracle, and they made that trade actually for convenience. They traded data to that database vendor. And we all know the
successes Oracle’s had, and the sheer extraordinary expense of those technologies. So, it felt like a walled garden.

And that’s where EDB and Postgres entered to really change that equation. What’s interesting is the re-platforming that happened and the transformation to cloud actually had the same, kind of, binding effect; we now moved all that data over to the public cloud vendors, arguably in an even stickier context, and now I think customers are realizing that’s created a dimension of inflexibility. It’s also created some—as you rightly pointed out—some deficiencies in technical depth, in database, and in software. So, our customers have sorted that out and are kind of coming back to middle. And what they’re saying is, “Well, we want all the advantages of an open-source database like a Postgres, but we want control of the data.”

And so what control looks like is more the ability to take one version of that software—in our case, we’re worrying about Postgres—and deploy the same thing everywhere they go. And that opens the door up for EDB to be their partner as a traditional on-prem partner, in the cloud where they run our Postgres and they manage it themselves, and as their managed service, Postgres Database as a Service Provider, which is what we’re doing.

Corey: I’ve been something of a bear on the idea of, “I’m going to build a workload to run everywhere in every cloud provider,” which I get. I think that’s generally foolish, and people chasing that, with remarkably few exceptions, are often going after the wrong thing. That said, I’m also a fan of having a path to strategic Exodus, where Google’s Cloud Spanner is fascinating, DynamoDB is revelatory, Cosmos DB is a security nightmare, which is neither here nor there, but the idea that I can take a provider’s offering that even if it solves a bunch of problems for me, well, if I ever need to move this somewhere else for any reason, I’m re-architecting, my data model and re-architecting the built-in assumptions around how the database acts and behaves, and that is a very heavy lift. We have proof of that from Amazon, who got up on stage and told a story about how much they hate Oracle, and they’re migrating everything off of Oracle to Aurora, which they had to build in order to get off of Oracle, and it took them three years to migrate things. And Oracle loves telling that story, too.

And it’s, you realize you both sound terrible when you tell that story? It’s, “This is a massive undertaking that even we struggle with, so you should probably not attempt it.” Well, what I hear from that is good God, don’t wind up getting locked into a particular database that is only available from one source. So, if you’re all-in on a cloud provider, which I’m a fan of, personally—I don’t care which one but pick a cloud provider—having a database that is not only going to work in that environment is just a reasonable step as far as how I view things. Trading up that optionality has got to pay serious dividends, and in many database use cases, I’ve just don’t see it.

Ed: Yeah, I think you’re bringing up a really important point. So, let’s unpack it for a minute.

Corey: Please.

Ed: Because I think you brought up some really prominent specialty database technologies, and I’m not sure there’s ever a way out of that intersection and commitment to a single vendor if you pick their specialty database. But underneath this is exactly one of the things that we’ve worried about here at EDB, which is to make Postgres a more capable, robust database in its entirety. A Postgres superpower is its ability to run a vast array of workloads. Guess what, it’s not sexy. It’s not sexy not to be that specialty database, but it’s incredibly powerful in the hands of an enterprise who can do more.

And that really creates an opportunity, so we’re trying to make Postgres apply to a much broader set of workloads, from traditional systems of record, like your ERP systems; systems of analysis, where people are doing lightweight analytic workloads or reporting, you can think in the world of data warehouse; and then systems of engagement, where customers are interacting with a website and have a database on the backend. All areas Postgres has done incredibly well in and we have customer experience with. So, when you separate out that core capability and then you look at it on a broader scale like Postgres, you realize that customers who want to make Postgres strategic, by definition need to be able to deploy it wherever they want to deploy it, and not be gated or bound by one cloud vendor. And all the cloud vendors picked up Postgres offerings, and that’s been great for Postgres and great for enterprises. But that corresponding lock-in is what people want to get away from, at this point.

Corey: There’s something to be said for acknowledging that there is a form of lock-in as far as technology selection goes. If you have a team of folks who are terrific at one database engine and suddenly you’re switching over to an entirely different database, well, folks who spent their entire career working on one particular database that’s still in widespread use are probably not super thrilled to stick around for that. Having something that can migrate from environment to environment is valuable and important. When you say you’re launching this as a database as a service offering, how does that actually work? Is that going to be running in your own cloud environment somewhere and people just make queries across the wire through standard connections to the database like they would something locally? Are you running inside of their account or environment? Is it something else?

Ed: So, this is a fully-managed database as a service, just like you’d get from any cloud vendor or DBAAS vendor that you’ve worked with in the past, just being managed and run by EDB. And with that, you get lot of the goodies that we bring, including our compatibility, and all our deep Postgres expertise, but I think one of the other important attributes is we’re going to run that service in our clients’ account, which gives them a level of isolation and a level of independence that we think is really important. And as different as that is, it’s not heroic; it’s exactly what our customers told us they wanted.

Corey: There’s something to be said for building the thing that your customers have said that they want and make sense for you to build as opposed to, “We’re going to build this ridiculous thing and we’re sure folks are going to love it.” It’s nice to see that shaping up in the proper order. And I’ve fallen victim to that myself; I think most technologists have to some extent. How big is EDB these days?

Ed: So, we have over 650 employees. Now, around the world, we have 6000 customers. And of the 650 employees, about 300 of those are focused on Postgres. A subset of that are 30-odd core team members in the Postgres community, committers in the Postgres community, major contributors, and contributors in the Postgres community. So, we have a density of technical depth that is really unparalleled in Postgres.

Corey: You’re not, for lack of a better term, pulling an Amazon, insofar as you’re, “Well, we have three people working on open-source projects, so we’re going to go ahead and claim we’re an open-source company,” in other words. Conversely, you’re also not going down the path of this is a project that you folks have launched, and it claims to be open-source because we love it when people volunteer for for-profit entities, but we exercise total control over the project. You have a lot of contributors, but you’re also still a minority, I think the largest minority, but still a minority of people contributing to Postgres.

Ed: That’s right. And, look, we’re all-in on Postgres, and it’s been that way since I got here. As I mentioned earlier, I came from Red Hat where I was—I was at Red Hat for a little over six years, so I’ve been an open-source now for 20 years. So, my orientation is towards really powerful, independent open-source projects. And I think we’ll see Postgres really be the most transformative open-source technology since Linux.

I think we’ll see that as we look forward. And you’re right, though, I think what’s powerful about Postgres is it’s an independent project, which means it’s supported by thousands of contributors who aren’t tied to single companies, around the world. And it just makes the software—we develop innovation faster, and I think it makes the software better. Now, EDB plays a big part in there. Roughly, a little less than a third of the last res—actually, the 13 release—were contributions that came from contributors who came from EDB.

So, that’s not a majority, and that’s healthy. But it’s a big part of what helps move Postgres along and there aren’t—you know, the next set of companies are much, much—next set of combined contributors add up to quite small numbers. But the cloud vendors are virtually non-existent in that contribution.

Corey: This episode is sponsored in part by something new. Cloud Academy is a training platform built on two primary goals. Having the highest quality content in tech and cloud skills, and building a good community the is rich and full of IT and engineering professionals. You wouldn’t think those things go together, but sometimes they do. Its both useful for individuals and large enterprises, but here's what makes it new. I don’t use that term lightly. Cloud Academy invites you to showcase just how good your AWS skills are. For the next four weeks you’ll have a chance to prove yourself. Compete in four unique lab challenges, where they’ll be awarding more than $2000 in cash and prizes. I’m not kidding, first place is a thousand bucks. Pre-register for the first challenge now, one that I picked out myself on Amazon SNS image resizing, by visiting cloudacademy.com/corey. C-O-R-E-Y. That’s cloudacademy.com/corey. We’re gonna have some fun with this one!

Corey: Something else that does strike me as, I guess, strange, just because I’ve seen so many companies try to navigate this in different ways with varying levels of success. I always encountered EDB—even back when it was EnterpriseDB, which was, given their love of acronyms, I’m still somewhat partial to. I get it; branding, it’s a thing—but the folks that I engaged with were always there in a consulting service’s capacity, and they were great at this. Is EDB a services company or a product company?

Ed: Yeah, we are unashamedly a product technology company. Our business is over 90% of our revenue is annually recurring subscription revenue that comes from technical products, database server, mostly, but then various adjacent capabilities in replication and other areas that we add around the database server itself. So no, we’re a database technology company selling a subscription. Now, we help our customers, so we do have a really talented team of consultants who help our customers with their business strategy for Postgres, but also with migrations and all the things they need to do to get Postgres up and running.

Corey: And the screaming, “Help, help, help, fix it, fix it, fix it now,” emergencies as well.

Ed: I think we have the best Postgres support operation in the world. It is a global 24/7 organization, and I think a lot of what you likely experienced, Corey, came out of our support organization. So, our support guys, these guys aren’t just handling lightweight issues. I mean, they wade into the gnarly questions and challenges that customers face. But that’s a support business for us. So, that’s part and parcel. You get that, it’s included with the subscription.

Corey: I would not be remembering this for 11 years later, if it hadn’t been an absolutely stellar experience—or a horrible experience, for that matter; one or the other. You remember the superlatives, not the middle of the road ones—and if it hadn’t been important. And it was. It also noteworthy; with many vendors that are product-focused, their services may have an asterisk next to it because it’s either a, “Buy our product and then we’ll support it,” or it’s, “Ohh, we’re going to sell you a whole thing just to get us on the phone.” And as I recall, there wasn’t a single aspect of upsell involved in this.

It was, “Let’s get you back up and running and solve the problem.” Sure, later in time, there were other conversations, as all good businesses will have, but there was no point during those crisis moments where it felt like, “Oh, if you had gone ahead and bought this thing that we sell, this wouldn’t happen,” or, “You need to buy this or we won’t help you.” I guess that’s why I’ve contextualized you folks as a services company, first and foremost.

Ed: Well, I’m glad you have that [laugh] experience because that’s our goal. And I think—look, this is an interesting point where customers want us to bring that capability to their managed DBAAS world. Step back again, go back to what I said about the big cloud vendors; they are, at their core, infrastructure companies. I mean, they’re really good at that. They’re not particularly well-positioned to take your Postgres call, and I don’t think they want that call.

We’re the other guys; we want to help you run your Postgres, at scale, on-prem, in the cloud, fully managed in the cloud, by EDB, and solve those problems at the same time. And I think that’s missing in the market today. And we can step back and look at this overall cloud evolution, and I think some might think, “Gee, we’re into the mature phase of cloud adoption.” I would tell you, since the Red Sox have done well this year, I think in a nine-inning baseball game—for those of your listeners who follow American baseball—we’re in, like, the top of the second inning, maybe. Maybe the bottom of the second inning. So, we’ve been able to listen and learn from the experiences our customers have had. I think that’s an incredible advantage as we now firmly plant ourselves in the cloud DBAAS market alongside our robust Postgres capabilities that you experienced.

Corey: The world isn’t generating less data, and it’s important that we’re able to access that in a bunch of different ways. And the last time I really was playing with relational databases, you can view my understanding of it as Excel with a weirder interface, and you’re mostly there. One thing that really struck me since the last time I went deep into database-land over in the Postgres-squeal world has been just the sheer variety of native data types that it winds up supporting. The idea of, “Here’s some JSON. Take this and store it that way,” or it’s GIS data that it can represent, or the idea of having data types that are beyond just string or var or whatever other somewhat limited boolean values or whatnot. Without having just that traditional list, which is of course all there as well. It also seems to have extensively improved its coverage that just can only hint to my small mind about these things and what sort of use cases people are really putting these things into.

Ed: Yeah, I think this is one of Postgres’ superpowers. And it started with Mike Stonebraker’s original development of Postgres as an object-relational database. Mike is an adviser to EDB, which has been incredibly helpful as we’ve continued to evolve our thinking about what’s possible in Postgres. But I think because of that core technology, or that core—because of that core technical capability within Postgres, we have been able to build a whole host of data types. And so now you see Postgres being used not just as the context of a traditional relational database, but we see it used as a time-series database. You pointed out a geospatial database, more and more is a document-oriented database with JSON and JSONB.

These are all the things that make Postgres have much more universal appeal, universal appeal to developers—which is worth talking about in the recent StackOverflow developer survey, but we can come back to that—and I think universal applicability for new applications. This is what’s bringing Postgres forward faster, unlike many of the specialty database companies that you mentioned earlier.

Corey: Now, this is something that you can use for your traditional CRUD app, the my first hello world app that returns something from a database, yeah, that stuff works. But it also, for example, has [cyter 00:25:09] data types, where you can say, give me the results where the IP range contains this address, and it’ll do that. Before that, you’re trying to solve a whole bunch of very messy things in application logic that’s generally awful. The database now does that for you automatically, and there’s something—well, it would if I were smart and used it instead of storing it as strings because I make terrible life choices, but for sensible people, it solves a lot of those problems super well. And it’s taken the idea of where logic should live in application versus database, and sort of turn a lot of those assumptions I was starting my career with on their head.

Ed: Yeah, I think if you look now at the appeal of Postgres to developers, which we’ve paid a lot of attention to—one of our stated strategies at EDB is to make Postgres easier. That’s been true for many years, so a drive for engineering and development here has been that call to action. And if you measure that, over time, we’ve been contributing—not alone, but contributing to making Postgres more approachable, easier to use, easier to engage with. Some of those things we do just through edb.com, and the way we handle EDB docs is a great example of that, and our developer advocacy and outreach into adjacent communities that care about Postgres. But here’s where that’s landed us. If you looked at the last Stack Overflow developer survey—the 2021 Stack Overflow developer survey, which I love because I think it’s very independent-oriented—and they surveyed, I think this past year was 80,000 developers.

Corey: Oh yeah, if Stack Overflow is captured by any particular constituency, it’s got to be ‘Big Copy and Paste’ that is really behind them. But yeah, other than the cabal of keyboard manufacturers for those copy-and-paste stories, yeah, they’re fairly objective when it comes to stuff like this.

Ed: And if you look at that survey, Corey, if you just took and summed it because it’s helpful to sum it, most used, most loved, and most wanted database: Postgres wins. And I find it fascinating that if you—having been here, in this company for 13 years and watch the evolution from—you know, 13 years ago, Postgres needed help, both in terms of its awareness in the market and some technical capabilities it just lacked, we’ve come so far. For that to be the new standard for developers, I think, is a remarkable achievement. And I think it’s a representation of why Postgres is doing so well in the market that we’ve long served, in the cloud market that we are now serving, and I think it speaks to what’s ahead as a transformational database for the future.

Corey: There really is something to be said for a technology as—please don’t take this term the wrong way—old. As a relational database, Postgres has been around for a very long time, but it’s also not your grandparents’ Postgres. It is continuing to evolve. It continues to be there in a bunch of really interesting ways for developers in a variety of different capacities, and it’s not the sort of thing that you’re only using in, “Legacy environments,” quote-unquote. Instead, it’s something that you’ll see all over the place. It is rare that I see an environment that doesn’t have Postgres in it somewhere these days.

Ed: Yeah, I think quite the contrary to the old-school database, which I love that; I love that shade because when you step away from it, you realize, the Postgres community represents the very best of what’s possible with open-source. And that’s why Postgres continues to accelerate and move forward at the rate that it does. And obviously, we’re proud to be a contributor to that, so we don’t just watch that outcome happen; we’re actually part of creating it. But I also think that when you see all that Postgres has become and where it’s going, you really start to understand why the market is adopting open-source.

Corey: It’s one of those areas where even if some company comes out with something that is amazing and transformatively better, and you should jump into it with both feet and never look back, yeah, it turns out that it takes a long time to move databases, even when they’re terrible. And you can lobby an awful lot of accusations at Postgres—or Postgres-squeal—but you can’t call it terrible. It’s used in enough interesting applications by enough large-scale companies out there—and small as well—that it’s very hard to find a reason not to explore it. It’s my default relational database when Route 53 loses steam. It just makes sense in a bunch of ways that other things really didn’t for me before.

Ed: Yeah, and I think we’ll continue to see that. And we’re just going to keep making Postgres better. And it gets better because of that intersection, as I mentioned, that intimate intersection between enterprise users, and the project, and the community, and the bridge that a company like EDB provides for that. That’s why it’ll get better faster; the breadth of use of Postgres will keep it accelerating. And I think it’s different than many of the specialty databases.

Look, I’ve been in open-source now for 20 years and it’s intriguing to me how many new specialty open-source databases have come to market. We tend to forget the amount of roadkill we’ve had over the course of the past ten years of some of those open-source projects and companies. We certainly are tuned into some of the more prolific ones, even today. And I think again, here again, this is where Postgres shines, and where I think Postgres is a better call for a long-term. Just like Linux was.

Corey: I want to thank you for taking so much time out of your day to talk to me about databases, which given my proclivities, is probably like pulling teeth for you. If people want to learn more, where can they find you?

Ed: So, come to enterprisedb.com. You still get EnterpriseDB, Corey. Just come to enterprise—

Corey: There we go. It’s hidden in the URL, right in plain sight.

Ed: Come to enterprisedb.com. You can learn all the things you need about the technology, and certainly more that we can do to help you.

Corey: And we will, of course, put links to that in the [show notes 00:31:10]. Thank you once again for your time. I really do appreciate it.

Ed: Thanks, Corey. My pleasure.

Corey: Ed Boyajian, CEO of EDB. I’m Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you’ve enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you’ve hated this podcast, please leave a five-star review on your podcast platform of choice along with a long angry comment because you are one of the two Amazonian developers working on open-source databases.

Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.

Announcer: This has been a HumblePod production. Stay humble.