Talking Postgres with Claire Giordano

CLAIRE: 00:00:06
Welcome to Talking Postgres, a monthly podcast for developers who love Postgres. I'm your host, Claire Giordano, and in this podcast we explore the human side of databases, open source, and Postgres. And what that means is we dive into why do people who work with this database do what they do and how did they get there? I want to say thank you to the team at Microsoft for sponsoring this community conversation. And today's guest, and this is episode 27, is Peter Farkas. Now, Peter is co-founder and CEO of FerretDB, and it's an open source MongoDB alternative. Peter spent the last 15 years of his career working on open source for different database-related companies, including Cloudera and Percona, and now FerretDB. Welcome, Peter.

PETER: 00:00:57
Hello, Claire. Thank you very much for the invitation. Glad to be here. And hello, everyone.

CLAIRE: 00:01:02
I'm glad you're here too. So today's topic is how I got started with FerretDB and why we chose Postgres. So although you work at Ferret, there is a Postgres connection to today's conversation. And I think I just want to start there. What is the connection between FerretDB and Postgres?

PETER: 00:01:27
Well, there's a lot of connection, but let me go back a bit in time. So actually, I was not really part of the Postgres community back in the early 2010s, I believe. So I was very much into MySQL. I worked for a company named Percona. It's like EDB, but for MySQL, or back then it was really just MySQL consulting and support company. But back then we were seeing two database technologies to emerge next to MySQL, which is pretty much the default open source database for many of our users, MySQL that is. But we've seen Postgres and actually MongoDB to emerge later in the 2010s. And that's when I started looking into really what Postgres is, how the community looks like and so on. And I found that it's a great database and I really liked the community, even though it was much different than MySQL.

CLAIRE: 00:02:43
What was your role at Percona? Do you mind? Sorry, I interrupted you.

PETER: 00:02:49
No worries. So my role at Percona was I was in charge of the subscription support business. Basically we've built a team of more than 35 people to provide services for MySQL and later MongoDB and Postgres. And yes, that's what I did at Percona.

CLAIRE: 00:03:16
Okay. So I'm guessing that...

PETER: 00:03:19
It was just to add something. So, you know, some, having spent a lot of time in support for databases was really valuable because that's the organization which talks to users, which talks to customers. So you kind of get the other side of the story as well. You may think that one feature is really helpful and this is going to be the next big thing. And then later on, you realize that some things were overlooked and improvements are needed on the product side. So it's a very, very interesting and very valuable experience to actually be in this double agent situation where you're a champion for your users. But you also need to make sure that the business grows and the product evolves.

CLAIRE: 00:04:16
Well, you read my mind. That's what I was wondering when you said you were in charge of the support business, because on a previous episode of Talking Postgres, David Rowley, who is a Postgres committer, was on. And he talked about how formative his time working, supporting customers at 2ndQuadrant was and how that has influenced to this day his work as an engineer and as a committer. So I was curious if that time in support at Percona, leading that team, has affected your worldview now at Ferret.

PETER: 00:04:52
Absolutely. Yes, absolutely. That's actually part of the reason why we started the company. because if you are familiar with the MongoDB story, MongoDB was this really big up-and-coming database in, well, I would say starting 2014, we started seeing MongoDB users. So that's when it started to become more popular and it started seeing production scenarios and we talked to the users. And of course there were problems, but the bigger problem was that they changed the license in 2018. So a lot of users who chose an open source database product for their database needs found themselves in a situation where they ended up with a proprietary or source available or however you want to call the SSPL license. And so I've seen this combination of technical problems or challenges as well as the legal ones. So that was the starting point. That was the problem statement FerretDB started with in 2021.

CLAIRE: 00:06:15
So for people who are listening, who are perhaps unfamiliar with FerretDB, let's just go there. What is FerretDB? I know I said in the beginning, in the introduction, a MongoDB alternative, and you just hinted at that as well. But can we peel the onion and just go one layer deeper than that?

PETER: 00:06:37
Absolutely. But this is a huge onion.

CLAIRE: 00:06:40
With many, many layers.

PETER: 00:06:42
Yeah. Like you go to the vegetable section of the grocery store and you see this giant onion. Well, that's FerretDB. So FerretDB is basically an open source MongoDB alternative. We take Postgres as the storage layer and we make it speak MongoDB. So we emulate the MongoDB API. And so users can connect their MongoDB applications to FerretDB and FerretDB will store their data in Postgres, meaning that we turn Postgres into a MongoDB compatible database. And what compatible means is that users don't have to rewrite anything. They don't have to change their habits, their frameworks, their tools. can just keep using MongoDB related or MongoDB compatible frameworks whether that is a JavaScript framework or some application building tool or something else and just use it with Postgres and the MongoDB application will not notice that it is not running on MongoDB proper but it runs on on Postgres and I still think this is crazy, crazy cool.

CLAIRE: 00:08:12
It is crazy cool. Okay, so we're going to dive into the Postgres part. Obviously, the name of this podcast is Talking Postgres after all. But first I want to know a little bit more about how you got started. Like you talked about MongoDB changed their license in 2018. Obviously, from your place at Percona, you observed that. Then what? How did you go about founding a company? How did it happen? Did it happen overnight? A nine-month period maybe instead? Like what? Tell me about it.

PETER: 00:08:49
So I left Percona around 2016, so I was actually not there when the license change happened. I was still very much in touch with the community though. So Percona's founder, Peter Zaitsev, who you might be familiar with, is a very well-known person in the open source database space and founder of Percona. So we kept in touch after I left and we observed all of these changes and we were very active in discussing how is this going to change the course for MongoDB users. We've also seen Postgres to evolve into something which users really, really like. So in 2018, we kind of expected that the community is going to fork MongoDB and that there is going to be an alternative, such as what happened with Redis and the alternative Valkey, where Redis moved to SSPL and Valkey basically got started overnight by the community as a fork. But that is not what happened with MongoDB. So we were kind of waiting and expecting that something is going to happen on that front and forks are going to appear. But the only thing we've seen, not that that was not a big thing, but kind of unexpected, that AWS came up with their MongoDB alternative and Azure, Microsoft Azure came up with their MongoDB alternative, presumably not based on MongoDB code. So even though there was no fork, alternatives appeared. But these alternatives still, well, they were not open source and they were tied to specific cloud vendors. So by 2021, it became clear that the fork is not going to happen. Well, maybe much earlier than that, but in 2021, we were thinking, is there a possibility that we can just either fork MongoDB or create an open source alternative, a truly open source alternative for MongoDB users who were surprised by this license change and impacted by this license change. So the actual conversation, it happened in pretty weird circumstances. So with Peter, we went to this epic trip to the Himalayas. And that means we went to to the K2 base camp, which takes about two weeks in total and you sleep in very nomadic circumstances on a tent, most of the time on a glacier. And you know, during those two weeks you speak about family, you speak about hobbies, you just try to kill time at some point.

CLAIRE: 00:12:16
Kill time and stay warm.

PETER: 00:12:18
And stay warm and stay alive. Yes, that's also important.

CLAIRE: 00:12:24
What's the altitude at K2 Base Camp?

PETER: 00:12:27
What was that? Sorry.

CLAIRE: 00:12:28
What's the altitude at K2 Base Camp? Do you know off the top of your head?

PETER: 00:12:33
K2 Base Camp is about 5,200 meters. And that is about 17K feet for folks in the US. So yeah, that was pretty extreme. That was my first time above that altitude and that's when you can't really have a rest. Your heart rate when you sleep is still above like 90 beats per minute, so you don't really have a good night's sleep. These are the circumstances where we came up with the idea of FerretDB where we were thinking maybe it is possible to take an existing database engine and turn it into MongoDB and we did not know whether that is the same thing as what the folks at Azure and AWS did but we assumed that they did not fork MongoDB and we also assumed that it has to be something related to Postgres under the hood. So in July 2021 that's where we went to this trip. We were in a hotel in Islamabad and we decided that we are going to start the company which was called MangoDB. It's very controversial, I know. uh that's when that's when we embarked in this uh in this uh adventure and uh we involved uh my co-founder Alexey Palashchenko right away who is also a former Perconian so like this the three of us started this uh this uh adventure

CLAIRE: 00:14:28
That's quite a quite a birthplace for a database company. [Yeah, yeah it is] All right. So why did you choose Postgres? You said you were there at altitude and you knew that it needed to have Postgres involved, but why?

PETER: 00:14:49
Maybe because of the altitude. Just joking. The reason why we chose Postgres is because Postgres, first of all, is truly open source. And you know what, with MySQL, which was our main database technology we cared about for the most part at Percona, it's dangerously close to Oracle nowadays and some users don't appreciate it. And it's also not as good with extensions. So Postgres extensions are very mature and popular. And with MySQL that is not really the case as far as we understand. But the main reason why we chose Postgres over anything else is because the community is very much dedicated to make it work in very different scenarios. So Postgres and its community is unique in the sense that they are very proud of or we are very proud of Postgres and we want to make it succeed and we want to make sure that more and more users can benefit from the advantages of Postgres and we needed this kind of dedication and power to pull this off. We couldn't have done anything like that with the help of the community. And from day one, when we published our tech demo on GitHub, I think in two or three days we got 5k stars, which was a very good indicator that this is something we need to move forward with. Most of those stars were coming from the Postgres community around the world because they really wanted to see Postgres succeed in this kind of use case as well. So all in all, I think my answer would be definitely the community and definitely the way the community engages with newcomers, with people who are trying to do something very, very different. And that helped us a lot along the way.

CLAIRE: 00:17:24
Did you consider other databases? I mean, you told me already a second ago why MySQL wasn't a candidate, but I'm wondering if you did any kind of bake-off or performance benchmarking or testing, or if it just, like the analysis was maybe just in your minds, it was an obvious no-brainer.

PETER: 00:17:49
Well, there were a couple considerations. First of all, we don't just support Postgres, we also have support for SQLite, because SQLite is this very lightweight and very much embeddable database, which can be enough for lots of use cases without having to spin up something much more serious like Postgres. So we do have support for SQLite, but it does not bring the performance and the compatibility as what the Postgres backend does with FerretDB. And we also had community contributions for other database technologies like SAP, where SAP implemented SAP HANA support for FerretDB, which was really surprising as it did not happen without our intervention or much help at all. It just appeared overnight, but that's the power of open source. And we were very happy to see that. But back to our choices. So we had lots of requests for SQLite, so we obviously did that. We also had lots of requests for MySQL, but ultimately we decided against it because the community was not that engaged and it was just... It was just not something which would have given us lots of extra stuff over Postgres. That was not something we were interested in in general. There was also a third thing which we've seen and that is we were looking at AWS DocumentDB and Azure Cosmos DB for MongoDB. And we kind of had a feeling that these teams also used Postgres because of some of the limitations we were seeing in the documentation were crazy similar to Postgres's limitations. And that was also a sign that we might be on the right track if these large organizations with very smart developers arrive to the same conclusion as we did when it comes to Postgres being capable of doing all of this.

CLAIRE: 00:20:35
Got it. Okay, so you just mentioned the Azure Cosmos DB for MongoDB team. And I know that FerretDB now runs on top of something called DocumentDB, which was an open source offering released by Microsoft a couple of months ago, back in the beginning of this year. So can you explain that to our listeners?

PETER: 00:21:01
Absolutely. So how that happened is that we've been working on FerretDB for over a year when we got engaged with the Microsoft Cosmos DB team. they were interested in FerretDB and we were interested in what they did because we kind of had the community around this open source implementation of a MongoDB alternative whereas they had a powerful Postgres extension which at that point powered the MongoDB compatible service on Azure Cosmos DB for years at that point. So we engaged in conversations on how can we join forces and how can we make sure that we can combine the positives of the two products. And we started working on that. And, you know, I'm not sure how much I can say about this. I don't want to speak for Microsoft. I just know that an organization like Microsoft is obviously large and open sourcing something definitely needs lots of approvals. And we were seeing that during the time when we worked together or while we still work together with the team there. And it was really good to see that Microsoft is trying to do the right thing and they were assigning lots of resources into making sure that this open sourcing of their MongoDB compatible database solution alongside with FerretDB can actually happen. And the reason why this is very important and the reason why I think this is one of the greatest steps towards FerretDB's mission at this point, which is to bring MongoDB back to open source is because the more alternatives we have on the market for a MongoDB compatible database solution, while it's really good and there should be lots of alternatives of course, but an open standard is also needed. So if you think about it, if Microsoft, Amazon, FerretDB, SingleStore and other companies, Oracle, come up with their own implementations of a MongoDB compatible database, while it provides choices for the users, it also creates this environment where if these alternatives are not based on a common open standard then the features and the behavior of these products will be very different. So by working together with Microsoft we combined the two uh we combined two of the several well-known MongoDB alternatives out there and we placed them on a single foundation which enables users to migrate and use their existing know-how to actually move to an alternative and they can use this know-how and migrate between these alternatives away from MongoDB without the fear of getting locked into yet another product because that's the problem with a missing open standard. When you think about SQL, you can use SQL across multiple different products, but when it comes to MongoDB and their query language and all that, there is no standard behind it. So the moment you create an alternative, that is going to be a very unique implementation of what MongoDB does. So all in all, our work with Microsoft was really interesting and we are looking forward to pushing forward for an open standard together by keeping our products compatible and by making sure that others will join this effort.

CLAIRE: 00:25:50
And just in simple terms, the open source DocumentDB layer that FerretDB now runs on top of. DocumentDB includes, I think, a Postgres extension, correct?

PETER: 00:26:04
So DocumentDB itself is a Postgres extension, yes.

CLAIRE: 00:26:08
Okay. And which goes back to what you said in the beginning, you were talking about the reasons you chose Postgres and you felt like the whole extension ecosystem was really strong in that space. And I don't know if you know my background, but the whole way I got involved in in the Postgres open source project was by joining Citus Data years ago, back in like 2017. And Citus is an extension to Postgres as well. So I've seen firsthand just the power of the extension ecosystem. And it still boggles my mind that if you go back to the very first paper about the Postgres database from, gosh, the 1990s, I think, you know, one of the core requirements was that it be extendable and to see it have played out in the way that it has enabling like the innovation underneath FerretDB and enabling situs and enabling PostGIS, I'm still wowed by it all. [Indeed.] OK, sorry I'll get off that soapbox uh all right so how how is FerretDB working out for you? Do you have any interesting customer stories to share um or or maybe even um customer pain points, like brick walls you ran into that you had to break your way through in order to make your customers happy.

PETER: 00:27:32
So just to tie this in with the conversation about extensions and how good that is. So the main problem has always been, well, two things. One, compatibility and two, performance. And for the most part, for the initial year, we focused on compatibility because Alexey, my co-founder and I were talking a lot about where to start actually. You have a lot of comments to implement, you have a lot of features to implement, and you also have quite a good performance in terms of what MongoDB can deliver to users. And we kind of need to have both in order to provide a good alternative. But we had very limited resources, of course, and it's just not possible to focus on everything. So we ended up focusing on compatibility because our assumption was that there is no value in FerretDB if it just performs, but it is not compatible. Whereas if FerretDB is compatible with MongoDB, that's already valuable to users, even if it does not perform the same way as MongoDB. And by the way, it still doesn't, so we are very open about that part. So when it comes to extensions, we did not start to implement FerretDB as an extension. It was a proxy which translated SQL queries between MongoDB drivers and Postgres. So we got the MongoDB API on one side and the Mongo queries and we translated back and forth between Postgres. But the obvious problem in this is not just the overhead, but also some of the missing things in Postgres core, like certain data types, which are expected to exist from the MongoDB side in BSON, but it was not something which we had in Postgres JSON. So these workarounds were really detrimental to the performance of FerretDB, but it enabled us to be compatible. So if you think of FerretDB 1x, which was not based or is not based on an extension, it is fairly compatible, but it does not perform due to these missing features in Postgres to support MongoDB workloads. And when we started working with the Microsoft DocumentDB team and they provided their...

CLAIRE: 00:30:54
Which I want to be clear, that's not me. That's a whole different team at Microsoft. I'm on the Postgres team. So anyway, keep going.

PETER: 00:31:02
Microsoft is indeed large. Yes, as we came to understand, or not understand, the org chart, that is. So the main point of the Postgres extension was to introduce these missing features without having to change anything in core Postgres. Because if you fork core Postgres and you add features there, then you kind of have this strange flavor of Postgres and you can just tell users that, hey, if you have Postgres, you can just slap FerretDB on top of it and be compatible and perform well with MongoDB workloads. And you need to have this different flavor of Postgres, which is kind of hard to manage from an operational standpoint. But those users who are equipped with the ability to just add Postgres extensions, and if the extension can add all of these features to Postgres in a performant way, then everyone wins. And this is exactly the power of Postgres extensions. And I fully believe that some of these features which live in extensions, if they are used enough, they will end up in core Postgres. So with the Microsoft team, we worked in combining FerretDB and the DocumentDB Postgres extension into one Docker image anyone can run. And that provides a MongoDB-like experience, not just in Azure, but anywhere the user wants to run it. And this is what users want. This is what someone trying to move away from the MongoDB vendor lock-in would actually want. Because that's a true alternative, which is not tied to any given vendor out there.

CLAIRE: 00:33:34
Can we circle back to something you said probably about 90 seconds ago? You mentioned BSON and JSON. So for someone who's listening who is um has worked in Postgres for years and is obviously familiar with JSON and JSONB what what is BSON what's the connection between those two things?

PETER: 00:33:57
So JSON, both JSON and BSON, are basically the document database workload support in relational database. JSON is, if I remember correctly, it's a JavaScript Object Notation and BSON is a Binary JavaScript Object Notation. BSON is, I'm not sure if you're familiar with how MongoDB actually came to be. So they actually use a relational database engine called WiredTiger. So they still had to implement document database capability in a relational database engine. And that's exactly what Postgres did as well with JSON. JSON contains basic data types, whereas BSON comes with some extra data types, which MongoDB uses very heavily. It does use more space, it supports indexes, and it stores data. And maybe Alexey can correct me if he's listening, my co-founder Alexey Palashchenko, but well, I think from the name it's clear that it also stores data in binary whereas in a standard format. So these differences are pretty big and using just JSON to emulate BSUN while it's possible and we have quite extensive blog posts on how to do this. Ultimately it will never give you the performance which stock MongoDB would be capable of.

CLAIRE: 00:36:09
So I know, or I believe as a CEO of this company, as the co-founder, you probably talk to a lot of people about Ferret, you talk to customers investors, interested like supporters out in the world, or advisors, or whatever. What are the kinds of things that surprise people, surprise your customers? Have there been any interesting lessons that you want to share? I know that's, well, I didn't prepare you for this question.

PETER: 00:36:42
I'm enjoying not being prepared for questions because it actually gives me a moment to think about it, or opportunity to think about it. I would say that one of the biggest surprises customers usually, or users usually, have when thinking about moving to FerretDB is that it's actually possible. So most MongoDB users have a hard time to believe that Postgres is capable of doing all what MongoDB does. And it's quite cool to talk about this with them and introduce this concept to them. And, you know, some of these MongoDB users are not Postgres users. and they are not familiar and they think of Postgres as, well, what the MongoDB marketing team usually says, that Postgres is this archaic and outdated and horrible technology which is very hard to use and not good for you. This is verbatim what MongoDB marketing would tell a user who would inquire about Postgres, not just their marketing team, but in general, all of the content you see from MongoDB. They don't like Postgres and when we show MongoDB users that this is actually a viable alternative and it's available, then that's obviously a big surprise. And, you know, well, some iPhone users might or iOS users might not like this idea, but I believe that it's also surprising for those who see the variety of what's available out there. Think about all the different vendors you can go to when you want Postgres as a service, for example. So for a MongoDB user and for an iOS user, for example, the variety of what else is out there might be very, very surprising that you don't just have three vendors who can run MongoDB for you with essentially the same kind of pricing, but you can have 50 or 100 plus who can provide you Postgres as a service, run FerretDB on top of it and provide you a better experience than MongoDB could when it comes to the whole package, like availability or extra features or combined offerings or just pricing in general. So I believe that this is the most surprising thing, that you have users who were logged into some certain platform or MongoDB Atlas or whatever else, and we can introduce this whole ecosystem to them, which is much more colorful and comes with a lot more opportunities and flexibility than they are used to. I believe this is the most common surprise which we experience when talking to these users.

CLAIRE: 00:40:27
I wrote down the adjectives you shared, which I completely disagree with when it comes to Postgres. Archaic, outdated, horrible, not good for you. I do not agree with any of those.

PETER: 00:40:39
Not my words. Not my words.

CLAIRE: 00:40:42
Good, good, good. Someone told me that Ferret is written in Go, is that right?

PETER: 00:40:51
Yes, Ferret is written in Go and this has been consistent for the very beginning even though some people wanted to convert us to Rust early on and later on as well, but we believe in Go and we are Go shop.

CLAIRE: 00:41:11
Okay. Is that, I mean, does it matter to users or to customers or is that just an interesting thing that some developers, particularly ones who are, have preferences and languages care about?

PETER: 00:41:28
You know, some users have preferences, but I believe that they are the minority. So some users have extensive experience with Go and we have some capabilities which they can leverage as Go developers like we have some embedability feature in FerretDB which makes you able to just run FerretDB as a go library. Alexey might kill me saying this because it may not be fully specific or correct what I'm saying right now but my understanding is that we do offer some positive, you know, function, we provide some functionality which is specific to those who, who might also develop their applications, their MongoDB related applications in Go. But I would say it shouldn't matter. So I'm not interested in what language the OS I'm using is written in. And I believe that most database users would not be interested as well. Maybe DevOps teams would be interested, but I would say that's a minority.

CLAIRE: 00:43:01
Okay. I'm going back to the fact that you wear this hat, right? I have this belief that sometimes the jobs people have or the roles they have in a company end up changing them, end up changing the worldview. So, I don't know, I'm making this assumption that you're CEO, you talk to a lot of people, you have to evangelize what Ferret's doing. And so that means you have to explain to people, like, why does open source matter? And I'm coming at this question with a bias. I think open source matters. But I'm curious whether you've come up with any analogies or any ways of helping people who don't already have their own belief that open source matters. How do you help get them there? How do you help explain it to them?

PETER: 00:43:54
Well, that's a great and timely question. I'm also biased, of course, because similar to you, I've been working with open source for a long, long time. and I do believe that that's a good thing in technology. But there are some users who... Well, first of all, I don't think that it is their fault. So marketing around open source has been pretty murky or sometimes even downright, I would say, deliberately confusing, if you will, because lots of products were marketed or are marketed as open source, which are really not open source, and MongoDB is one of them. So when you come up with a license which is not open source, but say things like, "Hey, this is just as good as open source and more." You know, that's not open source and you're deceiving users to think that open source is how you define open source at a marketing team, at a large corporation. And I believe that we have a problem in our community, the open source community, where the voices of those who really understand what open source is and understand what is the open source definition and how licenses are expected to be adhered to these standards are not as loud as a billion dollar corporation who says things like, hey, the SSPL license is just as good as open source. So our voices are a lot less amplified as the voices of those who want to bend open source according to their business needs. And I think that one of the hats I'm wearing is trying to explain the difference between a false or fake open source license compared to real open source and I have lots of people who would say stuff like "hey, SSPL is open source" and again it's not their fault, that's what MongoDB or Redis or Elastic or some others told their users for years and you know I'm picking on SSPL, but it's BSL, and it's all of the other false or fake open source licenses included. And it's pretty hard to explain the difference. It's pretty hard to make a case that, hey, only the OSI approved licenses are real open source licenses. And someone would ask, you know, why? Who is the OSI to define? Why can't anyone else define what open source is? And in reality, anyone can use open source. It's not a trademark. It's not something which is protected by, you know, government organizations or the patent office or the trademark office or whatever else. Unfortunately, anyone can say that something is open source without complying with the open source definition. And so part of my job is to explain why the SSPL is bad for you, because in this specific case we are dealing with the SSPL and fortunately more and more people understand and more and more organizations understand that it's not as good as open source. Just last week, Redis, one of the newly SSPL-licensed products, announced that they are moving back to a proper open source license. Elastic did that, I think, last year. So I'm seeing positive trends in this area, but the problem is still the same. How can we define, how can we explain open source to those who are not spending their daily lives thinking about open source all the time and just want to benefit from the positive side of open source? That's definitely a challenge. And some voices are still louder than us.

CLAIRE: 00:49:01
It is a tough thing to explain. For someone who's listening to this and wants to dive deep after the show, I have known Stephen O'Grady of RedMonk for years, and he is a brilliant explainer. He's been at a boutique analyst firm that he and James Governor co-founded at RedMonk. Gosh, since when did I first meet him? In the mid-90s? So he's been around the block for a while, focused on open source developer communities, and wrote a book called The New Kingmakers. Anyway, just yesterday, he published a blog post about this very topic that you just mentioned. And I dropped the link into the show notes or into the Discord, and I'll include it in the show notes. And it's called "Two Steps Forward, One Step Back." But he explains SSPL and AGPL and OSI approved licenses and why you might care. and why you should care and kind of gives a little bit of the backstory along what just happened at Redis because this is very much new news. So if anyone wants to dive deeper, that might be a good place to start. I don't know if you have your favorite places that you direct someone who wants to learn more. If you do, let me know and I'll drop that into the Discord as well, Peter.

PETER: 00:50:24
So there is this very... mysterious website called ssplisbad.com. I don't know who did it, but I like to direct people there because it's not affiliated with any organization, although we don't know who made it. I promise it was not us. It actually predates FerretDB, but ssplisbad.com is definitely a good one. We also have some SSPL related blog posts on blog.ferretdb.io on our blog. So I think there are really strong and experienced voices all around the internet talking about this very topic and it's great to see that people not only recognize, experts not only recognize the need to talk about this, but the discussion is still very much alive years and years after SSPL appeared. And of course moves like Redis or Elastic moving back from SSPL to their original license, I think both were AGPL, maybe not, is definitely a positive change. And I think some bloggers and Salvatore Sanfilippo, the original author of Redis, explained how they expected SSPL to be accepted by the community and the community did not. And that's the power of community. That's the power of the community that, you know, our voices are heard by these organizations. They draw on the consequences and they take action. So it's not even pointless to talk about these problems as we see action on the organizational side.

CLAIRE: 00:52:40
All right, so let's pivot away from licensing for a second. I want to talk a little bit more about you and kind of how you got started at FerretDB. I was looking at your official bio on the POSETTE website, and we'll come back to POSETTE in a second. And it said you have a quote unquote passion for reading and exploring. And someone might see that and think, yeah, yeah, yeah, whatever. But I was curious, like how, what do you read? And how does what you read influence your job, influence what you do for Ferret? Same for exploring. I mean, obviously, we already know that you went to the Himalayas and this company was founded as a result of that trip and your time in a tent at 17,000 feet with Peter Zaitsev. But yeah, tell me more. Passion for reading and exploring.

PETER: 00:53:32
So the reading part, I wish I would have more time to read fiction. But that's actually not really part of my life nowadays or for the past couple years, definitely. But I'm reading a lot of Peter Drucker. I'm reading Dale Carnegie. I'm reading some original management-related authors whose work is often used to write new books on the matter. Like if you see all these Amazon bestsellers on how to manage organizations, on how to manage software, on how to do this or that in business, if you read some of the old school stuff out there, you realize that a large chunk of these new bestsellers are based on the original teachings, as it should be actually, of these great authors. So that is mostly what I'm reading. I'm also, you know, I don't smoke. I don't drink. I read Wikipedia. It's a problem. I can read the most random stuff from plants to space exploration. You know, it's a problem, I admit. But, you know, it's one of my favorite hobbies to just... explore and read about things which I may not even hear about if it's not for Wikipedia. I think Alexey mentioned, my co-founder, that he's suffering from the same addiction. So maybe we have these shared company values here where we read a lot of weird and random stuff on Wikipedia. When it comes to exploration, my friend and bad influence, Peter Zaitsev, and I went to lots of different mountains out there. Most of them are above 400 meters, but there are some even above 7, sorry, not 400, 4,000. And we even went to Aconcagua, that is 7,000 meters plus.

CLAIRE: 00:56:15
Where? Say it again.

PETER: 00:56:18
Aconcagua in Argentina. That's 22K or 23K feet for those in the US. So we do have this passion for mountaineering and I quite enjoy to go outside and just go to places which are very remote and where the situation may not be cozy because it kind of reintroduces some suffering into your life in terms of getting exposed to weather and really bad food and places where there's no beaten path. I quite enjoy that and I would to do it as much as I can. And this is how FerretDB was born. So, you know, it's proven that it stimulates the brain and, you know, there are some good ideas I have and some bad ideas when I come back from these trips. We actually have this initiative called Geeks Go Peaks, GeeksGoPeaks.com, shameless plug, where we are trying to introduce this concept to more and more people in IT who spend their days for the most part in front of some screen to go outside and do things which you never think you're even capable of doing. Our next trip is Via Ferrata trip near Bolzano, Italy in May, but if you check out the website, we do have some other trips planned, which are ranging from caving to mountaineering to exploring some abandoned stuff. I think that's just planned, but it will definitely happen. So, yeah, that's just an initiative which introduces this hobby to those who would say, "oh, I'm never going to be able to do that", or "oh, I'm too fat", or I'm too, you know, well, wimpy or less able or just too geeky. to go outside and climb a mountain. And our trips are a success for the most part. And lots of people realize that they can do so much more in the physical world than they thought they can. And that includes me as well. I never thought I would be able to see the K2 with my bare eyes and, you know, go there and experience the altitude and all that. And it turns out that we are much more capable of doing things than we think.

CLAIRE: 00:59:37
I am way more selfish a person than you. I think it's amazing. I didn't know about this Geeks Go Peaks thing and that you're sharing your love of doing this and the benefits that you get from this mountaineering and this outdoor adventure. Like I go sailing in Greece every summer for a week or this year it'll be two weeks. And we we bare boat charter a boat and we go from island to island. And unless you're in charge like we are, like our friends, the biggest decision they have to make every day is like what color bathing suit am I going to wear? And it's it's amazing how it changes my perspective. You know, I get back to work and I really am, different. So, but I've never thought of sharing that, right, or making it available or encouraging other people to do it in that way. So very generous of you.

PETER: 01:00:29
Well, you know, it's also, you know, I think the more people we have there, the better for us as well, right? We talk to new people, we hear new ideas, we share an experience much differently than if we would have went alone. So I don't think that this is generosity, but more like enhancing how we are doing this. And it's kind of like open source. Is open source generosity? I don't think it is. Open source is good for everyone involved if it's implemented the right way, if nobody's exploited. So it's kind of similar to open source where you share and you get things back in return. I think the concept is pretty similar if I think about it.

CLAIRE: 01:01:31
All right. So you mentioned a second ago that when you do these amazing adventures, like your trip to the Himalayas, that you come up with some really good ideas, like FerretDB, but you also come up with some bad ideas. And when you said bad ideas, I thought to myself, yeah, like the name, MangoDB. So, which of course it isn't now. Now it's FerretDB. You didn't stick with MangoDB. But I'm curious, did you have any other bad names that you considered for this company?

PETER: 01:02:01
We all have bad names.

CLAIRE: 01:02:03
I like thinking about names. So to me, it's an interesting thing. So what will you share? Any other bad names?

PETER: 01:02:12
Honestly, I think I have the document somewhere where we came up with lots of different names. And the reason why we named, well, FerretDB, initially MangoDB, is because we ate a lot of mangoes on the mountain and it kind of sounded like mongo. And then my father is a patent attorney and trademark attorney. And when I got home and I told him about MangoDB, he told me that this might not be the best idea, to put it simply. And of course, we kind of knew that this is going to be a project name. So the way how we came up with FerretDB is the three of us had quite a lot of calls, Alexey, Peter Zaitsev and I. And we discussed a lot of different names and I don't even know. There were different types of or different species of mangoes involved in the naming and then lots of animals. And the reason why we decided on Ferret is first of all because we had a domain which was available ferretdb.io, not ferretdb.com. We acquired that later when it became abandoned. ferretdb.com was the ferret database, which was done by a lovely lady somewhere, maybe in Canada, maybe in the US, where she created this database of the different types of ferrets and then she abandoned that domain and that's when we registered it. So that's when we got ferretdb.com, but it was crazy hard to come up with a name which did not exist already. And I think that's a pain whenever you start a company or a project. I envy you, Claire, if you like thinking about names. I'm not the same. I'm also having a daughter in two months, so that's also a naming challenge. But back to FerretDB.

CLAIRE: 01:04:40
Congratulations.

PETER: 01:04:41
Thank you. So the reason why we went with FerretDB is because first the domain was available and second, and we realized this later. So I'm not trying to say that this was deliberate, but in English, and none of us are native English speakers but in English there is such a thing as to ferret something out, which is to seek for something and fetch it and I think that's what the database does. So I think it turned out pretty good and in open source no one is going to flinch if your product is named after an animal. We have the Postgres elephant, the Hadoop elephant, the MySQL dolphin. So, ferret, why not?

CLAIRE: 01:05:38
The Go language has a gopher, right?

PETER: 01:05:41
A gopher, yes. Alexey has a lot of plush gophers, yes. I wonder what rust has, I don't know. Is it a rusty rebar?

CLAIRE: 01:05:52
I thought it was a crustacean. [Maybe. Actually.] The Rust mascot language. Let's see. I'll look that up really quickly. Ferris is the unofficial mascot. Many Rust programmers call themselves Rustaceans. So the fact that I have to look this up shows you that I am not a Rust programmer, right?

PETER: 01:06:12
Me neither, but Ferris the crab, that's almost ferret. See? So everything points to the direction of Ferret.

CLAIRE: 01:06:21
Yeah. I've often said that all good open source projects have a mascot. And for whatever reason, it's nice. I worked at Citus for a couple of years before kind of moving my focus over to Postgres more generally. And at Citus, our mascot was the Elicorn, which was part elephant in homage to Postgres and then part unicorn, because the idea was by scaling and distributing Postgres, we made it magic.

PETER: 01:06:51
So that, that's a bit more creative than what we did. A unicorn elephant is definitely original for sure.

CLAIRE: 01:07:03
Well, I'm glad you brought up the whole mascot thing because in researching for the show, I'm a big fan of the Postgres Weekly newsletter that Cooperpress, Peter Cooper, publishes every week. I find it a really useful way to kind of try to stay current. That and the whole Planet Postgres syndication in the world that I work in. And anyway, I think it was earlier in March at some point. One of your blogs or articles got linked to at the very top of Postgres Weekly that week. And that the graphic that he had at the top of the newsletter that week was a ferret and an elephant kind of looking at each other. So, you know, it makes for good artwork.

PETER: 01:07:50
Yeah, especially in the age of AI or, you know, generative AI, definitely some crazy stuff. And I agree that Postgres Weekly is just amazing. And it's, you know, I'm not a fan of a lot of newsletters, but that definitely stands out as something where you can actually keep your finger on the pulse of the Postgres community and we were very honored to get featured basically with most of our new releases in the Postgres Weekly and we were very grateful for Mr. Cooper to do that for us.

CLAIRE: 01:08:32
Well, the other thing is I'd like to think I'm a decent writer. Part of my joke is that I no longer program in C or have a favorite development language my programming language is now English. And, um, you know, I spend most of my time communicating in email or talking to people or giving conference talks. Like it's just, it's a different way to express your ideas and your thoughts. So I'd like to think I'm decent at it, right? And I'm not, I'm not being modest, I really am just decent at it. But Peter Cooper, he writes at a whole nother level. Like I look at the way in which he describes the things he's run across over the week. And the the twist of phrase and the insights that he derives from them, he gets to the crux of whatever each article or blog post or whatever is about. And I don't know, I wish I could write like Peter Cooper.

PETER: 01:09:40
I wish too. Yes, I share your experience reading whatever he writes. Definitely. Definitely. There's a reason behind his success, I would say.

CLAIRE: 01:09:52
Yeah. And he doesn't make things more boring than they are, which a lot of people do, maybe because they don't fully understand whatever the article was. He makes things more interesting than they are, maybe in some cases. He entices me to, okay, I better go read that thing. So anyway. All right, enough fans.

PETER: 01:10:14
Some things AI can't really do. For some reason, I participated in multiple panel discussions where I was also expected to share my views on AI, and I'm by far not an AI expert, but when some people said that writers will all lose their jobs and it's going to be just hell for anyone who is doing creative work, I don't think that that level of quality can be matched by AI. Like when you mentioned Peter Cooper or some of the other articles you can read from engaging writers, just my opinion, but I think there's still plenty of space for people to write good content, and I wish I would be one of them. I'm unfortunately not, so that's that.

CLAIRE: 01:11:19
It's May, next month is June. I can read a calendar, very impressive. But I'm thinking ahead to POSETTE. So I was on the talk selection team for this year's POSETTE: An Event for Postgres, along with some other amazing Postgres people, Melanie Plageman, Daniel Gustafsson, and KK Ravi. And one of the things, as a talk selection, team that we try to do is combine conference speakers. It's a virtual event that happens annually, and it's organized by my team at Microsoft. Teresa Giacomini is the chair, and one of the things we did on the talk selection team is we tried to mix together speakers from outside Microsoft, speakers from inside Microsoft, people focused on like the core Postgres open source, as well as people talking about some Azure managed services, and things in the extension ecosystem, and the broader Postgres ecosystem as well, not just the core. So anyway, I was really excited that we got to consider and accept your talk because I think it's important that this conference span all three of those areas. And your talk title that's coming up is From MongoDB to Postgres, Building an Open Standard for Document Databases. I don't know if you've done the recording yet. I know all those talks are prerecorded and then live streamed in June. Have you done it yet?

PETER: 01:12:56
Yes, I did. It was an honor to be selected to one of the tracks on POSETTE. And yes, we did the recording. It was very professionally organized, by the way, Teresa, and, you know, the rest of the team is awesome. And I'm very excited to attend the virtual event. So I think the talks are pre-recorded, but then all of the speakers will be attending live and answer questions in the chat. That's my...

CLAIRE: 01:13:31
Always a tough nut to crack. I know, I mean, next week I'm going to be in Montreal at PGConf.dev, which is the annual Postgres Development Conference. and there's just this wonderful, warm kind of feeling that you get from the hallway track, from meeting people, from breaking bread with them, from spending time in person. It's pretty wonderful. But the thing I really like about virtual is even though you don't get that kind of endorphin rush, there are so many people who cannot travel to an event, right? They don't have the budget. They're between jobs. They have elderly parents. They have young kids. They're going through a divorce. Whatever the reason, and I just really like the fact that speakers like you, even if it's not maybe as comfortable without an in-person audience, to kind of give you energy while you're doing your presentation, that speakers like you take the time and make the effort to give a virtual presentation because then so many more people are going to get to watch it and benefit from it So that's that's my soapbox on why POSETTE is virtual, and why it should be virtual. Anyway, I want to thank you.

PETER: 01:14:45
Totally agree. Totally agree. And sorry to cut you off, I just wanted to add, you know, there are Postgres community members all over the world, including countries which are very, very far from Montreal or the Bay Area in California or other places and it's a very very good thought and a good fit for this community to have a well-executed online event and as far as I see POSETTE is going to be one of those and and again i'm really excited to take part.

CLAIRE: 01:15:24
Well thank you, and you'll be talking more about some of the things I think that we've talked about today, and it's not going going to be exactly the same. This is a conversation where we jumped all over the place. I'm assuming your presentation is probably a little more coherent, or has a narrative, a narrative thread that kind of ties it all together. Do you want to give us a teaser?

PETER: 01:15:54
Absolutely. So my talk is going to be, as you said, From MongoDB to Postgres, the creation of an open standard for MongoDB is the essence of my talk, where I will be talking about how SQL came to be as an open standard. How did it happen that we have this common query language, which can be used all across several different database products, and the initial challenges they had, how it came to be, how it was implemented after becoming an open standard, what challenges did this open standard solve, SQL that is in the 90s, how Postgres and other products decided to implement SQL and how did it happen that we are where we are now, where there are hundreds of different derivatives of the relational database concept and the SQL query language. And then, of course, because I'm very biased towards this problem of MongoDB, I'm going to explain where MongoDB is in this journey, or is there a journey towards standardization. And the reason why I'm talking about this, you know, going back to having all these different alternatives to MongoDB. So these are not based on an open standard and that creates lots of challenges along the way for users, for developers and for the developers of these standards. And I'm attempting to make the case for the community to come together to work on an open standard for the MongoDB query language or for document databases in general. So developers will have the ability to develop against a similar open standard as what they use in the relational world. And that is a much better thing instead of having to track how the current MongoDB alternatives are different compared to each other and trying to bridge those gaps from the application side if someone wants to migrate between them. So this is what the talk is going to be about. And another shameless plug, so we have the opendocdb.org initiative where you can read more about this push towards creating an open standard for document databases. So most of my talk is going to be about making the case of that. It's not going to be a FerretDB commercial. So it's going to be purely describing the problem and what needs to be done to help developers and help users to get document databases where they belong, which is a solid foundation based on an open standard.

CLAIRE: 01:19:14
I just dropped the link to OpenDocDB in the [chat], I'll be sure to put it in the show notes for the podcast episode, and I dropped it in the Discord.

PETER: 01:19:23
Really appreciate it Claire.

CLAIRE: 01:19:25
Well I was wondering if you were going to mention it and I didn't realize that my open question about your POSETTE talk was going to take us there so there you go. Killed two birds with one stone. Okay, so is there anything I should have asked you today that's really interesting about the topic How I got started at FerretDB and why we chose Postgres? Did I miss anything? Did we miss anything?

PETER: 01:19:52
You know, I don't think so. Your questions were very thorough. I think that I got some questions, which I was absolutely not prepared for. And I quite enjoyed having to think about, you know, the surprises and everything else users hit when they first hear about FerretDB or what, what I need to explain. And we went all the way from the beginnings to the potential open standard. So I believe that that's quite, you know, a wide discussion around everything we have. So, yeah, I think...

CLAIRE: 01:20:36
I have two more questions then, of my own. The first is, if I were to pass along your perspective to the team at Microsoft that open sourced DocumentDB earlier this year about how it's going, what would you say? What should I tell them about performance or about them showing up for the community, about reliability, anything? Any feedback for them?

PETER: 01:21:09
I told the team already that as a member of the open source community, I'm very proud that Microsoft did the right thing with open sourcing what they have. They gave tremendous value to the community and this sounds like a Microsoft commercial, but this is really from the bottom of our hearts. When it comes to FerretDB, we really appreciated that they took the time and effort to go through this whole approval process and the work to make sure that this can happen. And I believe that what we need to focus on moving forward and not just Microsoft, but others in the community, inside and outside of the community, is to push for the open standard. And I've heard Microsoft blogging about it already and, you know, talking to the other hyperscalers out there. They are definitely interested, but it needs to happen. We need to push for it, and it needs to be a collaboration, and it needs to happen soon. So my feedback here is that open sourcing is one thing and it's a big step, but the biggest step would be a strong collaboration on the open standard. And this might be harder not to crack, but I'm sure that it's in everybody's interest and we are going to get there.

CLAIRE: 01:22:41
Okay, I'll make sure to, I don't even have to pass that along, I can just send them a link to that part in the podcast episode. Okay, final question. Cheese. We've had a couple of guests who've had really strange stories that connect their work in Postgres with cheese. I think I've had four so far. And so now I've just tried to get to the point where I remember to ask about it. And it's OK if you do not have a cheese story. Not everybody does.

PETER: 01:23:16
A cheese story. Well, actually, I have one related to the creation of FerretDB. So when we went to the K2 Base Camp, we did not do this all-inclusive thing where we have a lot of porters to bring stuff for us and all that. We were bringing our own stuff for the most part. All the fuel, all the food, all the equipment. So it was pretty tough. And that meant that we had a very limited choice in food. And we were a team of five. I'm sure a lot of you would be familiar with Oleg Bartunov, who is a prominent member. He was there, a prominent member of the Postgres community. And he had a strange choice of food. Basically, all we were supposed to eat was seeds and horse sausage. And that was not my choice of food. I was very much struggling to eat all of those things. So the only thing that kept me alive was some cheese I brought from Hungary and some sausage I brought from Hungary, which I shared with Peter Zaitsev, who was also not fond of the availability of edible food. And I believe that, you know, if I don't have that cheese with myself, there may not be FerretDB. We would not be talking today because I would have abandoned the push for the base camp, very possibly. I was very unhappy with the food. So, you know, when you first ask me whether I have a cheese story related to Postgres, I was not sure. But thinking about it, this is very much relevant.

CLAIRE: 01:25:25
Do you remember what kind of cheese it was? The Hungarian cheese that you're talking about?

PETER: 01:25:30
It was Trappist.

CLAIRE: 01:25:35
Trappist? Okay. I'll try to look that up.

PETER: 01:25:39
It's very common in Hungary. It's actually not a very extreme cheese in terms of how it's made or, you know, there are some cheeses. My father is very fond of these very smelly cheeses. Sometimes when I'm in Belgium or the Netherlands, he asks me to get some for him. And I need to bring four of these Tupperware boxes inside each other. And it still smells.

CLAIRE: 01:26:18
Like a nesting doll.

PETER: 01:26:21
Yeah. And the cheese would be right in the smallest one inside. But it still smells. Once I went to Belgium with my car and I brought cheese for him. And my God, it was an experience going back. But yeah, I don't think I would be able to eat those for sure.

CLAIRE: 01:26:44
Well, Peter, I want to say thank you very much for joining us today. It has been delightful to get to know you a little bit, talk to you about your story, share it with everybody who's going to listen to this episode once we publish it. And I wish you all the best with FerretDB. And I love that you're using Postgres.

PETER: 01:27:06
Thank you very much, Claire. And thank you to those who listened. It was an honor to be here. And I also wanted to take the time to thank the community for their support during all these years. And we really made the right bet when we chose Postgres and we engaged with the community. You were all awesome, and it's really an honor to be here and work alongside with all of you.

CLAIRE: 01:27:36
Thank you. Now, for those who are listening, if you like today's episode and you want to hear more of these Talking Postgres episodes, you should subscribe on Apple, or Spotify, or YouTube, or wherever you get your podcasts. And please tell your friends too. A word of mouth recommendation is what makes podcasts succeed. It's what enables them to continue to exist. So if you leave a review, that will help even more people discover the podcast. You can always get to past episodes and get links to subscribe on the different platforms by going to TalkingPostgres.com, and transcripts are included on the episode pages too. And a big thank you to everybody who joined the live recording and participated in the live text chat on Discord. Thank you. [Outro Music]