Screaming in the Cloud - At the Helm of Starship EDB with Ed Boyajian

Episode Date: November 2, 2021

About EdEd Boyajian, President and CEO of EDB, drives the development and execution of EDB’s strategic vision and growth strategy in the database industry, steering the company through 47 consecutive quarters of recurring revenue growth. He also led EDB’s acquisition of 2ndQuadrant, a deal that brought together the world’s top PostgreSQL experts and positioned EDB as the largest dedicated provider of PostgreSQL products and solutions worldwide. A 15+ year veteran of the open source software movement, Ed is a seasoned enterprise software executive who emphasizes that EDB must be a technology-first business in order to lead the open source data management ecosystem. Ed joined EDB in 2008 after serving at Red Hat, where he rose to Vice President and General Manager of North America. While there, he played a central leadership role in the development of the modern business model for bringing open source to enterprises.Links:EDB: https://enterprisedb.com

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. 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 slash screaming in the cloud. Observability, it's more than just hipster monitoring. 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 insight 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. And 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. That's jellyfish.co and tell them Corey sent you. Watch for the wince. That's my favorite part. Welcome to Screaming in the Cloud. I'm Corey Quinn. Today's promoted episode is a treasure and a delight. Longtime listeners of the 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. Long-time 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 Postgresquil database. Ed, thank you for joining me. Hey, Corey. So I know that other people pronounce it Postgree, PostgresSQL, PostgresQL, all kinds of other things. We know it's decidedly not Postgresquil, which is how I go for it. How do you pronounce it?

We say Postgres, and this is one of the great branding challenges this fantastic open source project has endured over many years. So I want to start at the very beginning, because when I say that you folks are the driving force behind Postgres or PostgresQL, 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 in 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 Quill. 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 code base. How do you engage with an open source project in that sense? 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' 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. I'd like to explore a little bit, well, first and foremost, the 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 running their own databases in the year of our Lord 2021,

rather than just using whatever managed dingus their cloud provider of choice today is offering for them? 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, land on Postgres, and then write new apps. Probably the first 10 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 the

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. 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 reInvent 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 NoSQL 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 where 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 offer managed database offerings. Where do those make sense and where do they fall down? 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 has been that early, early. Yeah, five-year head start makes a pretty compelling story. 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, and easy on-ramp, and they traded some capability and 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 environment, 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 kind of 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 kind of 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. 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, 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? So I think there's a few things that our customers are clearly telling us they want. I think this is the most important thing. They want control of their data. And if you step back, Corey, and 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 kind of the successes Oracle's had that 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 replatforming that happened the trans 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 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. 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 ex Exodus, where Google's cloud spanner is fascinating. DynamoDB is revelatory. CosmosDB 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 just don't see it. Yeah, I think you're bringing up a really important point. So let's unpack it for a minute, 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. Postgres superpowers 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 the website and have a database on the back end. All areas Postgres has done incredibly well and we have customer experience with.

So when you kind of 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. Now, 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. 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 it inside of their account or environment? Is it something else? 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 a 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 client's 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. 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 EDP these days? So we have over 650 employees. Now, around the world, we have 6,000 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. 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. 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 at Red Hat for a little over six years. So I've been in 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. You know, roughly a little less than a third of the last, it's 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. 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 that is rich and full of IT and engineering professionals. You wouldn't think those things go together, but sometimes they do. It's both useful for individuals and large enterprises, but here's what makes this something 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 $2,000 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 slash Corey, C-O-R-E-Y. That's cloudacademy.com slash Corey. We're going to have some fun with this one. Something else that does strike me is, I guess, strange. And 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 Enterprise DB, 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 services capacity, and they were great at this. Is EDB a services company or a product company? 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

and 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. And the screaming, help, help, help, fix it, fix it, fix it now emergencies as well. I think we have the best Postgres support operation in the world. It is a global 24 by 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. 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 their own ones. And if it hadn't been important, and it was, it was also noteworthy. With many vendors that are product-focused, their services may as well have an asterisk next to it because it's either a buy our product and then we'll support it, or it's, oh, 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. Well, I'm glad you had that 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 the bottom of the second inning. So we've been able to listen and learn from the experiences our customers have had.

And I think that's an incredible advantage as we now, you know, firmly plan ourselves in the cloud D-BAS market alongside our robust Postgres capabilities that you experienced. The world isn't generating less data, and it's important that we're able to access that in a bunch of different ways. 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 has really struck me since the last time I went deep into database land over in the Postgresquil world has been just 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, what sort of use cases people are really putting these things into? 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 advisor 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, you know, not just as the context of a traditional relational database, but we see it be used as a know, not just as the context of a traditional relational database, but we see it be used as a time series database, as you pointed out, a geospatial

database, more and more as 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 Stack Overflow 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. Yeah, 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 CIDR 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 turned a lot of those assumptions I was starting my career with on their head. 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 edbdocs 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 survey, I think this past year was 80,000 developers. 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. 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 watched the evolution from, you know, 13 years ago, Postgres needed help, both in terms of its awareness in the market and some technical capabilities that 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'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. 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. Yeah, I think quite the contrary to the old school database, which I love that. I love that shade because, you know, 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. 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 Postgresquil, 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. 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 10 years of some of those open source projects have come to market. We tend to forget the amount of roadkill we've had over the course of the past 10 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. 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? So come to EnterpriseDB.com. You still get EnterpriseDB, Corey. There we go. It's hidden in the URL, right in plain sight. 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. And we will, of course, put links to that in the show notes. Thank you once again for your time. I really do appreciate it. Thanks, Corey. My pleasure. 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. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill

by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started. This has been a HumblePod production. Stay humble.