Screaming in the Cloud - Cloud-Hosted Database Services with Benjamin Anderson

Episode Date: July 21, 2022

About BenjaminBenjamin Anderson is CTO, Cloud at EDB, where he is responsible for developing and driving strategy for the company’s Postgres-based cloud offerings. Ben brings over ten years’ experience building and running distributed database systems in the cloud for multiple startups and large enterprises. Prior to EDB, he served as chief architect of IBM’s Cloud Databases organization, built an SRE practice at database startup Cloudant, and founded a Y Combinator-funded hardware startup.Links Referenced:EDB: https://www.enterprisedb.com/BigAnimal: biganimal.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. I come bearing ill tidings. Developers are responsible for more than ever these days.

Not just the code that they write, but also the containers and the cloud infrastructure that their apps run on because serverless means it's still somebody's problem. And a big part of that responsibility is app security from code to cloud. And that's where our friend Snyk comes in. Snyk is a frictionless security platform that meets developers where they are, finding and fixing vulnerabilities right from the CLI, IDEs, repos, and pipelines. Snyk integrates seamlessly with AWS offerings like CodePipeline, EKS, ECR, and more, as well as things you're likely to actually be using. Deploy on AWS, secure with Snyk, learn more at snyk.co.scream. That's s-n-y-k dot c-o slash scream.

This episode is sponsored in part by our friends at Fortinet. Fortinet's partnership with AWS is a better together combination that ensures your workloads on AWS are protected by best-in-class security solutions powered by comprehensive threat intelligence and more than 20 years of cybersecurity experience. Integrations with key AWS services simplify security management, ensure full visibility across environments, and provide broad protection across your workloads and applications. Visit them at AWS Reinforce to see the latest trends in cybersecurity on July 25th to 26th at the Boston Convention Center. Just go over to the Fortinet

booth and tell them Corey Quinn sent you and watch for the flinch. My thanks again to my friends at Fortinet. Welcome to Screaming in the Cloud. I'm Corey Quinn. This promoted guest episode is brought to us by our friends at EDB. And not only do they bring us this promoted episode, they bring me their CTO for cloud, Benjamin Anderson. Benjamin, thank you so much for agreeing to suffer the slings and arrows that I will no doubt throw at you in a professional context because EDB is a database company and I suck at those things. Thanks, Corey. Nice to be here.

Of course. So databases are an interesting and varied space. So I think we can all agree or agree to disagree that the best database is, of course, Route 53 when you misuse text records as a database. Everything else is generally vying for number two. EDB was, back in the days that I was your customer, was EnterpriseDB, now rebranded as EDB, which is way faster to say, and I approve of that. But you were always the escalation point of last resort. When you're stuck with a really weird and interesting Postgres problem, EDB was where you went, because if you folks couldn't solve the problem, it was likely not going to get solved. I always contextualized you folks as a consulting shop. That's not really what get solved. I always contextualize to you folks, as a consulting shop,

that's not really what you do. You are the CTO for cloud. And, ah, interesting, do databases behave differently in cloud environments? Well, they do when you host them as a managed service, which is an area you folks have somewhat recently branched into. How did you get there? Ah, that's interesting. So there's a bunch of stuff to unpack there.

I think EDB has been around for a long time. It's something like 13, 14, 15 years, something like that. And really has just been kind of slowly growing, right? We did start very much as a product company. We built some technology to help customers get from Oracle database on to Postgres way back in 2007, 2008. And that business has just slowly been growing and it's going quite well. Frankly, I only joined about 18 months ago

and it's really cool tech, right? Like we natively understand some things that Oracle is doing. Customers don't have to change their schemas to migrate from Oracle to Postgres. There's some cool technology in there. But as you point out, I think a lot of our position in the market

has not been that product focus. There's been a lot of our position in the market has not been that product focused. There's been a lot of people seeing us as the Postgres experts and as people who can solve Postgres problems in general. We have, for a long time, employed a lot of really sharp Postgres people. We still employ a lot of really sharp Postgres people. And that's very much, in a lot of ways, our bread and butter, that we're going to fix Postgres problems as they come up.

Now, over the past few years, we've definitely tried to shift quite a bit into being more of a product company. We've brought on a bunch of people who have been doing more enterprise software product type development over the past few years, and really focusing ourselves more and more on building products and investing in ourselves as a product company. We're not a services company. We're not a consulting company. We do, I think, provide the best Postgres support in the market. But it's been a journey. The cloud has been a significant part of that as well, right? Like, you can't get away. Oh, yeah. These days, when someone's spinning up a new workload, it's unlikely, in most cases,

they're going to wind up spinning up a new data center if they don't already have one. Yes, there's still a whole bunch of on-prem workloads, but increasingly, the default has become cloud. Instead of why cloud, the question has become why not. Right, right, exactly. And then as people are more and more accepting of managed services, you have to be a product company. You have to be building products in order to support your database customers because what they want is managed services. I was working in managed databases and service something like 10 years ago, and it was like pulling teeth. This is after RDS launched, but this was still pulling teeth trying to get people to think about, oh, I'm going to let you run my database.

Whereas now, obviously, it's just completely different. And, you know, we have to build great products in order to succeed in the database business in general. One thing that jumped out at me when you first announced this was the URL is enterprisedb.com. That doesn't exactly speak to, you know, non-large companies. And EDB is what you do, your very corporate logo, but your managed service is called Big Animal, which I absolutely love. It actually expresses a sense of whimsy and personality that I can no doubt guess that a whole bunch of people argued against, but big animal it is. It won through. I love that. Was that as contentious as I'm painting it to be, or people actually have a sense of humor sometimes? Both. It was extremely contentious. I, frankly, was one of the people who was not in favor of it at first. I was in favor of something doing that was whimsical,

but maybe not quite that whimsical. Well, I call it post-grasqueal, so let's be very clear here that we're probably not going to see Ida on most naming and pronunciation things. But we can set those differences aside and have a conversation. Absolutely, no concern there. It was deliberate, though, to try to step away a little bit

from the sort of blue suit and tie enterprise DB type branding. Obviously, a lot of our customers are big enterprises. We're good at that. We're not trying to be the hip, young startup targeting business in a lot of ways. We have a wide range of customers, but we want to branch out a little bit. One of the challenges right now is if I spin up an environment inside of AWS, as one does,

and I decide I certainly don't want to take the traditional approach of running a database on top of an EC2 instance the way that we did in the olden days because RDS was crappy. And now that it's slightly less crappy, that becomes a not ideal path. And I start looking at their managed database offerings, and there are something like 15 distinct managed databases that they offer. And they never turn anything off, and they continue to launch things into the far future. And it really feels on some level, like 20 years from now, what we call a DBA today, their primary role is going to look a lot more like helping a company figure out which of Amazon's 40 managed databases is the appropriate fit for this given workload.

Yet when I look around at what the industry has done, it seems that when we're talking about relational databases, Postgres has emerged. Back when I was more or less abusing servers in person in my data center days, it was always my SQL. These days, Postgres is the de facto standard full stop. I admit that I was mostly keeping my aura away from any data that was irreplaceable at that time. What happened? What did I miss? It's a really good question. I certainly

am not 100% on all the trends that went on there. I know there's a lot of folks that are not happy about the MySQL acquisition by Oracle. I think there's a lot of energy that was adopted by the NoSQL movement as well. You have people who didn't really care about transactional semantics that were using MySQL because they needed a place to store their data. And then things like MongoDB and that type of system comes along where it's significantly easier than MySQL, and that subset of the population just sort of drifts away from MySQL. Yeah, and in turn, those NoSQL projects eventually turn into something where, okay, now we're trying to build a banking system on top of it,

and it's, you know, I guess you can use a torque wrench as a hammer if you're really creative about it, but it seems like there's a better approach. Yeah, exactly. And those folks are coming back around the relation of databases, exactly. At the same time, the advancements in Postgres from the early 8 series to today are significant, right? Like, we shouldn't underestimate how much Postgres has really moved forward. It wasn't that long ago that replication was hardly a thing in Postgres, right? I mean, it's been a journey. One thing that your website talks about is that you accelerate your open source database transformation.

And this is a bit of a hobby horse I get on from time to time. I think that there are a lot of misunderstandings when people talk about this. You have the open source purists, of which I shamefully admit I used to be one, saying that, oh, it's about the idea of purity and open and free as in software. Great. Okay. Awesome. But what I find that corporate customers are talking about when they say open source database, they don't particularly care if they have access to the source code because they're not going to go in and patch a database engine, we hope. But what they do care about is, regardless of where they are today, even if they're perfectly happy there, they don't want to wind up beholden

to a commercial database provider and or they don't want to wind up beholden to the environment that that is running within. There's a strategic exodus that's available in theory, which on some level serves to make people feel better about not actually exodusing. But it also means if they're doing a migration at some point, they don't also have to completely redo their entire data plane. Yeah, I think that's a really good point. I mean, I like to talk, there's a big rat's nest of questions and problems in here, but I generally like to talk about open APIs, talk about standards, talk about how much is going to have to change if you eliminate this vendor. We're definitely not open source purists. Well, we employ a lot of open source purists.

I also used to be- Don't let them hear you say that then. Fair enough, fair enough. We have proprietary software at EDB as well. I mean, there's a kind of wide range of businesses that we participate in. I'm glad to hear you also mention the sort of where it's hosted angle as well.

I think there's some degree to which people are, they've figured out that having at least open APIs or an open source-ish database is a good idea rather than being beholden to a proprietary database. But then immediately forget that when they're picking a cloud vendor, right? And realizing that putting their data in cloud vendor A versus cloud vendor B is also putting them in a similar difficult situation. They need to be really wary of when they're doing that. Obviously, I work at an independent software company, and I have some incentives to say this, but I do think it's true. And, you know, there's meaningful data gravity risk. I assure you, I have no incentive. I don't care what cloud provider you're on. My guidance has been for years to, as a general rule, pick a provider, I care not which one, and go all in. And until there's a

significant reason to switch, trying to build an optionality of, oh, everything we do should be fully portable at an instance notice. Great. Unless you're actually doing it, you're more or less giving up a whole bunch of shortcuts and feature velocity you could otherwise have in the hopes of one day you'll do a thing, but all the assumptions you're surrounded by bake themselves in regardless. So you're more or less just creating extra work for yourself for no defined benefit. This is not popular in some circles where people try to sell something that requires someone to go multi-cloud, but here we are. No, I think you're right. I think people underestimate the degree to which

the abstractions are just not very good, right? And the degree to which those cloud-specific details are going to leak in if you're going to try to get anything done, you end up in kind of a difficult place. What I see more frequently is situations where we have a big enterprise, not even big, even medium-sized companies, where maybe they've done an acquisition or two, they've got business units that are trying to do things on their own, and they end up in two or three clouds sort of by happenstance. It's not like they're trying to do replication live between two clouds, but they've got one business unit in AWS and one business unit in Azure. And somebody in the corporate, say, enterprise architecture or something like that

really would like to make things consistent between the two so they get a consistent security posture and things like that. So there are situations where multi-cloud is a reality at a certain level, but maybe not at a concrete technical level, but I think it's still really useful for a lot of customers. You position your cloud offering in two different ways. One of them is the idea of big animal, and the other, well, it sort of harkens back to when I was in sixth grade going through the American public school system. They had a cop come in and talk to us and painted this imaginary story of people trying to push drugs. I was like, hey, kid, you want to try some of this? And I'm reading this and it says, EDB Postgres for Kubernetes. And I'm sent back

there where it's like, hey, kid, you want to run your stateful databases on top of Kubernetes? And my default answer to that is, good lord no, what am I missing? That's a good question. Kubernetes has come a long way, I think, as part of that. Oh, truly. I used to think of containers as a pure story for stateless things, and then, of course, I put state into them, and then everything exploded everywhere, because it turns out I'm bad at computers. Great. And it has come a long way. I have been tracking a lot of that, but it still feels like the idea being that you'd want to have your database endpoints somewhere a lot less, I guess I'll call it fickle, if that makes sense. It's an interesting problem space. We are seeing

a lot of people who are interested in our Kubernetes-based products. It's actually based on, we recently open sourced the core of it under a project called Cloud Native PG. It's a cool piece of technology. If you think about a sort of two-by-two where you've got in one corner, you've got self-managed on-premise databases, so you're very, very slow-moving, big iron type, old-school database deployments. And on the opposite corner, you've got fully managed in the cloud, big animal, Amazon RDS, that type of thing. There's a place on that map where you've got customers that want a self-service type experience, whether that's for production or maybe it's even for dev tests, something like that. But you don't want to be giving the management capability off to a third party.

For folks that want that type of experience, trying to build that themselves by like wiring up EC2 instances or doing something in their own data center with VMware or something like that can be extremely difficult. Whereas if you go to a Kubernetes-based product, you can get that type of self-service experience really easily, right? And customers can get a lot more flexibility out of how they run their databases

and operate their databases and what sort of control they give to, say, application developers who want to spin up a new database for a test or for some sort of small microservice, that type of thing. Those types of workloads tend to work really well with the first-party Kubernetes-based offering. I've been doing databases on Kubernetes

in managed services for a long time as well, and I don't, frankly, have any concerns about doing it. There are definitely some sharp edges, and if you want to do it at scale, you need to really know what you're doing with Kubernetes, because the naive thing will shoot you in the foot. Oh, yes. On some level, it feels almost like people want to cosplay working for Google, but they don't want to pass the technical interview along the way. It's a bit of a weird moment for it. Yeah, I would agree. I have to go back to my own experiences

with using RDS back in my last real job before I went down this path. We were migrating from EC2 Classic to VPC. So you could imagine that dates me reasonably effectively. And the big problem was the database. And the joy that we had was, okay, we have to quiesce the application

so the database is now quiet, stop writes, take a snapshot, restore that snapshot into the environment. And whenever we talked to AWS folks, like, so how long is this going to take? And the answer was, guess. And that was not exactly reassuring. It went off without a hitch because every migration has one problem. We were sideswiped in an Uber on the way home, but that's neither here nor there. It was 2 o'clock in the morning, and we finished in half the maintenance time we'd allotted. But it was the fact that, well, I guess we're going to have to take the database down for many hours with no real visibility, and we hope it'll be up by morning.

That wasn't great, but that was the big one. Going on on an ongoing basis, there were maintenance windows where the database would just stop databasing for a period of time during a fairly broad maintenance window. And that led to a whole lot of unfortunate associations in my mind with using relational databases for an awful lot of stuff. How do you handle maintenance windows and upgrading and not tearing down someone's application? Because I have to assume that, oh, we just never patch anything. It turns out that's way easier is, in fact, the wrong answer. Yeah, definitely. As you point out, there's a bunch of fundamental limitations here.

If we start to talk about how Postgres actually fits together, pretty much everybody, RDS is a little bit weird. The older RDS offerings are a little bit weird in terms of how they do replication. But most folks are using Postgres streaming replication to do high availability Postgres in managed services. And honestly, of course... Because you have a VIP that winds up failing over or the application's aware of both endpoints and switches to the other one?

Yeah, yeah. And that... Sort of database pooling connection or some sort of proxy? Right. There's a bunch of subtleties that get into there where you say, well, did the VIP fail over too early? Do my application try to connect and start making requests before the secondary is available? That sort of thing. Or you misconfigure it and point to the secondary, and suddenly

when there's a switchover of some database, suddenly nothing can write, it can only read, and then you cause a massive outage on the weekend. Yeah, that may have been an actual story I made up there. Yeah, you should use a managed service. So it's complicated, but even with managed services, you end up in situations where you have downtime, you have maintenance windows. And with Postgres, especially in other databases as well, especially with Postgres,

one of the biggest concerns you have is major version upgrades, right? If I want to go from Postgres 12 to 13, 13 to 14, I can't do that live. I can't have a single cluster that is streaming one Postgres version to another Postgres version, right? So every year, you know, people want to put things off for two years, three years sometimes, which is obviously not to their benefit. You have this maintenance. You have some sort of downtime

where you perform a Postgres upgrade. At EDB, we've got, so obviously this is a big problem. This is a problem for us. We're involved in the Postgres community. We know this is challenging. That's kind of just a well-known thing. Some of the folks that work at EDB

are folks who worked on the Postgres logical replication tech, which arrived in Postgres 10. Logical replication is really a nice tool for doing things like change data capture. You can do like Walt at JSON. All these types of things are based on logical replication tech. It's not really a thing, at least the code that's in Postgres itself doesn't really support high availability, though. It's not really something that you can use to build a leader-follower type cluster on top of. We have some tech, some proprietary tech within EDB that used to be called bidirectional replication.

There used to be an open-source project called bidirectional replication. This is kind of a descendant of that. It's now called Postgres Distributed, or EDB Postgres Distributed is the product name. And that tech actually allows us, because it's based on logical replication, allows us to do multiple major versions at the same time, right? So we can upgrade one node in a cluster to Postgres 14, while the other nodes in

the clusters are at Postgres 13. We can then upgrade the next node. We can support these types of operations in a kind of wide range of maintenance operations without taking a cluster down from maintenance, right? So there's a lot of interesting opportunities here when we start to say, well, let's step back from what your typical assumptions are for Postgres streaming replication, give ourselves a little bit more freedom by using logical replication instead of physical streaming replication, and then what type of services, what type of patterns can we build on top of that that ultimately help customers build, whether it's faster databases, more highly available databases, and so on and so forth.

Let's face it, on-call firefighting at 2 a.m. is stressful. So there's good news and there's bad news. The bad news is that you probably can't prevent incidents from happening. But the good news is that Incident.io makes incidents less stressful and a lot more valuable. Incident.io is a Slack-native incident management platform that allows you to automate incident processes, focus on fixing the issues, and learn from incident insights

to improve site reliability and fix your vulnerabilities. Try Incident.io to recover faster and sleep more. One approach that I took for, I guess you could call it backup sort of, was intentionally staggering replication between the primary and the replica about 15 minutes or so. So if I drop a production table or something like that,

I have 15 short minutes to realize what has happened and sever the replication before it is now committed to the replica. And now I'm living in hell. It felt like this was not like option A, B, or C and the right way to do things. But given that meeting customers where they are is important, is that the sort of thing that you support with Big Animal? Or do you try and talk customers into not being ridiculous? That's not something we support now. It's not actually something that I hear that many asks for these days. It's kind of interesting.

Like, that's a pattern that I've run into a lot in the past. I was an ancient grumpy citizen. Again, I'm dating myself here. These days, I just store everything in DNS text records, and it's way easier. But I digress. Yeah, it's something that we see a lot for. We have support for point-in-time restore, like pretty much anybody else in the business at this point, and that's usually the I fat-fingered something type response. Honestly, I think there's room to be a bit more flexible and

room to do some more interesting things. I think RDS is setting a bar, and a lot of database services out there are kind of just meeting that bar. And we all kind of need to be pushing a little bit more into more interesting spaces and figuring out how to get customers more value, get customers to just get more out of their money for the database, honestly. it's a pretty thin and blurry line between database advocate, database evangelist, and database zealot, where it feels like instead we're arguing about religion more than actual technical constraints and concerns. So here's a fun question that hopefully isn't too much of a gotcha, but what sort of workloads would you actively advise someone not to use Big Animal for in the database world? But yes, again, if you're trying to run a DNS server,

it's probably not fit for purpose without at least a shim in the way there. But what sort of workloads are you not targeting that a customer is likely to have a relatively unfortunate time with? Large-scale analytical workloads are the easy answer to that, right? If you've got a problem where you're choosing between Postgres and Snowflake, and you're seriously considering, you actually have as much data that you'd seriouslygres and Snowflake, and you're seriously considering, you actually have as much data that you'd seriously be considering Snowflake,

you probably don't want to be using Postgres, right? You want to be using something that's Columnar. You want to be using a query planner that really understands a Columnar layout. It's going to get you the sorts of performance that you need for those analytical workloads. We don't try to touch that space. Yeah, we're doing some of that right now

with just the sheer volume of client AWS bills we have. We don't really need a relational model for a lot of it. And Athena has basically fallen down on the job in some cases. And, oh, do you want to use Redshift? That's basically Postgres. It's like, yeah, it's Postgres if it decided to run on bars of gold.

No thank you. It just becomes this ridiculously overwrought solution for what feels like it should be a lot similar. So it's weird. Six months ago or so, I wouldn't have had much of an idea of what you're talking about. I see it a lot better now, generally by virtue of trying to do something the precise wrong way than someone should. Right, right. Yeah, exactly. I think there's interesting room for Postgres to expand here. It's not something that we're actively working on. I'm not aware of a lot happening in the community. Postgres is, for better or worse, extremely extensible. You see the JSON support in Postgres that didn't exist, I don't know, five, six years ago. And now it's

incredibly powerful. It's incredibly flexible. And you can do a lot of, quote unquote, schema-less stuff straight in Postgres. Or you look at PostGIS for doing GIS, geographical data. That's really a fantastic integration directly in the database. Before that, people, for doing GIS, geographical data, right? Like, that's really a fantastic integration directly in the database. Yeah, before that, people start doing ridiculous things that almost look similar to a graph database or a columnar store somehow, and yeah. Yeah, exactly. I think sometimes somebody will do a good column store

that's an open source, like deeply integrated into Postgres rather than... I've seen someone build one on top of it that has the Rebucket that had a quarter of a trillion objects in it. Professional advice, don't do that. Unless you're Snowflake. So, I mean, it's something that I'd like to see Postgres expand into. I think that's an interesting space, but not something that,

at least, especially for Big Animal and, frankly, for a lot of EDB customers, it's not something we're trying to push people toward. One thing that I think we are seeing a schism around is the idea that some vendors are on one side of it, some are on the other. Where on the one side you have, oh, every workload should have a bespoke purpose-built database that is exactly for this type of workload. And the other school of thought is you should generally buy us for a general purpose database until you have a workload that is scaled and significant to a point where running that on its own purpose-built database begins to make sense. I don't necessarily think that that is a binary choice. Where do you tend to fall on that spectrum? I think everybody should use Postgres. And I say this not just because I work at a Postgres company. Let's be clear, before this, you were at IBM for five

years working on a whole bunch of database stuff over there, not just Postgres. And you so far have not struck me as the kind of person who's like, oh, so what's your favorite database? The one that pays me. We've met people like that, let's be very clear, but you seem very even-handed in that conversation.

I got my start in databases actually with Apache CouchDB. I'm a committer on CouchDB. I worked on a managed CouchDB service 10 years ago. At IBM, I worked on something in nine different open-source databases in managed services.

But I love having conversations about, like, well, I've got this workload should i use postgres should i use mongo should use cassandra all of those types of discussions frankly though i think in a lot of cases people are they don't understand how much power they're missing out on if they don't choose a relational database like they don't understand the relational model well enough to understand that they really actually want that in a lot lot of cases, people are also just over-optimizing too early. It's just going to be much faster for them to get off the ground, get product in customers' hands if they start with something that they don't have to think twice about. And they don't end up with this architecture with 45 different databases, and there's only one guy in the company that knows how

to manage the whole thing. Oh, same story with picking a cloud provider. It's okay, you hire a team, you're going to build a thing. Which cloud provider do you pick? Every cloud provider has a whole matrix and sales deck and the rest. And the right answer, of course, is the one your team's already familiar with, because learning a new cloud provider while trying not to run out of money at your startup generally doesn't work super well. Exactly, yeah. One thing that I think's been sort of interesting, and when I saw it, it was one of those, oh, I sort of like them because I have that instinctive reaction. I don't think I'm alone in this. As of this recording, a couple weeks ago, you folks received a sizable investment from private equity.

And default reaction to that is, oh, well, I guess I put a fork in the company. They're done because the narrative is that once private equity takes an investment, well, that company's best days are probably not in front of it. Now, the counterpoint is, is that this is not the first time private equity has invested in EDB. And you folks, from what I can tell, are significantly better than you were when I was your customer a decade ago. So clearly there is something wrong with that mental model. What am I missing? Yeah, frankly, I don't know. I'm no expert in funding models and all of those sorts of things. I will say that my experience has been, and what I've seen at EDB has definitely been that maybe there's private equity and then there's private equity. We're in this to build better products and become a better product company. We were previously owned by a private equity firm for the past four years or so.

And during the course of those four years, we brought on a bunch of folks who were very product-focused, new leadership. We made a significant acquisition of a company called Second Quadrant, which they employed a lot of, kind of the European best postgres company. Now they're part of EDB, and most of them have stayed with us. And we built the managed cloud service, right? So this is a pretty significant private equity company buying us to invest in the company, and I'm optimistic that that's what we're looking at going forward. I want to be clear as well that I'm not worried about what I normally would be in a private equity story about this, where they're there to save money and cut costs. And do we really need all these database replicas floating around? And these backups, seems like that's something we don't need. You have, at last count, 32 Postgres contributors, seven Postgres committers, and three

core members, all of whom would run away screaming loudly and publicly in the event that such a thing were taking place. I mean, of all the challenges and concerns I might have about someone running a cloud service in the modern day, I do not have any fear that you folks are not doing what will very clearly be shown to be the right thing by your customers for the technology that you're building on top of. That is not a concern. There are companies I do not have that confidence in, to be clear. Yeah, I'm glad to hear that, Matt. I'm 100% on board as well. I mean, I work here, but I think we're doing the right thing, and we're going to be doing great stuff going forward. One last topic I do want to get into a little bit is, on some level, launching in this decade, a cloud-hosted database offering at a time when Amazon, whose product strategy of yes is in full display, it seems like something ridiculous that is not necessarily well thought out.

Why would you ever try to do this? Now, I will temper that by the fact that you are clearly succeeding in this direction. You have customers who say nice things about you, and the reviews have been almost universally positive anywhere I can see things. The negative ones are largely complaining about databases, which, I admit, might be coming from me. Right. It is a crowded space. There's a lot of things happening. Obviously, Amazon, Microsoft, Google are doing great things, both kind of... Terrible things, but great. Yes, yes. Right. There's good products coming out. I think AlloyDB is a great, not necessarily a great

product. I haven't used it myself yet, but it's an interesting step in the direction. I'm excited to see development happening. But at the end of the day, we're a database company. Our focus is on building great databases and supporting great databases. We're not entering this business to try to take on Amazon from an infrastructure point of view. In fact, the way that we're structuring the product is really to try to get the strengths of both worlds, right? We want to give customers the ability to get the most out of the AWS or Azure infrastructure that they can, but come to us for their database, right? We just, frankly, we know Postgres better than anybody else. We have a greater ability to get bugs fixed in Postgres than anybody else.

We've got folks working on the database in the open. We've got folks working on the database proprietary for us. So we give customers things like break-fix support on that database. If there is a bug in Postgres, there's a bug in the tech that sits around Postgres, because obviously Postgres is not a batteries-included system, really, we're going to fix that for you. And that's part of the contract that we're giving to our customers. And I know a lot of smaller companies

maybe haven't been burned by this sort of thing very much. We start to talk about enterprise customers and medium, larger-scale customers. This starts to get really valuable, right? The ability to have assurance on top of your open-source product. So I think there's a lot of interesting things there, a lot of value that we can provide there. I think also that,

I talked a little bit about this earlier, but like the box, this sort of RDS shaped box, I think is a bit too small. And there's an opportunity for smaller players to come in and try to push the boundaries of that. For example, giving customers more support by default to do a good job using their database, right?

We have folks on board that can help consult with customers to say, no, you shouldn't be designing your schemas that way. You should be designing your schemas this way. You should be using indexes here, that sort of stuff. That's been part of our business for a long time. Now with a managed service, we can bake that right into the managed service. And that gives us the ability to kind of make that, you know, you talk about shared responsibility between the service provider and the customer. We can change the boundaries of that shared responsibility a little bit so that customers can get more value out of the managed database service than they might expect otherwise. There aren't these harsh separations and clearly defined lines across which nothing shall pass when it makes sense to do that in a controlled, responsible way. Right, exactly. Some of that is because we're a database company, and some of that is because, frankly,

we're much smaller. I'll take it a step further beyond that as well. I have seen this pattern evolve a number of times where you have a customer running databases on EC2, and their AWS account manager suggests, ah, move to RDS. So they do. And then, ah, move to Aurora. So they do. And then, ah, move this to DynamoDB. And at which point it's like, what do you think your job is here exactly? Because it seems like every time we move databases, you show up in a nicer car. So what exactly is the story here and what are the incentives? Where it just feels like there is a, whatever you're doing is not the way that it should be done, so it's time to do yet another migration. There's something to be said for companies who are focused around a specific aspect of things. And then once that is up and working and running, great, keep on going. This is fine. As opposed to trying to chase the latest shiny on some level. Right. I have a big sense of, I guess, affinity for companies that wind up knowing where they start and most notably

where they stop. Yeah, yeah. I think that's a really good point. I don't think that we will be building an application platform anytime soon. You're going to run Lambda functions on top of a database. It's like, congratulations. That is the weirdest stored procedure

I can imagine this week, but I'm sure we can come with a worse one soon. Exactly. I really want to thank you for taking the time to speak with me so much about how you're thinking about this and what you've been building over there. If people want to learn more, where's the best place to go to find you?

BigAnimal.com. Excellent. We will throw a link to that in the shout-outs. And it only just occurred to me that the Postgres mascot is an elephant, and now I understand why it's called Big Animal. Yeah, that's right. He who laughs last thinks slowest. And today, that's me. I really want to thank you for being so generous with your time.

I appreciate it. Thank time. I appreciate it. Thank you. Really appreciate it. Benjamin Anderson, CTO for Cloud at 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 an angry comment that you then wind up stuffing into a SQLite database, converting to Base64, and somehow stuffing into the comment field.

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.