Postgres FM - Peter Zaitsev

Episode Date: March 31, 2023

This week we're sharing an edited version of Nikolay's recent interview with Peter Zaitsev from Percona — they discuss MySQL vs Postgres, Percona’s success, open source licenses, FerretDB, and databases on Kubernetes… phew! And here are some links to a few things mentioned: PerconapgCloudHacker browser extension PMMPercona Distribution for PostgreSQLFerretDBPeter's Twitter profilePeter's LinkedIn profile------------------------What did you like or not like? What should we discuss next time? Let us know on social media, or by commenting on our Google doc.If you would like to share this episode, here's a good link (and thank you!)Postgres FM is brought to you by:Nikolay Samokhvalov, founder of Postgres.aiMichael Christofides, founder of pgMustardWith special thanks to:Jessie Draws for the amazing artwork 

Hello and welcome to PostgresFM. We've got a slightly different episode for you this week. Unfortunately due to some conflicting schedules and then internet issues we didn't manage to record a regular episode but we hope to be back with that next week. In the meantime I have edited a recent interview Nikolai did with Peter Zaitsev for PostgresTV. They talk about MySQL versus Postgres, Pocona's success over the years, open source licenses, databases on Kubernetes, quite a lot. And actually they do get a bit passionate at some points and there's a little bit of swearing. So if you are around sensitive ears, please be mindful of that. Otherwise, over to Peter and Nikolai. Enjoy. This is Nikolai from Postgres TV. And

today we have an interview with great guest Peter Zaitsev from Percona, Percona's founder. Hi, Peter. Thank you for coming. Hey, thanks, Nikolai. Pleasure to be here. I think we met 15 years ago, right? Yes, it's been a while. Several years already passed. And I remember also like seven or eight years ago, I made a joke asking when Percona will provide Postgres support. Remember? Yes, yes. And then a few years later, actually five years ago, in Santa Clara Percona Live Conference,

you announced, it was 2018, you announced Postgres support. So it was not a joke anymore. Then I gave you five years to realize how Postgres works and all details. So question to you right now, what do you think the biggest problem of Postgres is and like what biggest difficulties compared to other database systems? Oh, you're asking me as if I would be deep technologist, right? And I think my relationship with Postgres will be different than it was with MySQL, where I was hands-on content sentence for many years, right?

And by the time we started to provide Postgres support, right, Percona was already a business with more than 200 people, which, well, did not really permit me so much time and need to get in depth with that, right? So with that in mind, what I think the PostgreSQL difficulties is, in my opinion, is not so much they're technical, but in certain cases, I would say like organizational, right? And maybe kind of

having a need to evolve with times. While PostgreSQL was not ever controlled by a single entity as MongoDB, right, or MySQL with Oracle, right, that is still controlled by a small group of unelected people, right, which are kind of benevolent dictators for life, if you will. And I think that is a problem. If you look at more particular things, PostgreSQL is probably the only really big project out there which does not have a bugs or defects database. It all goes in, let's say, some mailing list. And that is not helpful for users, right? Because as a user, you want to know, hey, here is a bug. It was introduced in this version, right? Hopefully, so if I'm below that, I don't need to upgrade, right? And it thinks in that version. If I'm

afterwards, I don't need to upgrade. You're talking about some registry of issues, tasks, bugs, and so on. Well, yes. With lifecycle tracked, right? That's right. Yes. And if you look at other database projects tend to have it, well, you know, PostgreSQL doesn't. I think also if you look at their process for development progress, right? Look, of course, there is this reliance on a mean Microsoft-owned GitHub, right? Or other nasty venture-funded GitLab, right? But look, that is a developer experience which we all like those days, right? We want to operate the full requests, right?

Not just, you know, send some code in the mailing list. So that is, I think, too, yeah. I'm 100% agree with you. And we actually, on this channel, we talk quite a lot about these problems. And we actually created a browser extension, which allows you to, in one click, to extract a patch from mailing list and quickly develop and check it in Gitport using GitLab, and also vice versa from Merge Request,

can generate a patch to send it to mailing list. But don't you think this conservative approach with mailing list, maybe it's a part of success of Postgres, no? Well, you know, I think this is kind of very interesting, right, in general philosophical discussion. And in many cases, it is very hard to say, well, is somebody kind of successful because or despite? You know, is somebody successful because he spent 20 years in jail and that was fantastic

education? Oh, well, you know what? Many people die doing that or become kind of slightly abnormal. And this guy, well, still was successful. So that is, I think, a comparison I would have here. Yes, of course, PostgreSQL is successful. That is not a question. It is fantastic. It's fastest growing database, right? But I think there are opportunities for Postgres to be even more successful. I also think what for every project and every technology company out there, we need to make sure it does not sit on its laurels, right, if you will. And PostgresQL folks should remember that.

I think for years, for many years, PostgresQL was kind of a distant second to MySQL in adoption. Now it's in many cases caught up and overcome, right? Especially in the momentum for the new project. But that does not mean that something else cannot come and become a more popular solution in the future if the PostgreSQL community doesn't evolve with time. I think evolving is the name of every technology venture out there. All right. And I understand that you don't have hands-on experience with Postgres, but I still think it's interesting to hear some opinions from you.

For example, MySQL has Vitesse and Sharding, right? Yeah, yeah. Let's go technology. If you want that, let's dive into that. Yeah, I mean, I'm not an expert. I still have... High level. Right. Yes. Well, one thing in this case, I think a solution for distributed database, you name that, right? I think modern developers, they expect a database, which is a horizontally scalable and a clustering also, which is built in. Not what you have to build the cluster from a different wonderful component.

I think that is one thing out there. Now, you may also pick on built-in encryption, transparent data encryption. That is another piece of mine, right? Which is, I find puzzling what seems to be over years, number of efforts in this case, right? But none of them really made it in a PostgreSQL mainline. Well, again, kind of that is something which most databases out there, they provide and many enterprise companies,

they expect that to be in a database. Yes, they may be stupid morons and don't understand what the file system inscription is just as good, but that's what they want. Right. You're talking about about encryption for data in place, like not on transit because Postgres provides...

That's right. Data trust or... What about compression? Like some people say like... I recently had a discussion on Twitter with CTO of Victoria Metrics. He was poking like, oh, I forgot Postgres doesn't have compression. And we talked about, okay, one billion rows, how many of gigabytes is that?

Usually with Postgres, we got used to one billion rows is one terabyte. With databases like ClickHouse, it's much, much less. So based on your experience with OTP systems like MySQL, do you think it should be implemented better in terms of compression in OTP system? Or it's just purely should be in all app systems or analytical databases and so on? Well, I think that is one thing what you cover, I think is very interesting, right?

I think if you look at compression, either your column store systems like ClickHouse or like special purpose systems like Victoria Metrics, if time's serious, yes, they allow for some great compression, right? Like 100x, very impressive numbers. Maybe not 1000x, but sometimes 100x, depending on data, of course. Yes, yes. I mean, that's right.

That is typically not what we get with OLTP-focused databases. But look, I think in this case, it is good if such options exist. Here is, I would go in a little bit kind of different direction. What was interesting in PostgreSQL, comparing that to MySQL, right, I'm obviously very familiar with, is what in a certain level, PostgreSQL allowed for huge number of extensibility. In other cases, it is rather restricted, and that is your storage system. And that kind of goes to the transparent data encryption as well, as well as compression. I think there have been efforts in a post-Griscoil space to play with that. There was Z-Heap, which was a project going for a few years. I haven't heard updates about that for quite a while,

but obviously it didn't quite get to production. I think we also have Neon also doing some things on changing the storage architecture in PostgreSQL. But all of that goes into kind of like a rather severe and intrusive PostgreSQL forks, if you will, not some sort of like extension. Right. But there is storage API. There is some already progress to allow different storage engines. But there are no well-established column store engines yet. But there is some extensibility already in place.

Well, that's right. But I think that is something what allows you to play a bit. Because if you think about saying, oh, I will just use the same storage engine and I apply compression to that. Well, that may not be quite a good idea. At least if you think about what we saw in the DB in MySQL, well, that is not very impressive.

What we see in this case is LSM-based storage, like based on MyRocks. That typically can offer substantially better compression, but they have also a lot of other difference in how they store data compared to your conventional B3-based database storage. So bottom line, compression topics should be considered together with storage engine topic, right? They should come together. I think that's right. And look, I think there is another interesting question here. I've seen a number of people talking about getting that light compression if running PostgreSQL on a file system which supports compression. It's like ZFS, you mean?

Like ZFS, first and foremost. And if you need a compression, then performance is less of a concern that is a possible solution. Yeah, it makes sense. It limits the number of use cases because many people don't manage services, but it makes sense. So back to success question and what's behind it and the last technical question. When Percona was founded, like in 2006, right? 2006, that's right.

Right. And how many people does Percona have right now? I think it's somewhere between 350 and 400 people, somewhere in that range. Yeah, that's impressive. What do you think is behind success? What defines success here? Well, I mean, why Percona has grown to this size? Well, I think there's a couple of things. And some of that I would attribute to luck and being in the right place at the right time. Because about the time we started, we had Sun acquiring MySQL, then Oracle acquiring Sun. That had a lot of digestion processes, if you like, right? Which really allowed us to get some good market share. It was in 2000, roughly 2010, 2011, as I remember, these acquisitions happened.

2009, right? It was, I think, like early, it was like an Oracle would buy in the db right which should get always kind of like an extra tension so there was a lot of i would say challenges in that market and i think for us another important thing was uncompromised customer focus saying hey you know what we just want to go ahead and do what's right for a customer from my perspective, from looking outside at how it started, I remember MySQL performance blog or something. Oh, yes, yes, yes. Well, that's right. Yes. It looks... Yeah. You and Vadim, your co-founder, were very active there. And do you think blogging helped also? Well, yes. I think especially at that time,

everything has to be looked at like a time lens, right? I started MySQL Performance blog, and actually it was even like a blog on a live journal first, before going on my own, right? At that time, I already had some sort of people who respect me in the industry, right? I was also around the conferences, right, on MySQL behalf. So then I left on my own. That was very good in generating initial business. Because when I left MySQL, I didn't have long runway. I had just my second child, right, who was, she was like six months, we just moved to the new country. So for me, it was like, hey, you know what? Make this thing work or go hungry, right?

And actually, to my surprise, I think we got like a pretty busy schedule in just one month, even though we didn't even have a corporate website at that point, right? I just little have like, we do MySQL consulting on our website. And I think that is for me, is probably like a learning experience. Hey, you know what, if you want to do it kind of a hard way, you're not raising capital, you want to kind of bootstrap, make sure you have some sort of following. Some people you actually have a reach who can either become your customers or maybe spread the world to help you to get those customers. What kind of tasks? General database support, performance tuning or what?

That's right. Now, remember, that was before the cloud, before database as a service. And what that means is if you want to have like a, you know, simple Drupal power website, for example, and you want to make sure it is highly available, you need MySQL set up for your replication, backups, and so on and so forth. And that typically would be some sort of manual work. That's what you would do. Also, a lot of consulting. That is where I think we did a lot of good in terms of finding our niche. Because one thing is if you look at the larger companies, typically they come with relatively heavy process to set up consulting.

You figure out your statement of work, right? And probably that's going to be- Master service agreement first, then statement. Yes, yes. MSA, right? And whatever, right? We would build in 15 minute increments and it would be pretty easy to do.

Hey, you know what? You essentially have like a napkin kind of agreement with us and we'll do what you tell us. And that means for startups, that was very easy. I just need a little help here. Hey, you know what? Maybe tune my basic settings. Hey, I don't know what to do with this query. Boom. And that was very inexpensive for customers and providing them a lot of great outcomes. That's super interesting. So tiny contracts, like the only flow of them. Yeah, that's super interesting. So tiny contracts, like the long flow of them. Yeah, that's super interesting. And another thing what we did, which we later actually stopped doing,

right, as we launched support, is also emergency consulting. You actually could call and that was my number. You could call me in the middle of the night and I will wake up and we'll pretend I was not sleeping or... You don't sleep anyway because of second child, right? Yeah, that's right. And I'll go and, you know, fix your database, right? And they would essentially charge you for two hours minimum, right? Or something like that, which was a very good deal for customers who run

into trouble and they don't know what to do with their database. Yeah, interesting. And then you said you abandoned this idea while the company has grown, right? Well, yes. I mean, things change. And I think this is also what company has grown, right? Well, yes. I mean, things change. And I think this is also what is important to understand, I think, as you scale the company. The things that you are going to do as a kind of solo entrepreneur are not what your employees would do.

And for many reasons, it's not just kind of a hard work. I, jumping on the call, I can promise anything I like. And in many cases, people say, well, we need help with this. I say, oh shit, they're asking me to also write some code in the language I don't know. I say yes, because I'll actually call a friend and he will help me. Well, you know what? If you are the salesperson, you're probably not going to be comfortable obligating the company what that company doesn't do after that company has scaled. And that means is as a company grows, you get typically in much more defined proposition of your services, what you do, what you don't do. And also we transitioned upmarket. And I think that's a good thing we did because I've seen so many companies which have been operating with us

earlier on, they sort of disappeared after cloud moved on. Because you know what? The same dudes who would need a little Drupal website, well, they now can just host it with Acquia to get a whole thing. Or if they want a separate thing, they'll probably can use RDS on Amazon and not have me to come and set a database for them. Right. So demand decreased. Well, demand changed in this case. I think at the same time, we see a lot more of a larger enterprise adopting open source database technologies. So when my common customer early on would be small businesses, now a lot of them are large enterprises.

I also wanted to ask you why open source? I noticed at some point only a few years ago, actually, that you prefer open source everywhere, like have strong focus on open source. And why? Well, there's like multiple reasons for that. Some of that is their ecosystem I sort of grown into, right? But I also truly believe this from a customer point of view, that the open source is best for you because that gives you a lot of choice. And I think, well, open source, so maybe using that other free software and thinking about free as a freedom, in this case, is very important for me personally. I mean, if you think about, for example, why did I start my own business? Well, one thing is I

absolutely despise authority, right? I hate taking orders. So what that means, if that is kind of more important for you, maybe than the amount of dollars you make, well, then I think, A, having your own business, and B, doing that around the open source is the best you can do. Because using open source, I don't need to go to any large vendor and say, well, dear Oracle, I want to do business with you. Please love me. Oh, you have a partnership agreement I need to sign. No, I can go out and say, did you guys know Oracle doesn't have customers? Oracle has hostages. I love it.

Well, a couple of more questions about Percona. Percona still is a consulting company. Well, I mean, I wouldn't call it this way, right? I think this is something where people want to kind of define that and maybe from the early days, right? I believe what we are in a software business, we produce software. It is just that software. Like PMM, right? Like PMM, like, you know, percon distribution for Postgres as we speak here,

right? It just happened to be what our products are open source. Interesting. But- But I think what is important to understand, right, is what the open source, that doesn't mean you cannot charge for it. We have customers which may buy support and then we can cover both the Percona version as well as an upstream. Let's say if you choose to run PostgreSQL, which you downloaded from postgreSQL.org, we also have... Or RDS. Or RDS, yes. We cover that as well. Though I would say in RDS, we recognize our help is a little bit more limited

because we cannot look at the source code or even what the hell is going on with the instance. But in many cases, we can help. Or we also provide their subscription to their Percona platform, which we are building some other additional things beyond support, which actually kind of like always existed.

We have a knowledge base, which customers can do self-service in PMM. We have some additional advisors, which are available to subscribers. Only in paid version. So there's differentiation and functionality there, right? That's right. I think if you look from a Percona standpoint, where I see importance of value proposition, Even though we are now hundreds of people, right? It's not just myself and a couple of friends. We are a tiny company compared to the gorillas in the market. And in this case, what that means, I don't want to say, oh, you know what? We are providing like an other proprietary version of Postgres, just like Enterprise DB does. And our version is just slightly crappy and slightly cheaper. It's not really differentiating enough.

And for me, what I want to make sure is what the offering provides that really big delta, which is for me, what open source brings in a practical way is avoiding vendor locking. When you run per corner products, hey, you know what? If you don't like us, if you don't like us if you don't like because we suck or because we are too expensive hey you know what

you can keep buying our product and go get help somewhere else we are not going to require you to refer any software out yeah that's interesting

in this point obviously it's interesting to discuss open source versus cloud what do you think what's happening right now in 2023?

And what's the nearest future of this? Because obviously we had a recent case. It's not from database world, but it's from front-end code world. There is a case when some Russian, Denis Pushkarev, has Lawy Rock and his library CoreJS, which he maintains for many years alone. And basically like half of internet is running on this library. You know this problem, right? And he's complaining that he cannot make money

and he cannot continue and so on and so on. What do you think about open source versus cloud? Well, I think what the problem we have here is just because how ubiquitous software engineering and open source has become, right? It's not about open source so far, but about doing things for their own reasons, right? Because if you're saying, well, you know what, I go ahead and do the open source, right? Under open source license.

Well, that means, well, you are essentially thinking like, well, I want to get a good for the world, right? And I am not expecting to pay anything bad. Look, it's not just about the open source, right? You can release your son in public domain, right? And then say like, how the hell nobody's paying me? Well, look, you chose to do that. If you wanted to only restrict it, well, you could have done it. Maybe nobody would have heard about it in this case, but that is the choice to make, right? It's like open source is not a business model, right? This is what it's all about. Well, open source is not a business model,

right? But I think right now you see when the thing shifts. Well, if you look at from a music industry, I think you had like, as we moved from the CD to streamings, you also had a lot of people bitching about how hard their life is and now they make no money, what they believe should be paid for their art. That is kind of natural, right? In this case. Now, look, I would say, if you look at from my standpoint, I wish the cloud vendors and actually many other commercial companies, which rely on open source would choose to contribute more to that. I think that is something what we will gradually learn. And I like seeing people like that.

I like more people say, you know, fuck it. I do not want to maintain my library anymore. Because what you want those cloud and corporations to understand, that's kind of your, you know, your supply chain. If you are not fair to somebody in your supply chain, you know, like, sooner or later, they're going to say, fuck you. I'm

not going to supply you anymore. MongoDB and Elastic, right, similar thing. They changed licenses and so on. Because of actions from AWS, basically. Well, I mean, I don't see it that well, frankly, right? I think actually, if you look at a VC-funded open source, that is a different story.

A lot of those people privately, and I think what I like about MongoDB, they are actually very public, right? They have no freaking shame. They say publicly, well, you know what? We did not open source to get help. We open source as a marketing strategy. So they approach us saying, hey, we'll call this thing open source to get as many customers as possible, right? And then it doesn't serve us anymore. We

say, you know what? Screw you. Time to change. Now it's not open source. With CocoaDB, a similar thing happened, right? That's right. But it's not like reserved to cloud and open source. Think about somebody like Uber. Uber was subsidizing every damn ride until all taxes were dead. And then they can say, well, fantastic. You know what? We are not going to get more adoption by using the low prices.

Now let's make people pay more. Not just Uber, right? The same strategy as you can see with somebody like Amazon. Very often people say, well, you know what? We got used to things being really cheap on Amazon 10 years ago. Well, not any longer because guess what? They got maximum adoption. People kind of get hooked on that.

Free databases on Heroku, free databases on Vichy, no more, right? And free databases on Neon and so on, right? Yeah, so I think that's right. And I think that's right. The open source is a part of freemium strategy, right? The first dose of heroin is for free. But you know what? If you get that first dose of heroin for free,

that doesn't mean you would continue getting it, right? So I think that in terms of MongoDB's Elastic, I think that was deliberate strategy plannedDB's elastic, I think that was deliberate strategy planned for a number of years, and then they came with that as a soap story. Not like, hey, we are greedy bastards, our market cap is X,

and we want that to be 5X, but well, we are unfairly treated by the cloud vendors, and we are fighting for our survival, yada, yada, yada. And these considerations probably should define the license you choose. For example, if you start some new database system or some add-on, like we have a bunch of new projects like open-source Snowflake

built on Postgres, open-source Firebase built on Postgres, and so on. Many. We have at least five maybe very noticeable projects right now. What license would you choose? Well, I think that is a very good point. And I think that, of course, depends a lot on the path you are looking to change and also how honest you want to be with yourself, right? Actually, kind of this path,

what we see proven as working very well in VC companies saying, hey, go with permissive license, get adoption, then scream bloody murder how life is tough, right? And change your license. Look, at large extent, that is successful. Is it honest? I don't think so, right? I mean, but you know what?

Maybe as a founder, you don't give a shit. You know, say, hey, you know, I have my cool billion in the bank and, you know, fuck you all. Like in the open source contributors, right, who helped that to happen. Well, you know, why not? That is a, you know, position which... So would you choose a BSD or like Postgres license in this case and then change it later? Yeah. Well, first of all, I think what is happening right now is that GPL is dead because it's kind of useless left in the middle.

Including AGPL or no? I think mostly AGPL. Because the thing about MongoDB, it was AGPL. And I think that is something what I heard out there is what they find out what AGPL does not work. Well, maybe if you go through that all the legal process and in 10 years later, it will be discovered. Well, you actually breach of that license. But by that time, it's kind of all. And why doesn't it work? Well, look, I'm not a legal person,

but I want to say is there have been a number of companies, you know, think about Object Rocket, think about Compose, IO, who were providing MongoDB as a service. Then it was AGPL. And MongoDB couldn't make shit out. They just could not stop it. Well, I don't think we had bad lawyers.

I think in practice, it didn't quite work. But as soon as they changed the license to SSPL, everybody complied. And what I heard in this case is because while AGPL leaves certain things to interpretation, their SSPL is much more black and white in this regard, right? What you cannot do certain things. So bottom line, what would you choose? My opinion, right? If your goal is maximizing adoption, then some sort of permissive license is your best choice. The choice of a license, I think here, depends on the community a lot, right? Like for example, if you look at the cloud native,

Kubernetes stuff, they all do Apache. It's better to just comply with that. So your customer looking at the license, they don't have to, you know, they have lawyers, right, which understand Apache, it's already approved, right? If they're running Kubernetes, don't make it more complicated for them.

If you're using the ecosystem, which is based on, you know, other licenses, maybe you want to embrace that. So that is what I would say. Yeah, makes sense. And there's a project called FerretDB, which is kind of MongoDB, open source MongoDB on Postgres, built on Postgres, right? Yes, that's right. I noticed it also has Apache 2.0. Well, that's right. So the Feradb is the project I helped to start because after MongoDB went

property, right, it was clear what there is a need for open source MongoDB alternative. And we discussed for a fork with number of parties, but of parties, but there was not a lot of appetite. And we knew as a pure corner to really do a fork would not be workable, right? So, well, a few years later, I'd seen what we are not really getting a lot of stuff happening in that ecosystem, right? I have to put the team together.

Yeah, and then we've been building MongoDB compatible replacement by using Postgres as a backend for last year or so. Interesting. In my opinion, I have quite established opinion on MongoDB criticism of relational databases. Like two things, and both, I agree, are reasonable. First is

so-called web scale, so lack of sharding, right? And second is the difficulties with schema maintenance, changes, testing of it, and so on, like schema-less. So web scale and schema, two words. How does FerroDB go to address these challenges? Well, I think that is a very good question. So if you look from a schema-less standpoint,

well, in this case, FerroDB behaves exactly like MongoDB. PostgreSQL has a pretty powerful JSON capabilities, right? And that's what FerroDB leverages. If you look at the web scale, I see what that is a problem to be solved by PostgreSQL or surrounding ecosystem. I already know what both Hugo Byte and CockroachDB has written about using FerroDB with their solution as a backend, which is fantastic.

And FerroDB team probably also look at wherever it's feasible to work at with Cytos or other more native PostgreSQL solutions as well. Interesting for me, like as a person coming from business side versus engineers. Engineers like to solve a complicated problem. I remember talking to our guys and let's say, well, we need a backup. I say, well, but what about how it's going to work with a 100 terabyte database of a million of tables, right?

And you know what? The answer might be it won't. But it doesn't matter because from a business standpoint, you need to be looking at the glass half full. And if a market is large enough and you only can serve 10% of a market, that is wonderful. Stop engineering and start selling. And then you can grow that 10% to 11, 15 and whatever. So that is how I approach it. So is it going to be a solution for everyone on day one? No, it's even not going to be a solution for everybody at any point in the future, right? But I think it has enough market where it's going to be very successful,

right? And we've already seen that. Yeah, that's great advice. I think some of our previous guests also would benefit from. So thank you. It sounds obvious, but you are telling this great. I mean, thank you. Okay, so I think maybe that's it, or maybe a few more words about the future of clouds and Kubernetes and so on. Will Kubernetes kill clouds? I've been talking a lot about what is going on

in the clouds in those days. And I think what is very interesting with open source in general, you can see some of a proprietary innovation often goes a lot faster than you can see some of open source kind of slowly and inevitably kind of catches up. And what really excites me is what's going on right now with a cloud-native ecosystem and a Kubernetes-based solution, which are getting more and more features, more and more innovations. If you look at the stats from data on Kubernetes

community, for example, you can see the database on Kubernetes is actually one of the fastest growing workloads. It's grown, I think, by about 50% last year alone. And I think more and more, we can use a cloud in a way where that is essentially commodity infrastructure provider. Same as we use, for example, a cell phone providers right now, right? You know what? You just don't particularly care. All the carriers are about the same, right? And with Kubernetes, cloud native open source, we can get to pretty much the same thing with cloud providers. Of course, cloud providers don't like it. They often would like to pretend it's not possible.

If you go and think about how you have to behave to be, you know, build well-architected Amazon application or something like that, of course, that's not the way they're going to do. But hey, you know what? Was Microsoft advising you to go open source in late 90s or early 2000s? Of course, they didn't. Companies advertise not typically, right? Not what's good for you, but what's good for their wallet. But despite that, I think an open source will take a big dent of cloud workloads in the near future. A couple of weeks ago, Nikita Shumuganov, the CEO

of Neon, which builds Neon database, bottomless, and so on and so on. So we mentioned on Twitter that Neon has Kubernetes operators, so they use Kubernetes. And engineers hate it. And it feels overwhelming to maintain. It's like too much stuff and so on. And they consider HashiCorp a nomad. And I tweeted just one word in my Twitter and so on. And they consider HashiCorp a nomad. So, and I tweeted just one word in my Twitter and LinkedIn also,

just one word, Kubernetes-less. And in both places, I've got a lot of likes. Obviously, a lot of engineers, obviously, they do hate Kubernetes. Do you think Kubernetes already won or maybe is winning? Are there any alternatives?

Is this the only path we have? In the context of databases, I would like to say, do you think kubernetes already won or maybe is winning are there any alternatives is this the only path we have in the context of databases i would like to say look what i would say we observe this kind of kubernetes community for a number of years right and i remember there was let's say folks what apache is like a messes like hey you know we are much better. There's like a Docker swarm. We are much easier. There was Rancher, the Red Hat's OpenShift version one, which was not based on Kubernetes, right? There was a lot of folks out there which are doing different stuff.

But look, the Kubernetes won at large extent in the mindshare. Is that the best technology? Maybe not. But reality is what best technology does not always win. In this case, we have to be looking at mindshare. And I think right now, Kubernetes is pretty much as ahead compared to different variants as Linux ahead of FreeBSD, NetBSD, and others. And again, you can probably find a bunch of freebsd people out there which will explain to you why free sb technology is ahead of linux yeah maybe right but well this reminds me also another story my sql was considered not as the best open source database but in postgres had a lot of benefits and it was losing initially like 15 years ago and we both

remember it but eventually postgres became number one choice for startups as it is right now yes well that's right but linux versus freebsd mysql versus postgres are different stories well that's right but look from my opinion at your corner and other businesses right what i involved, we typically are taking a practical step and not trying to guess too much in the future. Because frankly, technology changes so quickly, some of the stuff that we may imagine, you know, five years ahead may not exist, right? We think about this like a chat GPT, for example, which came almost out of nowhere. It's like we always had like an AI gloom, you know, self-driving cars not happening. They promised that 10 years ago and nothing. And that's like, boom, you know, chat GPT,

which is kind of a lot better than kind of anything they've seen. So we are focusing a lot about like what exists right now, what companies are thinking to adopt right now. And if you think about an enterprise space, Kubernetes is pretty much ubiquitous. Now, I do not think including for places as well, right? Including for database compared to other frameworks. Now, if you think about using HashiCorp approach, what's that? It's called Nomad, as I remember. Nomad, yeah. So think about this, right? That does not make a bad choice for Nikita, because if your role is saying, hey, I want to run my database as a service, right, my, then using whatever solution your folks are comfortable

with is totally cool, right? And maybe that is where you want something which is more simple. Maybe the code you can understand, something you can hack and customize and so on and so forth. Now, if you are, as companies like Vercona say, hey, we want to empower solutions for thousands and thousands of customers, you have to be mindful about what kind of expertise that customers have, what they want.

And look, in this case, Nomad may be awesome, but reality is nobody is asking for Nomad. Not yet. Maybe they will, but for now, it's not fair, right? And there's probably, you know, like one out of a hundred experts in this case. So yeah, that's how I see it. Maybe last question in this area. As I hear Kubernetes is like becoming definitely, maybe already became even for databases even for databases, the most popular choice. But today, we live in some kind of crisis again. And recently, Basecamp, CTO, DHH published a good report that they have a lot of...

So, do you think it's possible that Kubernetes will be a solution to go out of cloud. For example, we just get our bare metal and collocation or RAN servers. So we install some lightweight Kubernetes as k3s.io. There is such, like it's easy to install. Yeah, totally, like k3s, yeah. Can be Kubernetes a killer of clouds in this case, when people start analyzing their budget reports. Well, I think what you are right at large extent, the clouds are expensive. I think over the last now, I think it was like 10 years, if a capital being so cheap, a lot of companies were saying, hey, you know what, we want to grow, we want to do fast. It doesn't really matter what that growth is not very cost-effective.

And that is, I think, how many of them would do a mindless spend on the cloud, as well as a bunch of other kind of mindless spends, right? I mean, you can see a lot, particularly venture-funded companies, but also big enterprises stacking in their belts in other ways too, right? Last several months. Now we are getting to a point where you say, well, you know what? We actually need not only to grow fast, but we want to find a way how to make it efficient. And that is they're either abandoning, I would say, their proprietary services, which can be a huge premium. Like think about how much more expensive, let's say, is Aurora compared to how much infrastructure costs to run it. That's probably going to be like three times different or something like that. And then all the way going to be able to utilize either your own service or let's say some of other

clouds, less expensive cloud infrastructure providers. Think about this, right? The fact that Amazon Web Services was really the profit driver for Amazon for years now, that means what their margins are obscene compared to your server provider. Like if you look at Dell's super microservice world, their margins are this. And if cloud is commodity, you would expect to see relatively thin margins for them, right? And that is one way or another we are going to drive them. And I think a few things will happen. As we have guys like DHH at Basecamp, CTO, right, saying, hey guys, you can actually escape the cloud. There is a way to go back on-prem. It is not so hard. Because we have Kubernetes, right? Because we have Kubernetes, right? Then it will force the clouds to come to their senses

and cloud will become less expensive. Cheaper. Yeah. So that is, I think, is a wonderful thing. In many cases, it doesn't require 100% to move. It's important to the way to be shown and some people to having discussions. Hey, dudes, we have a choice. We don't only have to sit there, right? For things to become more cost-effective. Right.

That's interesting. And this relates in my own thoughts as well. I think definitely we should pay attention to those numerous Kubernetes operators for Postgres. And yeah. Yes, especially ones from Percona, right? Of course, but you forked it, right? You forked it from Zalando, no? Initially. No, no, no. Well, initially

we forked that from Crunchy. Okay. That's right. But we got a bunch of our original development out there as well. Huge competition. And that's good also. And this is open source style, like Bazaar and so on, not Cathedral. So great.

Okay. Thank you, Peter. I enjoyed it a lot. I learned also myself. I hope our viewers also did. Thank you so much. I hope we will chat sometime soon as well

at conferences or somewhere else. Thank you. Have a good week. Okay. Sounds great. That was a pleasure. Yeah. And those who achieved this point

definitely should put like and subscribe and share with people who are interested in open source databases and so on. It was great conversation. Enjoy. Thank you. Bye-bye. Bye.