ProvenDB BlockChain Tech to Databases, All Things MongoDB - Percona Podcast 25

Link to listen and subscribe: PodBean

Guy Harrison, CTO @ ProvenDB (AKA: Southbank Software) is the special guest of Matt Yonkovit in The latest HOSS Talks FOSS Ep25. Guy has authored several books on database technology including MongoDB Performance Tuning, Next Generation Databases, and the Oracle Database Problem Solving and Troubleshooting Handbook. He is currently the CTO of ProvenDB where he is bringing BlockChain tech to databases. In this episode we talk about all things MongoDB, Databases, and the future landscape of technology

YouTube

Link: https://youtu.be/nmJWhrxmG-8

Guy Harrison

CTO, Southbank Software

Guy Harrison is CTO at Southbank Software, a database and blockchain tools company. He is the author of MongoDB Performance Tuning, Next Generation Databases, MySQL Stored Procedure Programming and many other books, articles and presentations on database technology. He writes the “MongoDB Matters” and “Emerging Technologies” columns at Database Trends and Applications.

See all talks by Guy Harrison »

Matt Yonkovit

The HOSS, Percona

Matt is currently working as the Head of Open Source Strategy (HOSS) for Percona, a leader in open source database software and services. He has over 15 years of experience in the open source industry including over 10 years of executive-level experience leading open source teams. Matt’s experience merges the technical and business aspects of the open source database experience with both a passion for hands on development and management and the leadership of building strong teams. During his time he has created or managed business units responsible for service delivery ( consulting, support, and managed services ), customer success, product management, marketing, and operations. He currently leads efforts around Percona’s OSPO, community, and developer relations efforts. He hosts the HOSS talks FOSS podcast, writes regularly, and shares his MySQL and PostgreSQL knowledge as often as possible.

See all talks by Matt Yonkovit »

Transcript

Matt Yonkovit: Hi, everybody. Welcome to another “HOSS Talks FOSS”. I’m here with Guy Harrison from ProvenDB, who just gave a great talk, 2 great talks, actually, at Percona.Live on MongoDB performance tuning as well as on the changing face of databases and the evolution of databases. Guy has written several books about databases over the years. And he’s got two books currently authored and out there. And he’s working on a third. So that’d be great to sit down and have a chat with him today. So, hi, Guy, how are you doing?

Guy Harrison: Hi, Matt. Hi, everybody. Great to be here. Thanks for having me.

Matt Yonkovit: So tell us about the books that you currently have out?

Guy Harrison: Well, I’ve got a fair few older books that no one’s really interested anymore. There’s a couple on Oracle. My first book was a book on Oracle tuning. This was quite before open source databases were a thing. And that was quite popular in the day, we’re talking about the 90s here.

Matt Yonkovit: I might have read it because I was an Oracle DBA back then.

Guy Harrison: Okay. Well, it was quite popular at the time as there weren’t quite as many books in those days as there are now.

I wrote the O’Reilly book on MySQL stored procedure programming, work with the MySQL team. And that’s where I met Peter Zaytsev, if I’m pronouncing that correctly, 2003. And I bumped into him forever since then. And it’s been great to see his journey. It’s been fantastic, right.

And then I wrote a few more books on Oracle. And then 2015 are right “Next Generation Databases”, which was my attempt to take everything I’ve learned about databases, in my role as VP of Engineering at Quest software, which is a large database tools company, and the emerging sort of trends that we saw in open source cloud, NoSQL, big data, that sort of thing. Most recently, “MongoDB Performance Tuning”. The startup I used to haveve been working with, using MongoDB as our backend and learnt a lot about that over the last five years, decided to put that down with my son, actually. So I was on one end of the age spectrum and he’s at the other side. Hopefully, we balanced perspective between that I’ve got a lot of long term experience that sort of might be relevant and he’s got a modern developers viewpoint. So it was great working with him, obviously.

And then right now, I’m working on “CockroachDB: The Definitive Guide” with two of the guys that have the CockroachDB team.

Matt Yonkovit: So, you’ve seen many different databases over the years. And what led to this explosion of the number of databases? I mean, we’ve seen this as well, some of the data and some of the things that I’ve brought up before…Everybody’s using many different databases now, they’re not just choosing one. But it seems like every month there’s a new database popping up. New technology, it’s based on one of the granddaddies, as you mentioned in your talk, it could be Spanner, it could be a document database, could be something else. But what do you think is causing all this growth?

Guy Harrison: Well, you know, for a long while the Oracle and SQL Server and even MySQL to a certain extent had a sort of a stranglehold on the database market, everyone was using the same model, the relational model, the same language (SQL), and there wasn’t much room for innovation around that, because, businesses just weren’t interested in anything else. So the object oriented databases were struggling to get attention, and they just couldn’t break through.

But the cloud and the Internet really changed all that we had. Suddenly, we had applications that had to span the globe, and be always on. And if there’s one thing that the relational database just doesn’t do all that is handled downtime in a globally distributed way. So you can’t distribute an Oracle database across every continent of the globe and expect it to stay up if there’s any network issues. No one does that, no one even tries. So that was one of the pressures. I guess the other was that developers used not to be in charge of these decisions. So back when I was a developer, you got no choice and no say whatsoever in the technologies that we use in the application. There’d be some sort of senior architect or something, you’d say “We shall use Oracle. And we shall use Java”. But with open source coming along, developers got a lot of, they could just pick up a database and just start running with it. They didn’t need to set aside an invoice or anything like that.

By the time we’re talking about (2009-2010), as well as object oriented programming still wanting something different, there was also the pressures of continuous integration, wanting schemaless databases, databases, where the schema could be completely defined in the code. So as soon as you checked into GitHub, you could run a build, deploy, and you didn’t have to get a DBA to come along and do an ALTER TABLE. And so that was another pressure coming along, as well as big data, we had more applications with data that just was too voluminous and unstructured to be handled by these models. So that broke the back of the relational dominance. And that caused a huge amount of innovation from bet 2009 on, and you’re right, like to think there’s a new database every day at the moment. But in 2009-2010, that was literally true. As soon as it became obvious that you were allowed to create your own database so many came out, it was kind of bewildering. But, I think, now we’ve seen a certain amount of settling down. I can keep talking a lot, but just…

Matt Yonkovit: I think that, one of the interesting things that you mentioned, there was that shift with the developer focus, and the developers being able to start on their own. I mean, I mentioned, I was an Oracle DBA, back in the day in the early 2000s, late before 2000, and in the late 90s, and I remember projects that I wanted to work on. If I wanted to use an Oracle database as a backend, there just was no way because the cost of just getting something even small was improbably high. And so it became something where you really needed to have that alternative. And I think that that shift that happened over the last 10 years to where developers get to choose, has caused a couple of interesting things to happen.

Number one, it has really facilitated a lot of growth in the number and types of databases. I know, you’ve talked a little bit about the graph SQL databases for some things, you’ve talked about some of the more Hadoop-like things for the quote noquote data lakes, you’ve talked about some of the document databases, some of the NoSQL databases, some of the relational databases, all these different databases have grown, and developers tend to choose what they’re most comfortable with, or what they think will fit that particular application. And now you’ve got all the who used to hold the keys of the kingdom, the infrastructure teams, getting thrown over like “Oh, here’s a new database you have to support”. And I know that I’ve seen this from an operations perspective, especially from a lot of people that I’ve talked to. They have no practical experience in, let’s say, running MongoDB. And all of a sudden: “Oh, we developed this application, it’s in Mongo, deal with it”. It’s an interesting space.

Guy Harrison: Yes, that’s very true. And when you’re working with companies like MongoDB, you see when they start to make that transition into the operations centers, and when they’ve suddenly “It’s not just about developers, I’ve also got to sort of provide tools and facilities that make life easier for production DBAs in larger organizations”, they’re shifting focus and the things that they’re concerned about. And it’s part of the growing up for a true open source of not open source, whatever. But the lifecycle of a modern database is to start with developers, and then to have to try and cross that chasm into large scale production, because these people can still knock back the database.

So very often, the developers built this beautiful thing, it’s on MongoDB. But if MongoDB falls over every day in production on a global scale, then it doesn’t matter, the developer can say what they like, a large organization is going to say: “No, rebuild it in something else, we’re gonna go to Amazon or something”. But the other part of that equation is that at the very same time that this is happening, we’re seeing databases in the cloud really start to take off. And at that point, you’ve got this, that you don’t even need to worry about it. Because we’re not going to go to MongoDB in your data center, we’re going to jump to MongoDB Atlas in, MongoDB is on cloud. And they’ll manage the backups and they’ll manage security and so forth. And this is smoothing the way I think. In my opinion, it’s given a really good business model for open source to aspire to. Developers on premise use the open source download free to pre go with it is the cloud maybe, but when it comes to monetizing, we prefer people to come and use our fully managed cloud. And that’s how we make our money with the fully managed cloud implementation of what can still be an open source product. We don’t need to charge enterprise licenses and all the messiness that happens there we are trying to persuade someone to pay you for essentially nothing. You’re running it on your own hardware, you’ve got your own DBAs, what are you paying for when you buy a MongoDB enterprise, just the ability to ring up every now and again.

Matt Yonkovit: I think that the cloud model has proven itself out. And it’s kind of turned databases into a bit of a commodity. The one thing that I’ve noticed, and I’m curious if you’ve seen this as well, is that as we’ve made things easier, especially for developers to get started, the barrier to entry has gone down. But also the skill level of those who are having to interact or solve some of these problems has also decreased. So, when there is a big scale problem, it tends to be a bit more difficult for them to figure out because they don’t have that database background. They don’t have, maybe, the basis to troubleshoot some of the things. And a lot of times from a fully managed perspective, cloud providers tend to be very focused on the operational aspects, like the backups, upgrades, making sure that you’re patched and things. But from a performance perspective, a lot of it’s still on the developer to take care of their own database and make sure that it’s designed correctly, and it’s implemented correctly.

Guy Harrison: Yeah, you’re right, even more so than then in the past, where you typically have the developer would hand over the application to a production team, now the developer in a DevOps model is still pretty much fully responsible for performance in production and needs to have a bigger or more sophisticated understanding of database performance at scale. This is kind of one of the reasons I wrote the MongoDB book, because working with a lot of MongoDB developers, it’s so easy to pick up and get going. The developers were not exactly clueless, but not quite as informed about the fundamentals of performance management for database, as, perhaps, they were when Oracle was the only database where you just knew that you had to. You had to know how to tune a SQL query, you had to know how to use EXPLAIN, you had to have a pretty good grasp of indexing and so forth.

That having been sad, I’ve been around an embarrassingly long time. And a lot of my career has been like picking up after developers who didn’t. I think that’s one thing that never changes.

Matt Yonkovit: Yeah. And I think that it is an interesting space, because from a cloud perspective, or even a database perspective, a lot of the challenges that I see with people who have with any of the cloud providers or any of the databases service, it’s because of a misunderstanding more than it is that the technology is bad. And it’s that kind of marketing message around: “Hey, this is fully managed”, because people think: “Oh, well, it’ll just perform, it’ll just scale, it’ll just handle everything, and I never need to worry about it”. And a lot of people just end up paying a lot more money because they upgrade to the next size, the next size, the next size… To try and get better performance, better scale. And so that’s why your book on MongoDB performance tuning is very interesting. And Mongo was designed to be easy. It was designed for developers, and it is a beautiful piece of software that really enables developers to move faster, and it speaks more closely to a developer’s natural development process, then a relational database does. And so that’s why helping them understand that “Hey, there are some things that you need to worry about” is important.

Now, in the book, or in your travels, as you’ve talked about MongoDB and talked about some of the performance issues, are there a couple that you might share that these are common things, one or two things that are like “These things always happen and you should watch out for them, they’re common mistakes”?

Guy Harrison: Sure, they’re pretty basic, really. Most developers understand that they need to use an index, but a lot stop when they’re just using any index. And if you’ve got more than one filter condition in a query, you can construct a variety of different indexes to support that. And the difference between just any old index and the best index is typically several orders of magnitude improvement. So that’s one.

I think, another thing is as a developer, you really need to know the tools that MongoDB provides for you to track performance. And so like all databases, there’s a profiler that captures slow queries, there’s a command that you can use to see how MongoDB is going to execute. And there’s execute the query and there’s system statistics that in Mongo, the base case, generates about 1000 different metrics. And like that’s hard to know of those 1000 metrics, which are the ones I need to pay attention to. If you want to be a professional developer in MongoDB, you should know those three tools, you shouldn’t just say “That for someone else” or “I don’t care of, it all worked well on my laptop”, you need to understand how to work with that.

Matt Yonkovit: If it wasn’t for users, all applications would be fast, I swear.

Guy Harrison: Yeah, well, sure, without data in a database status, database is usually fast. Like I’ve seen this a zillion times, it worked fine until you put some data in the title of the collection, and then it started to be slow.

And the final thing is, there’s a sort of a systematic way to tune databases, like there is a systematic way to tune the engine of a car. And that systematic way is to work from the workload first, what am I asking the database to do. Am I asking it to do too much? Can I make it slightly easier? Can I make a web smarter with indexes? And then after that you start looking at memory to avoid IO. And only when you’ve done all that, you start doing things like upgrading the disks or sharding. Those operational things should be done last when you’ve got the workload, right? Because if you do them first, and then do the workload, second, you might find that “I bought three new MongoDB servers to shard everything out, but then I found I added one index, and I didn’t need them”. So you always work down from the application into the hardware in that order?

Matt Yonkovit: Well, it’s funny, because nowadays, performance equals dollars more than ever before. Because I mean, back when we did Oracle, you might have to get more memory, you got bigger boxes, but ordering hardware or a bigger box was sometimes a six to 12 month procurement process, at the best of times. Now, when you’re talking about performance, it could be like “Hey, you click a button, and it upgrades to a larger instance in seconds.“ And that performance impact if you developed something and architected a little wrong, could be massive.

Guy Harrison: Absolutely, I’ve had the same experience, you used to have to tune because you had no choice, because hardware upgrades were so difficult. Now, you can just increase the amount of virtual hardware very quickly, but it’s going to cost real dollars. And another way, I think, I don’t think about this all the time, but just blindly consuming more electricity, it’s not really very responsible environmentally, is that right? If you’re a big organization, you’ve got money to burn, and you quadruple the amount of electricity your data centers are using, you’re not doing anyone a favor, you’re spending money. And you’re also spending resources that we should be conserving. So everything goes to make sure the applications are efficient. And the application code, not just the database code, the application can avoid asking the database for things that are already known and stuff like that. That’s been true forever, most of the fundamentals of database tuning are the same for all the different types of databases, and most of them been through now for a ridiculously long time. But the cloud does change the dynamics of how you have to pay for your mistakes, I suppose.

Matt Yonkovit: So I’m curious, because I hold a weird view when it comes to schemaless databases. And I use that term loosely, because I don’t believe… So Mongo, a lot of people say it’s schemaless, I don’t believe that it really is schemaless. But you still have to do schema validation. It’s just you have to do it in the application. And it pushes that validation around. And if you don’t design what that quote noquote schema looks like, you end up wasting space and could cost performance cycles as well. I’m curious, what do you think of that? Is it really responsible to throw whatever you want in? Should you really structure your data more?

Guy Harrison: No, it’s still got the same, just because there’s no CREATE TABLE statement doesn’t mean that you don’t have to work out what your collection or document structure is. In MongoDB, we have a chapter on this in the book, obviously, it’s the same in a way, it’s got a lot of the same considerations as relational modeling, but, and you’ll see it in all the MongoDB material on their website, there’s a lot of talk about “Do I link everything? Do I embed everything?” So for instance, the naive model for MongoDB is: “I just have an object and I just dump it into the database’s adjacent document and it’s got repeating groups, and it’s got arrays and arrays of embedded objects”. But MongoDB can only have 16 megabytes in that one object, so you can’t put it. For instance, you can’t put every tweet for a user, if you’re doing some sort of Twitter- like application, you’ve got to break it out somehow. But you might have enough room to put every line item for an order that might always fit in 16 megabytes. If you do things like repeating the name of a product in the embedded document, when you need to change the name of a product, or change its price code or anything like that, you’re going to have to update it in not one spot, but a zillion different spots, as many as many documents as there are orders. And all of those trade offs are just as real today, in MongoDB, as they were 10 years ago in MySQL, it’s just a matter of what sort of de-normalization that we want. We don’t sort of have quite so easy joins. So we want to avoid splitting stuff up. But we can embed everything in the same document. So there’s a whole sort of discipline for MongoDB. And it comes down to whether you link documents or embed them or do some sort of hybrid pattern. And these things are reasonably well understood now.

But again, you bet you’re right, in the MongoDB, this makes it too easy. “I’ll just… The first thing I think of bang, that’s my document, and I’ll change it later”. But changing it later is still an expensive operation and still potentially requires you to restructure all the data you’ve added to the application today.

Matt Yonkovit: Yeah. And what’s interesting is not only Mongo has some of these things that originally were designed to be very document oriented, to be very focused on the developer and thinking like a developer, so that kind of schemaless push more validation to the code. But over time, they’ve started to gradually introduce more relational features, or things that would be traditionally in an RDBMS, similar to other databases, because overall, I’ve seen this interesting trend. Companies mature, and they developed these purpose built databases, whether it’s a graph database, whether it’s relational, whether it’s a data warehouse, an analytic system, or a document database, they start to incorporate the ideas from other databases. And you mentioned this in the talk that you gave on the next generation databases, that Oracle has started to include everything in the kitchen sink, in their portfolio of databases. But I’m starting to see like Mongo, for instance, added transactions, of course, they want more SQL-like interface, and they’re starting to move more towards that same thing with analytics, column stores, introducing this, or relational databases introducing more NoSQL-like interfaces, JSON, whatnot.

Why all of a sudden we’ve gone to these different extremes, where “Oh, this database is really, really good at doing this one thing. Oh, now we’re going to add these 20 different things as a bolt on after the fact”. Any thoughts on why we’re seeing that kind of trend evolve?

Guy Harrison: Well, primarily, these companies are just chasing their customers. And their customers are saying you’re going into deals, and they’re losing deals, because they don’t have transactions or because someone wants an advanced feature that they can’t support in MongoDB base case, as we talked about it before, growing up past the developers, MongoDB is done really well in some companies that I would have thought I would have done so well in including banks, they’ve managed to persuade some banks to use them, even before they had transactions, but they clearly banks gonna say: “Look, I need transactional integrity, I can’t handle this idea that my update might, may or may not be consistent”, so that they chase their customers and their customers say “We want transactions”, they say “We want to analyze the data, we want to use tableau to look at the data in the database, so MongoDB adds a SQL Bolt on. Meanwhile, if your have Postgres or enterprise DB, or Oracle or SQL database, you’ve got developers who’s saying: “We like working with JSON, we don’t want to work with tables”, so you increase your JSON support within the database. And now you’ve got this case where MongoDB is a JSON database with some SQL support, and you’ve got these SQL databases that have JSON support, and they’re strengthening on both sides until they’re converging again. It’s kind of inevitable, I think that you don’t want to be a nice database forever. It’s not the best way to capture market share. I guess the exception is the graph databases that seem to be fairly content to stay in that niche because their model is so different that they feel they can’t compete head to head against general purpose databases, but they feel that they’ve got the edge in this one case but we see graph databases being graph capabilities being added to other databases who are saying: “Well, we think we can support that nation as well”. Now, whether it works out that way, in the long term, I guess we have to wait and see the graph capabilities in MongoDB and Oracle are pretty weak compared to Neo4j or TigerGraph. And so if you really have a graph workload at the moment, you really do want to specialize graph database, but who knows where we’ll be in 10 years.

Matt Yonkovit: So one of the interesting trends that I’ve seen, and I don’t know, if you’ve seen this: a lot of companies, especially the larger companies that have very big workloads, are starting to invest more in designing their own versions of Postgres, MySQL, other open source databases, they’ve started to codify that. And this isn’t a new trend, it’s just I see it accelerating a bit. Because Google and Facebook obviously have created many different databases. I mean the original Cassandra comes from there, you know, HBase heavily influenced from there. But now I’m starting to see, different people have different takes, and that’s starting to spawn up new projects, right. You mentioned some of the new SQL type things, whether it’s Cockroach or Yugabyte. And those were designed a little bit differently, but they take components of Postgres, for instance, and incorporated into their product. We had a talk from Uber, where Uber did their own document data store at Percona Live. We’ve heard from the folks over at planet scale about Vitess, which was built to handle YouTube scale, but it’s built around MySQL. So what’s your take on these databases that are starting to be evolved or bolted on to meet this new, scalable workload? Where do you see those going?

Guy Harrison: Well, you know, I’m not deeply familiar with those, perhaps you might have more experience with them. But in the very large organizations, you’ve got the strength of expertise, where you can say: “Postgres is almost OK for us, but we need this one more thing” or “We think we can get some competitive advantage by having a unique database, one that’s no one else has got that has some unique features”, and you’ve got PhDs and super developers, and you can give that a shot. And developers are always really keen to build their own databases, because there’s always something wrong with the one we’re using. So you’ve got to let the lead developers do it, they’ll do it. And a lot of times, these projects don’t come to my chart, you might remember project Voldemort from LinkedIn.

Matt Yonkovit: I remember Voldemort.

Guy Harrison: I think was the inventor of that and that get outside of LinkedIn. So these innovations out of these really massive companies sometimes just become like a flash in the pan inside that company, sometimes they become a significant part of that company’s competitive advantage. And sometimes they break out and become part of the open source ecosystem, and we all get to benefit from it. But for the vast majority of us, we should not be thinking about modifying an existing database, we should be thinking, we should have the choice, all the choice you talked about at the beginning of this session gives us a lot of things to choose between, and hopefully we can find something that’s good enough, and get on with the job of building an application. Because when you’re building a database, you’re solving your own problem, you know, you’re not solving your customers problems. So you should be choosing the best database, making good decision there, spending time tuning it, but if you’re building a database, then you’re probably not building user functionality, that’s really gonna make a difference.

Matt Yonkovit: Okay. And at ProvenDB, you’ve got your own unique database there, which is a blockchain database. Right?

Guy Harrison: Yes, yeah. So our aim is to be at the intersection of database technology and blockchain technology. So now I just can’t help going into pitch mode here. So just forgive me as I do it.

Matt Yonkovit: That’s okay.

Guy Harrison: But one of the things that I noticed when I was working with databases for most of my professional life is that we didn’t really have any way of guaranteeing the contents of the database. I knew as a DBA, that I could just manipulate the database and leave no trace. And beyond that you can get down to the database files and change bits and bytes in there or go straight to the disk. And so when the database says, this row or this document was inserted on this timestamp, there was really no particularly good reason to believe that, you’re just really trusting the developer of the DBA that they hadn’t been corrupted or that no hacker got in and changed that.

And then blockchain gave us the ability for the first time to have immutable records where we could be sure that no one had made that I didn’t and since I’d been added, but there was no way you can build a sensible application on top of the blockchain platform, they just didn’t have the storage capability, no schema, bad performance, bad economics.

So what we’ve done at ProvenDB is we’ve added to MongoDB as our base platform a sort of an anchoring system that takes the data in MongoDB and creates digital signatures and anchors them to the blockchain, transparently to you, you don’t have to do anything for this to happen. And then if you want to assert that to an auditor, or to some other regulator, or to a customer that this is the record, this is the proof of identity document, this is your will, this is the accounting transaction, these are the legal signatures. You can prove without any doubt whatsoever, that the dates of these documents are correct, and that they haven’t been tampered with. So that’s kind of the short elevator pitch.

Matt Yonkovit: So it’s really certifying that those documents are legit. That’s really what it is. It’s a signature that guarantees that, and that’s important, because right now, so many people have so many needs for compliance issues, and to make sure that their data can match what government regulators might want it to create.

Guy Harrison: And as a society, we are being bombarded with fake and fabricated news and information, we need to have a way that we can trust the information in there. Well, because we’ve gone when we use paper and other physical media, we could look at that paper, and we could forensically check it. And we could even carbon data. Yeah, there’s lots of things we could do to say, “Okay, this is, this is real, this is a real piece of information”. Now we can copy and manipulate digital information so easily, that we’re all at risk. But as you know, one of the things that’s coming up is you’ll be able to take this video and make me say whatever you want with a piece of software that you can just fix and things like. And that’s the only protection I guess we can have out of that is that as this video is uploaded, we create a cryptographic signature of it and anchor it to a blockchain so that at least I can say, “No, no, this is the original. I never said that about your mother, Matt. You know, it’s a lie”. And so that’s kind of our mission there. So, you know, that’s, yeah, I’ve always wanted to do something unique. Follow the lead database, and I’ve been a commentator and practitioner. And it’s been great to have a sort of adding something worthwhile to the database ecosystem.

Matt Yonkovit: Very cool. Very cool. Well, Guy, thank you for sitting down and chatting with me. As I mentioned, Guy has a couple books out, head on over to Amazon, you can check them out, the MongoDB performance tuning book, and shortly a book on CockroachDB, which will be very interesting to read. You can also check out Guy’s Percona Live sessions, which are up on YouTube as we speak.Thanks for hanging out with me for a little bit.

Guy Harrison:

It’s been an absolute pleasure, I should just quickly shout out but currently Percona Live was the best online conference I’ve attended since the pandemic made online conferences. Really big thing but are by far the best, most well organized, best content and the attendees were really engaged. It was just great.

Matt Yonkovit: Oh, we love to hear that. We’re glad that you had a good experience there. You know, obviously, it’s hard when it’s remote, but we’re glad we got this right.

Guy Harrison: Excellent. Good job. Okay. Thanks a lot, man. All right.

Matt Yonkovit: Thanks a bunch, Guy.

Wow, what a great episode. That was we really appreciate you coming and checking it out. We hope that you love open source as much as we do. If you like this video, go ahead and subscribe to us on the YouTube channel. Follow us on Facebook, Twitter, Instagram and LinkedIn. And of course, tune into next week’s episode. We really appreciate you coming and talking open source with us. ∎