Deep Dive Into EdgeDB – Percona Podcast #58 w Yury Selivanov, the CEO of EdgeDB

Link to listen and subscribe: PodBean

EdgeDB has recently reached version 1.0. Listen out to Yury Selivanov, The CEO of EdgeDB, as he joined the Head of Open Source Strategy at Percona, The HOSS Matt Yonkovit. Yury is talking about his background from contributor to a python core developer, and transition to EdgeDB. What makes EdgeDB different? EdgeDB is focused first and foremost on the developer experience. Combining the best of PostgreSQL with a new intuitive interface designed for developers to easily adopt it make EdgeDB a project worth watching. Join us as we dive into the implementation of EdgeDB, open source, relational database, ORM’s, and the Graph Relational Model.

YouTube

Link: https://youtu.be/ZDGEz6oY-nw

Yury Selivanov

CEO of EdgeDB

Yury Selivanov is Co-founder and CEO at EdgeDB. Bringing state-of-the-art database technology to the masses. EdgeDB is an open-source object-relational database built on top of PostgreSQL. The goal of EdgeDB is to empower its users to build safe and efficient software with less effort.

See all talks by Yury Selivanov »

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:
Hey everybody, welcome to another HOSS Talks FOSS. I’m the HOSS, Head of Open Source Strategy here at Percona, Matt Yonkovit. And today I am joined by Yury, the CEO of EdgeDB. Yury, how are you doing today?

Yury Selivanov:
Good. How about you?

Matt Yonkovit:
Not too bad! Not too bad now, Yury. I wanted to chat with you. Because EdgeDB has recently come onto the scene. I think it was a couple of weeks or a couple of months ago, when you reached version one. Is that correct?

Yury Selivanov:
Yeah, yeah. It was long under development for several years. We finally launched it came out of this, this weird stealth mode that we’ve been in for, for what felt like decades, but it was actually a couple of years. And yeah, finally we released 1.0. Oh, if Hacker News was number one, there were 14 hours, maybe 15. We have amassed almost 10,000 tuples. The reception was very positive and warm. And usually, I would say for each one. So yeah, it was a great lunch.

Matt Yonkovit:
Awesome, awesome to hear. Well, I wanted to start maybe with a little bit about the background here. I know that you have been a longtime contributor to the Python community. And so you started your work really early on developing a lot of the core features and modules that went into Python. And at some point during that journey, something must have happened to make you interested in re-designing a database and, and kind of like rethinking the approach. Maybe walk us through maybe those early days. And what gave you this inspiration like, like, how did it hit?

Yury Selivanov:
Yeah, yeah, well, the answer is luck. Sure. Almost luck, I think we’re sort of lucky to stumble upon this idea and how we actually execute it. But the story is actually quite a bit longer than just luck. So, my co-founder and I started a software development consultancy in Toronto, in 2008. And we work with a bunch of different companies. We helped small companies to build software, and big companies to build software, and we ended up helping General Electric, Cisco, EDB, Microsoft, Pinterest, and multiple different companies. And we were using our own stack. Most of those products that they built are using our own stack, written in a python programming language. And one of the most notable things about this stack was the data layer. And lots and lots of ideas that were kind of battle-tested. While developing all the software is now in EdgeDB. This was the foundation for EdgeDB. And yeah, because all it was all in Python was a pretty advanced framework and foundation, we really tried to push the low limits of Python programming language. Almost inevitably, I guess I became a Python core developer around 2013. It actually, all started with scratching my little itch. So back then, when we actually started magic stack, that was the name of our Canadian company and the consultant company still exists, by the way. We decided to use Python as a language of choice. And back then Python has just started the transition, the famous transition from two to three, that took a decade for Python to actually clear. And when we started, I think, python 3.0, was released, and it was an alpha version of it, alpha six, or alpha seven. So we started to use Python, Python three super early, basically, nobody else was using it at all. And at some point in time, because again, this is a new major release of Python language with the intent let’s fix bugs. Let’s fix annoying so the version two, even if it’s slightly backward, incompatible like if you see a thing that has to be fixed, let’s fix it. I noticed this weird behavior that like when you’re checking if an attribute is present on an object or not, in just consumed or errors, doesn’t actually matter what kinds of errors just sounds normal. And I was super hard to debug in our data layer, because our data layer and overloaded like all those attribute checks, and you could just magically like check if something is present there make requests to the database that was like a super early iteration of the data layer. We don’t do this anymore in EdgeDB. It’s a bad idea, but we did. Back then, we did. And I just propose, hey, let’s fix it. That was my first contribution to the Python programming language. The actual patch was like two lines long. But still, I think it counts. And later on, I was just I just continued to read the mailing list, I proposed more and more features. At some point in time, I became a Python core developer. And Yeah, just kinda, it was an interesting relationship, basically, because we were evolving Oracle database, and whatever stuff was missing for us in Python, we were trying to push it in Python. And this is how we ended up eating async-await to python programming language. This is how I ended up helping with maintaining the asynchronous IO layer in Python, and many, many other things we did

Matt Yonkovit:
And it’s a very classic start to the open source space, I think a lot of people get afraid of open source and start contributing. But they don’t realize that many people who end up becoming very influential or core developers start with a two-line patch, they start with the things that are impacting their own usage of the soft center. And it’s a very easy transition if you’re willing to start to look and start to learn and start to contribute back. I think that’s one of the awesome things about the open-source space is one of the few places where you can go, and see something that just doesn’t quite work, right, or it doesn’t quite seem right. And you have the ability to change it and to help influence that community. So that’s why I’ve always been a huge fan of the open-source space and have been in it for all these years. Yeah.

Yury Selivanov:
People actually, yeah, people actually approached me all the time and asked this question how do we become Python core developer, and I’m always answering, hey, just start contributing, it’s super easy. When I’ll have GitHub, it’s not like the contribution processes are obscure or anything, if you see some type in the documentation, or some improvement, just contribute, just start. And then after making 20, or 30 contributions, people will know you. And this is how you will become a Python core developer, you don’t have to be a genius to become one. You don’t have to know C, C++, or assembly. All you need is basically just enthusiasm. That’s it. So yeah, I really encourage all people to not just contribute to Python, but really do anything. There are so many open-to contributions, open source products, and projects. It’s a great thing.

Matt Yonkovit:
Oh, yeah, definitely. And so during this time, you’ve just kind of achieved your core developer status you’ve you’ve been working with some of these new modules like async. IO, and some of these contributions. And you’ve had your own data layer. So how did that transition to EdgeDB? So, how did you go from contributing core Python to a new database? Or the EdgeDB?

Yury Selivanov:
Yeah, yeah. Well, I guess, Alice, my cofounder, and I are a little bit tired of running this consultancy agency, it’s, it’s not an easy business, actually. Sometimes you make something great and goes nowhere. Sometimes you make something great. And it actually flies, you never know, it’s always roller coaster, you have to basically sometimes survive from check to check. And we decided, Hey, we should actually become a product company, it will be so much more interesting and engaging for us. And open way more possibilities. And we looked critically at what we had. And I mean, we’re developers, both of us software engineers, so this is what we do best. So we looked at our infrastructure, and hey, this data layer looks actually super promising. What if we actually make it a database, like it doesn’t have to be a library, it would be way more powerful. If we just took all the good ideas mix that already work makes sense, some other good ideas that we know will work and just make the proper database, make it language agnostic. So that won’t matter. If you’re coding and C or Ruby or JavaScript or whatever. And you just use this high-level data store. This is how it should be kinda wasn’t the vision, I think around 2016, maybe 2015. But we haven’t actually started working on EdgeDB per se. At the time, we were thinking that, yeah, this must happen. This will happen. But we have to prepare for it. Because the vast majority of code was written in Python. And we knew that Python wasn’t going to cut it in its current state back then. This is how I got involved with asynchronous IO. Because we needed concurrency, we needed a high throughput. This is how we and why we actually worked on adding async IO to Python because we knew that EdgeDB is going to have this asynchronous core. That’s how it is discovered Cython which is a dialect of Python that compiles to C, we created UV loop, which is like this IO acceleration library that is now I think, almost a de facto standard in Python asynchronous world. So yeah, we kind of gradually evolved our code base and our cells, this idea that EdgeDB will happen. And around 2018, we slowly started working on it, I will say that we started to spend roughly like, 50% of our time, just making sure that the lights are up and businesses running and 50% of our time working on EdgeDB.

Matt Yonkovit:
Okay, and so the data access layer that you built EdgeDB on, is it really designed more for an interface or in an experience that developers are more used to than classic SQL interface, or the standard kind of API’s that are in relational databases nowadays?

Yury Selivanov:
Well, nowadays, EdgeDB is basically a relational database, it runs on top of Postgres, but this is an implementation detail. But everything else is kind of different with EdgeDB. So first of all, we’re saying that relational model is great. And relational databases are just ridiculously good. Especially Postgres. It’s absolutely an incredible database. And, essentially, it’s a platform that you can build foundation. Now, multiple companies that do this, by the way, for example, Yugabite and timescale, they all kind of take Postgres and build either on the side or underneath it. This is a common pattern. So but EdgeDB, we were just replacing the entire front end, replace how the schema is defined, replace all layer, replace the query language, we define how you do migrations and multiple other things, including the binary protocol, the client API is basically the entire front end of the database is changed with EdgeDB. And to actually be somewhat successful at this change, and to actually make it possible to actually compete with traditional relational database and the SQL, it had to have the proper foundation. And I think we have it now we call it graph relational. Essentially, it’s an extension relational model. And we use this foundation to define everything our data model to define our query language. So to answer your question, basically, EdgeDB is a new database that wants to be a complete replacement for traditional relational databases. It’s built on Postgres, it’s fundamentally relational, and it’s best for the same use cases that Postgres is best at. It just has far greater dx, it will make you way more productive.

Matt Yonkovit:
Yeah, and I think this is an exciting approach. And this is what really piqued my interest around the edge. So you mentioned Postgres is the platform, and I have seen a lot of companies use Postgres at its core. But it’s interesting because there are two different types of problems that people are trying to solve. So you look at like at Yugabite, or a CockroachDB, for instance. And, they are trying to leave the client interface in the API’s there. So you can use what is already built for Postgres, and then they replace the back end to make it cloud-native or whatever. So they have replaced the back end, which is, which is cool. But what I hear from developers is, that they want a faster, easier experience. They’re pushed to move faster. So a lot of them don’t like SQL, I’m a database guy. So I have grown up in the database space forever. So but I always say this at conferences that I go to, it’s like, people think databases are uncool. When you talk to developers, they’re like, oh, yeah, we need a database. But we don’t like writing SQL. And we hate defining this and that, and it’s just not natural to us. It follows the flow. And you’ll see that certain databases like MongoDB become popular because it bucked the trend of a lot of the relational client libraries, which is interesting because EdgeDB’s approach is opposed to taking a client library and building the back end, you’ve taken the back end and said the back end is pretty, pretty good. But what really could be better and could reach more developers. It’s the front end. It’s the interaction. It’s how developers think about code. It’s how developers think about the data that’s in their applications. And that’s a very different approach. But I think it has a lot of potential just because of where developers are nowadays in how they’re evolving and the pressures that are being put on them. They want to think about data like they think about code.

Yury Selivanov:
Yeah, yeah, absolutely. I mean, this is a vast topic, and I will share a couple of thoughts. I might end up working in circles if I do just interrupt me before I started, though, yes, we are based on Postgres. And yes, we’re building on top of Postgres. Traditionally, companies usually build an aside like timescale or, and the change the some ways layers, let’s say, like IO layer, for example, are doing different job right now. But nothing actually precludes us from tinkering with Postgres at a deeper level, potentially into the future, we as a company have a very ambitious goal. Essentially, it’s basically to redefine relational databases. If we just wanted to write everything from scratch, let’s say just not use Postgres, just write our own storage engine, that will be possible, it will just take us two more decades to do that. It’s, excruciatingly painful to create a proper working solid, robust database engine, so we chose Postgres, so we could focus our efforts on a new front end. And on better scalability, for example, we could try to do something similar to what AWS is doing with Aurora, or we could do something similar to Yugabyte or PlanetScale. But then our focus would be just kind of diluted, we would not be working on front that as much and we will probably not be able to work on the backend as much. So instead, we decided that, hey, using Postgres is ultimately an implementation detail, it’s a great one, we should focus on one thing, do it right. And when it’s time for us, and when our future customers grow to some certain scale, when they would need a better engine, basically, better internal engine than just vanilla, Postgres, basically, then we’ll take a look at what we should do. And by the way, Postgres is not also standing still. Oh, yeah, it’s rapidly, yes, we’re going rapidly, they are adding hooks and things. And now there are new database companies that try to use the functionality to change table engines to change how they store it, and multiple different advancements are happening. So basically, with EdgeDB, we’re going to continue focusing on the X and implementing some of the currently missing pieces of of the puzzle. And then when it’s time, sometime in the future, we’ll start working on the backend infrastructure and try to address the scalability issue. But ultimately, the vision of EdgeDB I’m glad that you actually talked a little bit about SQL developers don’t quite like it. That’s actually true. Developers hate databases. And I think this, you said that right. I think it’s the reason why MongoDB became so popular because suddenly it was like a breath of fresh air. We don’t need migrations. This is like the most painful thing about relational databases. We don’t need SQL, just use simple API’s. And a lot of developers decided, yeah, let’s try it. 10 years later, they discovered maybe that’s not the best approach. Now we see this renaissance of relational databases. If you open Hacker News or Reddit, you will see that, like, almost every day somebody is blogging about Postgres and how cool it is. So, yeah, unfortunately, unfortunately, databases, relational databases are still pretty much where they were in 2010. And where they were in 2000s, and 90s. And 80s. SQL was still SQL tables are still tables. And without actually addressing some of these fundamentals, I don’t think that it’s possible to meaningfully improve the DX of relational database, so we have to actually start digging deep. Now there are multiple different companies that create ORMs or create some middleware or create, I don’t know UIs for the database, but they all kind of try to just solve one piece of this big puzzle. And with EdgeDB we are trying to do something way more ambitious, which is basically Hey, how would the relational database look, if it was designed today? Today, when we not in the 70s, when we had mainframes and when the software architecture was not even correct to say vastly different that was just alien to what we have now. And what would it look like? What would we do differently? And EdgeDB is an answer to that. And if you want I can go into the detail like What exactly have we changed?

Matt Yonkovit:
Yeah, no, I mean, I think you’re on. I think SQL evolution. It is slow right now, and it has been for the last 20 years. It’s stable. That’s great and There are people who have those skill sets. But the current generation of developers are thinking and moving differently, and they have so many different options that they are exploring and starting to invest in. I think that it only makes sense that databases eventually have to catch up. And there are like you said, ORM is out there, there are different techniques and things that people use to try and mash this. But part of the challenge with those are, is they are outside the database itself. Right. And so exactly, they’re, they’re bolt-ons. And probably with the ORMS is a worm interprets what you want and tries to interpret what the database wants, in the likelihood of getting that 100%. Right, all the time is pretty low. And it generally has scalability issues, other things, because it’s not designed to necessarily work 100% the same way. And I think that really limited.

Yury Selivanov:
Don’t even let me get started with ORM

Matt Yonkovit:
I used to do a lot of database consulting. Right. So that was, so I know, the pain.

Yury Selivanov:
Yeah, it was, it was almost a revelation. Like when we were preparing for the launch of 1.0. We’ve had this live launch event on YouTube. And we wanted to make it interesting. So we had like almost a mini-conference, by the way. It’s, it’s, it’s all on YouTube. Anyone who is listening now and curious about this, you guys can search on YouTube. And you will find that just type EdgeDB. Anyways, I mean, I always and I, my co-founder and I had a conversation a few days before the event, and we’re just talking about ORMs and so-called Object-Relational impedance mismatch, which is actually the root cause of forums. It’s basically that tables are not how programming languages represent the event necessarily, and how developers work with it. And we just said this out loud, hey, object, impede Object-Relational impedance mismatch sounds like I don’t know, string theory or some deep physical property of this universe. But it’s not. It’s very far from it. It’s self-inflicted pain. And the only reason why we have it is that our relational data model is slightly different from our programming languages. And because of this deep incompatibility, we struggle. And this incompatibility actually manifests itself in the design of SQL as a programming language, which is a query language, which is actually great. And it’s a shame that it’s only more complicated than it should be. And so people don’t actually use its full potential. And yeah, basically, this is the root of the problem. But it’s important to realize that this problem is self-made. And that with the choice of the right data model inside the database, you just don’t need this, you don’t need this extra layer of abstraction, you just can talk the database native tongue without, without the need of this weird, awkward, slow translator. And I think it’s, it’s weird that ORMS have been with us for decades. And they shape the perception of, of how you should work with the database. Basically, there are like two camps. Now I use pure SQL or I try to use ORMS. And when you use ORMS, you also have to use SQL. Unfortunately, that’s inevitable. But it’s been so entrenched in our minds that sometimes it’s hard for me to pitch EdgeDB to people, like I’m saying that, hey, we defined the data layer so that the data model, so it’s compatible, it’s high level, it has object types. And they basically say, hey, so it’s basically an ORM in a database? Well, sure, I’m not going to fight your opinion. Yeah, you can, you can say that. But somehow, it’s incredibly hard for people to just even wrap their heads around this concept that hey, the database can just natively have a higher level data structure within it. And you don’t have to call it the more because of something else.

Matt Yonkovit:
Yeah, well, I mean, I think ORMS themselves, when you add the asset is a four-letter word. And I think that’s, it’s negative because it is that translation layer. But I think that what you’re doing is something that many other databases have done and are trying to do, which is create a new way to access natively, which is more of an API-driven approach. And that’s a little different, right. And so you see people’s approach to this MySQL, for instance, they have their x protocol, which gives you an API that you can access, and you can now access JSON through most relational databases, but you still are bound by a lot of the SQL issues and shenanigans and I know that as you get more divergent code bases and more, more options in terms of databases, even the SQL standard start to slip a little between the databases, so they don’t always work. And so there’s a lot of, there’s a lot of complexity out there. And you mentioned your graph relational focus. Now, I’m curious when I hear graphs, and this is a specific question that there are two different things. There are graph databases. And then there’s Graph QL, which is more of the API for databases. Yes. Where which one are you talking about? Specifically? But I’m curious.

Yury Selivanov:
None of those.

Matt Yonkovit:
None of those. Okay. There you go. Yeah. So explain it.

Yury Selivanov:
Yeah, yeah, there’s, there’s a story here. Basically, the edge word in EdgeDB. It doesn’t mean edge computing, necessarily yet. What it meant when we coined the name was just an edge in the graph. But we are not a graph database. So when we’re talking about graph, we’re talking about the graph of your relations within your relational schema. We think of graphs when we work with objects in JavaScript, basically, yes, like, I don’t know, you have object A and object B. You don’t necessarily have to use any graph, data structure, anything, just having two objects in memory link in each other. Well, conceptually, it’s a graph. So this is, this is the why we call graph relational because it’s an extension to relational model. That basically, slightly elevates, elevates it to a more high-level model. And but I think it’s time for me to decipher what graph relational means. What this extension relational model is because it’s actually very simple. So it actually consists of just a few minor adjustments of the classical relational model. So adjustment number one, every piece of data must have an ID globally unique data-independent ID, because in a classical relational database, you can have a table without any ID whatsoever. Or you can combine a couple of columns and say this is my ID, or you can just have an hour or the increment integer. And that would be your ID, or no idea at all. In EdgeDB. Every object type or table has a required property called ID, which is UU ID. The second extension is that we are introducing the concept of links. So essentially, we say that a piece of data can explicitly link other pieces of data. So essentially, you don’t need to have joints, you don’t need to have foreign keys, this slightly higher-level abstraction of a link, you can also call reference, if you want, just replaces this need. So now your one type can directly reference the other type. And the third extension, which is a little bit more kind of esoteric, it’s that we treat everything as a set. So our query language SQL is a set-based query language. And our data is stored in sets. And links can be single, or they can be multiple, if it’s a multiple link, it refers to a set of objects. And this actually, like you don’t think about this, this much when you write at scale, or when you work with the database, but it manifests itself in pretty interesting ways. For example, there is no concept of now in SQL in our query language. And now is a painful thing in SQL, it can do so many interesting things to you, like, for example, it can collapse your data and just nullify it all. And then you have an empty report, or you will be missing a column, your report will be null from time to time, maybe, I don’t know, you calculated the mean, while you in your report. And suddenly you had one line in your report, and you just had one value, I think was this will happily return you now in this case. So it’s really, it’s a really weird thing, because in SQL, it can mean an error and absence of data, multiple different things, and SQL will have the sole. If there is an error, you have an exception, it’s better to crash the query then give you incorrect results. And if you have missing data, it’s an empty set. And the entire language is carefully engineered, architected and balanced around this notion. So almost like there are no surprises basically. Anyways, this is the entire graph relational thing. That’s the kind of mathematical foundation of EdgeDB. And just by looking at it, you can in Imagine and MySQL did use what EdgeDB is doing. You think of a EdgeDB as basically, I don’t know, LLVM. It’s like an optimizing compiler, we compile high-level data schema, the low-level table, the oh, if you actually look under the hood, you just connect to the underlying Postgres instance that we manage, you will see a fairly normal table layout. Pretty classical one, like no, no, no surprises, no surprises there. We don’t do anything crazy there. We just map our high-level data model to a low-level table structure. We compile our query language HQL to SQL. We do some interesting tricks. And we use interesting and unique traits of SQL implementation of Postgres, specifically, but ultimately, it’s SQL. You can read it. So yeah, it’s, it’s a basic compiler for the high-level thing, the low-level thing. And it all builds on that this is kind of the kernel, the kernel of EdgeDB, the graph relational model, and this idea that we can compile high level things to low level things. And this way, we can unlock more power. Yeah, and it’s not new. It’s not new in our industry right now. People write bytecode by hand, use compilers for this. Why? Why would you be writing SQL?

Matt Yonkovit:
Yeah, it’s almost like a babel fish, right? I mean, I’m hesitant to use that because that was supported by AWS or it’s a trend, it’s, it’s the thing that’s going to speak, developer speaks and turn it into something that hardcore database nerd would understand and do it for you efficiently.

Yury Selivanov:
Yeah, but sometimes, it’s not even possible for hardcore database nerds to do what we do. Because there’s a limit to all this time limit how the database, how much time the database nerd can spend writing just one query, I can give you an example. So when we try to explain SQL, I think actually Graph QL helped us a lot, because Graph QL show people that, hey, expressing this idea that you can just fetch a hierarchy of objects in one query and getting this data easily is awesome. And this is this made it much easier for us to basically HQL also, this problem, hey, give me a list of users. And for every user, give me a list of your friends. And for every friend give me their email, and first name and address. It sounds like an easy thing. And it is an easy thing conceptually. But actually implementing them in SQL is surprisingly hard. Yeah, actually implemented more is surprisingly hard. In SQL, you can actually do some tricks, especially I mean, if you use Postgres, you use things like array ARG. But it’s going to be somewhat painful for you to compose the screen, if you rely on ORM, your ORM can actually make 1000s of grades for the simple thing, you might never know what it’s actually doing. But it might be doing some horrible things underneath for this simple conceptual task that every developer has to one way or another deal with nowadays. And this is why developers hate databases, by the way, because even simple things like this, that sound conceptually easy, are hard to do. So that would actually be an SQL, it’s this query is trivial. It’s like SQL one-on-one, you will be able to write this query like literally one minute after being introduced to SQL, it’s a trivial thing. It will be compiled to a SQL query, one SQL query, which will be executed atomically. It will be executed very fast in Postgres, because Postgres query planner is crazy, good. And, yeah, but the SQL query that you will get for fetching hierarchy of let’s say, three levels deep, it will look complicated, it would look something like you wouldn’t want to write by hand. And this is the whole point. It’s literally five lines of HQL, that will be compiled to, I don’t know, 30 lines of SQL, that is not so obvious, yet super fast to execute, like, two milliseconds, there’s huge repositories, and boom, you have. So yeah, this is where you have, you start to kind of see this leverage, that this idea, this idea can manifest itself as a very powerful idea that you can do so much more, if you had this, if you had this kind of step of compiling high-level things to low-level things within the database, not outside of it.

Matt Yonkovit:
so because Postgres is the back end, can EdgeDB sit on top of other implementations of Postgres? Or is it only what you download directly from a EdgeDB? Like, so, for instance, if you’re running on AWS and you want to run AWS as RDS Postgres, can you put EdgeDB on top of it?

Yury Selivanov:
Yeah, we support those right now. We used to have an extension to Postgres, which will prevent you from deploying to AWS, we used to actually patch Postgres, but some of those patches were upstream, and we contribute to them back to the community. So basically, now EdgeDB runs on vanilla Postgres, you don’t need to have anything special in it at all, but have guides on how you will deploy EdgeDB to DigitalOcean, AWS, or Google Cloud, or Azure, it’s honestly up to you, we have a Docker container that deploys along with an existing Postgres for just ship it with a Postgres inside, it’s entirely up to you. But the future for EdgeDB is going to be slightly different. We don’t actually want people to deploy to AWS this much, because it’s painful. I mean, there are some people who will always want it, and we’re not going to make their life harder if they want to do it. But the majority of people just struggle, because there’s so much, there’s so many things that you have to configure properly. How do you configure your TLS certificates, how do you map one port to another how do you configure EdgeDB to actually see the Postgres? How do you do backups, like all of this is quite complicated. So the dream that we have at EdgeDB is to basically just automate this all and give you a nice EdgeDB cloud option, where I could literally take you just one command or one button, click to just get your database running in production. And we are incredibly close to we’re gonna launch the first technical preview of our cloud and just about a month, okay, four weeks.

Matt Yonkovit:
Is that cloud then using like, you can deploy in AWS, Google DigitalOcean. And you get to choose kind of the base cloud platform, and then you manage everything. Okay, cool.

Yury Selivanov:
The very, very first, yeah, the very first is gonna be just AWS, at least during this technical demo, period. But the goal, but the goal is, yeah, multicolored, you will just choose the region, you will choose the cloud provider, and we will just run the database for you and automate absolutely everything.

Matt Yonkovit:
Okay, is yeah, one of the big things, and this is something that I’ve seen as a trend in the database space. And I was actually talking about this, at the Postgres Silicon Valley conference a couple of weeks ago, was the developer side of Postgres it’s the demands there are increasing. And this is going to really drive a lot of Postgres innovation over the next 20 years, or 10 years, or five years, or next year of all of those being inclusive. And I think that one of the interesting things is, that cloud providers in cloud instances typically are designed to solve the operational issues, but they leave all the development food, the work between building an application, designing it, making sure that the schema is okay, and everything to you. And it sounds like edge kind of fits that gap, where you provide some of those tools to make more efficient decisions from a database perspective. Better, a bit better design, enforce some of those rules that you should have in the first place to ensure your data consistency and scalability, as well as provide those operational things.

Yury Selivanov:
Yeah, absolutely. This is the whole point that you’re kind of reinventing the entire front end of the database, because we’re just, we’re not just reinvented the data model, let’s say or design their own query language, it goes deeper. So at EdgeDB, for example, schema migrations, as a first-class feature of the database, the database, no database is actually the best place where the migrations should happen. And the database knows how to do them correctly, perfectly. It knows what migrations are potentially dangerous or not, it makes sense to do them in the database; it’s, it’s still an open question for me why I think EdgeDB is the first database, that relational database that just has this first-class notion of schema, first of all, a schema that is editable, and that is kind viewable by you. And that is controllable by the database and tracked by the database and the first class, migrations workflow, so you don’t have to use them more or anything else. But then again, it goes deeper than this, because we also implement our own binary protocol, and also implement our client API’s. And I’ll just give you an example with client API’s. So why, why do we actually want to implement our client API’s? Now because we are I think, entering different age now it’s a serverless age it’s a distributed age when, when you run multiple one, you can run multiple different database nodes, potentially multiple different regions, some of them can be read on this some of them can be writable. Things can happen like metal partition errors can happen. database client API’s, all of them are just not there, let’s say, another partitioning error happens, while your application will display 500. There and guarding against that, it’s just the way like, you will have to choose people based on boilerplate code to just handle this specific case. Or let’s say you want to intelligently route, your read-only queries to read-only replicas, there is no infrastructure for this whatsoever that has to be hardcoded. So it actually is EdgeDB, we actually know absolutely everything about every query, we know if it’s read-only or not. We know if it touches any volatile functions or not. We know absolutely everything about everything. And that allows us to make some decisions. For example, our client libraries will soon be able to outgrow this automatically, we don’t decrease our client libraries right now, can repeat the query, if it’s safe to repeat if a better care happens, like if it’s a read-only query, and a connection was just like the socket disconnect. There is no IO, we know that, hey, I can actually reconnect and transparently repeat this query and get the data because it’s safe, because this data is read-only. Whereas if I was mutating something, and then that recur, happen, I have no idea maybe that that query actually committed. So now I can show you 500 there. But most of the time, we read data, right? So by just automating this tiny aspect of your client API, you can just survive, networkers will already improve the quality of service. And or, let’s say you started the transaction, and then you get a serialization error. This is going to be more and more common theme. And yeah, most, most libraries just give up, you have to ask for sterilization or, but the whole point of the series so that you can just go and retry this transaction. So in our API’s, you don’t have to do anything special, we will just retry it for you automatically. We basically engineered the API’s to, to, to just be capable of that. Some of our API’s look slightly weird in Python, for example, because in fact, in Python, then there is no concept of multi-line lambda function or closure. So in Python API, you will basically say, for tx in conduct dx, with tx, so you can do like this two blocks. But that allows us to repeat this transaction if it fails. So a lot of thought, went into designing those client libraries to make sure that all the best practices are incorporated in them so that developers don’t have to think about them at all. And this kind of attention to detail, I think makes EdgeDB a unique company right now, because so many companies try to figure out deployment and scalability and global availability, those are all good companies. And this is a big problem. But ultimately, I kind of I feel great about it, I think the humanity is safe. We have already plenty of options for globally available databases. But the this API, the UI, the GX part of what it means to interface with a relational database is so missing, so neglected. And a lot of the pain that should be that should be solved by the database entirely. is basically continuing to rest on developers shoulders, and what do they do, they either just don’t like it and suffer through, or they just don’t care. And they ignore those problems. Or maybe they’re not even aware of them. Because you don’t have another partition errs. On your laptop, when you’re developing applications, you will have them in production for sure. You might not even know that you have them. So yeah, that’s what makes EdgeDB to be quite unique. Okay.

Matt Yonkovit:
Well, you’re I like to end these discussions with some rapid-fire questions. Sorry, these are random questions that have nothing to do with technology. In some cases, sometimes they do. Sometimes it’s just kind of a mix. So I like to do this. I started this recently, and it’s worked out pretty well, just to get to know the person who we’re talking to a little bit more and get people interested when they meet you to maybe say, Hey, that’s pretty cool.

Yury Selivanov:
So the fun before anything goes wrong. We’ll edit it out for sure.

Matt Yonkovit:
No, no. So you’re so let’s say we meet up at a conference and someone wants to buy you a drink and talk to you about EdgeDB. What is your drink of choice? They bite you could be coffee. Soda.

Yury Selivanov:
Conferences, usually go for beer. Okay, but maybe if I choose a glass of red wine.

Matt Yonkovit:
Oh, okay. Connaisseur of wine or beer if it’s just hanging out. All right. All right, fair enough. What is the last book you read?

Yury Selivanov:
It was Andy Weir novel. What’s What was the name? There was about this. I cannot actually retell the story, I guess without spoiling it too much. But basically, this Okay, the first chapter started that the sun got dimmer and dimmer and dimmer and the humanity was faced with this dilemma that the world is about to end.

Matt Yonkovit:
Yeah, so that was not I mean, obviously. Yeah. Let’s see what Hey, not Hail Mary, or Artemis?

Yury Selivanov:
Yeah. Okay. I love the book.

Matt Yonkovit:
It’s a great, okay. Okay. Super easy read well, okay, so are you then a fan of science fiction books?

Yury Selivanov:
Yeah, yeah, I’m a big fan. Yeah, unfortunately, I don’t have as much time as I used to have four signs for. And this is why, by the way, I love him very much. Because sometimes in the evening is just like, I need to unplug my brain. And I just cannot read anything. And somehow Hail Mary was just perfect, absolutely perfect. So easy, and so engaging.

Matt Yonkovit:
So normally, I ask people, their favorite programming language, but I’m just guessing it’s Python for you.

Yury Selivanov:
Probably Python. But I actually also rediscovered JavaScript. For myself, I was always like, an advanced JavaScript developer, did a lot of interesting things with it. But when I was writing a client library for EdgeDB, a couple of years ago, three years ago, I chose TypeScript. And I love the experience of TypeScript a lot. It’s actually it actually was quite a fun thing for me to do. And I never would imagine that it’s possible to fix some of the language words with just this optional typing. And it makes total sense. And it’s amazing. And yeah, TypeScript, I think, is a great example of engineering done right.

Matt Yonkovit:
Now, okay, cool. And so let’s, let’s look at this technology landscape. I know where you are currently, company wise, what you’re working on. But are there some technologies out there that you’re looking at going? Wow, that’s really cool. or interesting.

Yury Selivanov:
WebAssembly! Is one of them for sure. Okay, I think it will unlock a lot of interesting use cases in the future.

Matt Yonkovit:
Okay. And if there is one thing in the technology space that really worries you, or that you’re trying to figure out how we solve as a community, what would that be?

Yury Selivanov:
The thing that worries me slightly, but then again, maybe I’m just being ignorant, and maybe I haven’t done my research yet. Is web three thing for now? I don’t get from the technical standpoint, from my limited knowledge of of the groups or decentralization, and yeah, I’m not against decentralization, I’m just not sure that web three in the way how it’s currently pitched, is going to be a thing. Maybe it will change and evolve into something different, but in its current form. I’m just not sure from the technical standpoint, if it’s feasible or not. So it’s one of those things that I’m sometimes paying attention to and reading articles, but I still haven’t made up my mind.

Matt Yonkovit:
I wanted to thank you for coming on today chatting with us telling us a little bit about edge dB, where you’re going how you got here. I do appreciate your time today.

Yury Selivanov:
Yeah, thank you so much. And to all listeners, please check out EdgeDB. Go to edgedb.com. And we have great documentation and amazing tutorials. It’s going to be an interesting right for you. I guarantee you that. Absolutely. So check it out. Yeah,

Matt Yonkovit:
Yeah. And we’ll go ahead and drop the links in the description as well. So if you are interested in either trying it out or maybe even contributing some code, providing bugs, and some feedback, I’m sure Yury and the team there would be most grateful for that. But we’ll be delighted. Yeah. And so for those listening, go ahead and like, subscribe to the channel here. We would love to hear your feedback. If you’d like Yury back on, tell us if you want someone else in this space, you want to hear about a different project. Let me know I’m happy to have people who know me, I like to talk. So we do appreciate all of you hanging out. And we will see you next time.

Yury Selivanov:
Bye-bye. ∎