Yury Selivanov: Whatever it takes to make it possible for someone to just instantly become this 20 X developer, 10 X developer, some multiplier developer, we should do it. We should give people this powerful tool. Eric Anderson: This is Contributor, a podcast telling the stories behind the best open source projects and the communities that make them. I'm Eric Anderson. Today we're talking about EdgeDB with Yuri Selivanov, who is one of the creators, a co-founder of EdgeDB. Yuri, thanks for coming on the show. Yury Selivanov: Thank you. Yeah, glad to be here. Eric Anderson: We've talked over the years and this is an exciting time to be talking about EdgeDB, because you had your major announcement at recording time. This is a week ago, but by the time this publishes it'll probably be six weeks ago. Congrats. Yury Selivanov: Yeah. We did have a pretty great day on Thursday, February 10th. We launched EdgeDB live on YouTube. You guys can look it up. It's on our EdgeDB YouTube channel. It was a little bit silly, the beginning of it. We actually were figuring out how to exactly launch EdgeDB, and how to make event remotely climatic 10 minutes before the event, so things that could go wrong went wrong. For example, we wanted to have an audio track playing along. We are typing, "Wake up Neo. The time is now. EdgeDB is waiting for you," and the sound was muted. Yury Selivanov: So I think a lot of people were watching us at exactly 10:00 AM Pacific time, and it was just silent, slow typing without any soundtrack. But overall, I think people loved it. And while the event was ongoing, we posted to Hacker News and I think 30 minutes in, we already hit the front page of Hacker News. And then we quickly rose to the top of Hacker News, the number one spot, and we've been there for 13 hours, maybe 14. I went to sleep without checking, but we were number one around 11:30 PM and amassed 930 or 40 points, 300 comments or more. What was worrisome, is that there was no negative comments in at all. Just words of encouragement and people being excited. I usually see some- Eric Anderson: Yeah. Hacker News isn't always a friendly place. Yury Selivanov: ... Exactly. And this time everybody was cheering, so we were super excited about this. Eric Anderson: That's great. Well, congratulations. I missed the flub at the beginning, but maybe that lends authenticity. The rest of it, what I did catch looked fantastic. So tell us about what EdgeDB is, so that the audience is oriented around what we're discussing. Yury Selivanov: Yeah. So EdgeDB is a new database and it's actually not just a new database. I believe that it defines a new category of databases. We call it graph-relational. We are coining this term, so don't go to Wikipedia just yet. It will be there hopefully soon, but there is no article about it right now. This is a new thing and it's essentially an extension of relational model. It's just a couple of things and we can go over them if you want. But the ultimate goal of EdgeDB, is to just streamline the developer experience around dealing with a database to make it convenient. If you have a great tool it almost disappears in your hand. Yury Selivanov: You can just perform your task without noticing any rough edges or anything, just natural extension of your hands essentially. With databases, it's not like that usually. There are lots and lots of things for you to figure out and be super careful around. How do you deploy them? How do you write queries? How do you fetch data? What middleware do you need to set up? All those questions, they are real and they actually slow you down. And with EdgeDB, we just want to basically remove all those negative aspects. Remove the drag essentially, and just give you a tool that can actually speed up your development process a lot by big factor. Eric Anderson: The name graph-relational, I think is new to EdgeDB. I feel like I followed the project some, and I think in times past you've communicated that aspect, but not so concisely. Am I right? Yury, you've had various ways of describing EdgeDB, and this seems the most succinct and in some ways compelling. I feel like you may have hit on something. Yury Selivanov: Yeah. I have two things that led us to inventing graph-relational concept to share. The first one, Dan Abramov, probably everybody knows him without an introduction. Dan Abramov and I had a conversation about React probably about a year ago. They were about to release a version of React, and he was wondering how we handle Python 2 to Python 3 migration, which was actually quite painful. And after that, I surely introduced him to EdgeDB. I asked him, "Hey. Let's have a follow up call. I'll just tell you more about EdgeDB and pick your brain. Maybe you will suggest me a few things." And if you said that when they launched React, first of all, not a lot of people under the stood what React is immediately. It didn't click with the community the first day, but then there was this almost random article about how React actually works. Yury Selivanov: And that random article mentioned that, "Hey. There is this virtual DOM concept that React builds on top of," and then suddenly the community was buzzing. "Oh my God. Virtual DOM. This is the thing. This is the future. If it's not going to be React, it's going to be virtual DOM for sure. So I have to learn React now." So naturally we started to look like, "What is our virtual DOME in EdgeDB? What is an interesting aspect? How can we distill the value of EdgeDB into something that is three words long or something like that?" And then just before releasing EdgeDB, Elvis, my co-founder and I had a phone call and, "Yeah. We need to write 1.0 announcement blog post." And that was actually quite stressful, because we are building this project for 10 years, and it's a huge thing. Yury Selivanov: A lot of people from time to time ask us, "Is this a WORM?" Well, yes. It does some of the things that WORMs do, but it does so much more. It has standard libraries on Krill language protocol, client APIs. The API surface is just huge, and we're solving so many different problems at once. So what the hell do we tell them on that 1.0 announcement blog post? How do we structure it? What do we do? So we had a conversation with Elis for a couple of hours. Just, "Okay. Let's start from the first principle. What do we actually do at our company? What are we actually building?" And then, "Can we call it a relational database because it's different from a classical relational database?" Yury Selivanov: And turns out that, yes. We can. We always knew that its relational database of course, but just talking it through and distilling the exact modifications that we've done to it, the foundation for this terminology. And the initial idea of calling this graph-relational was coined internally by dev advocate, Colin McDonnell. And we liked the name immediately, but we didn't quite connect it properly to EdgeDB ideas. And then before writing this 1.0 blog post, after having this conversation it was crystal clear, "We're building a graph-relational database. This is a new category. Let's define it. Let's open the door loudly and just say, "Yes. We are building graph-relational database, and here's what it can do for you."" Eric Anderson: We should get to the history, and we will in a moment. But I suppose part of the benefit of this three word phrase, as you mentioned, is that it's an abstraction layer. It hides all the complexity. There's all this nuance you want to explain about the product and the features I'm sure, and the React people did as well, but by leading with this phrase it encapsulates maybe. You can define it and it encapsulates all that terminology that you can get to eventually, as long as you understand this catchphrase. Yury Selivanov: Yeah, yeah. This name isn't absolutely flawless and perfect, because when people hear graph-relational, they might be slightly confused and say, "Hey. So this is a graph database." And we are not near [inaudible 00:08:30]. We actually have Street Schema and we have relational foundations. We are not a graph database, but conceptually when you are programming, graphs is all you work with. Sometimes don't realize it, but yes, if you work with objects, those objects are connected to each other. That's a graph. It's GraphQL after all. So the name actually makes sense, and I believe this only slight imperfection of it that some people might think that it's a graph database. I think it will not be a big deal in relatively short time when people learn more about EdgeDB. Eric Anderson: Good. Well, take us back. Tell us where this all started, Yury. 10 years you've been working on this. Is that right? Yury Selivanov: No. It's longer than that. It's embarrassingly longer than that. Eric Anderson: Well, let's bear all. [crosstalk 00:09:15]. Yury Selivanov: Yeah. My co-founder, Elvis and I, we met. I don't even know how many years ago. Maybe 13, maybe 14 years ago, at a small Canadian company that were building lead management system for big companies like Costco, Walmart, et cetera. And when we met it was V1 of system, and pretty much immediately we started working on a new system, V2, and we tweaked lots of things. We implemented lots of things. It was interesting. It was cool, and then we started working on V3. And for V3, we did something special in terms of programming. Most of the business logic was designed in a declarative way, and the application could be just compiled out of the description, and everything worked just amazingly well. We didn't have any bugs. We had to actually go and insert some bugs into production just to check if their reporting is working. Yury Selivanov: It was crazy. We were perplexed, "What's going on?" We were writing this system for a year and it's just working flawlessly? Like, "No way. Something is wrong." But it was. It was a smooth launch. And back then we just realized, "Hey. We have this great synergy. We've built this amazing tool. It's being used by big companies. So how about we just start a new company and try to build something?" And we had absolutely no idea what we're going to build. It was around 2008 and we started the company. We called it MagicStack. It was in Toronto, Canada. And the idea was, "Hey. Let's run this software development boutique shop, and if something great comes to our mind, we implement it and transition to a product company." But we'll start with just software development." Somehow we were lucky enough to have great clients. Yury Selivanov: We worked with Department of Defense, even though we were subcontractors, but we were working on some projects that were pretty interesting and pretty secret. We partnered with a Canadian company that was doing behavioral business simulations for big companies, like GE, Microsoft, et cetera. And we created an iPad game, which simulated virtual university and led people to discover how to run a university, how to expand it, et cetera. And it was powered by a super early version of EdgeDB. And as we were working on products like this and actually shipping them to pretty big companies, we realized that, "Hey. The internal stack that we're using at MagicStack," hence the name of the company, MagicStack, "it's pretty great. But the core feature of it is this data layer." And then one day we realized that, "Hey. We can actually build a database. We can actually capture the essence of this data layer, generalize it, make it language agnostic, not just like a Python framework and it'll be database. Eric Anderson: And your co-founder was on board. It sounds like you initially decided you wanted to work together, and you wanted to build something, and you were building various things. And eventually you realized, that what you both had passion in, or at least expertise in, was this core database framework. Yury Selivanov: Yeah, absolutely. He was the mastermind behind, specifically, all data layer things. Like, how do we actually compile it to SQL? How do we design our schema? It was three of us in the core of this project. Elvis, our first employee, Victor and I, and everybody was involved to a certain degree. Closer to 2018, I think, it was basically three of us working almost full-time on EdgeDB, but I think without Elvis, this just wouldn't happen because he had this early insight, that dealing with WORMs is actually quite painful and we should fix it. Eric Anderson: It's interesting that you acknowledge that the insight was about the problem as opposed was to the solution. Eventually the subsequent insights are various ways of solving it, but the first insight was like, "This is painful." Yury Selivanov: Both Elvis and I, first of all we are developers, but second we just hate writing code. We love writing good code, interesting code, but doing mundane things over and over again, it just kills the fun and we wanted to have a fun job. So the whole idea of this data layer was to basically not repeat ourselves. If you're describing your model once, you have a description of this model, like your types and relationships between your types. Yury Selivanov: When you need to create, let's say, a form or a grid to do data entry or to display the data, it would silly to just restate all this information just from a different angle. So we heavily relied on meta programming, et cetera. We had some projects that had tons different screens in admin panel and looked incredibly complex, but there was 100 lines of code in them. And the rest was just declaration files that just mapped your UI and UI widgets to the data model. Everything else was just generated automatically. Those systems were quite impressive, and they further reinforced the idea that we are onto something with EdgeDB, because EdgeDB just almost encourages this programming. Eric Anderson: Yeah. So you've been paying the bills for a decade by shipping some stuff to GE on occasion, but ultimately building this data layer. And at some point you decide, "This is the product or the core idea." What does that shift look like? Yury Selivanov: We were actually doing lots of other things. We were deeply into open source starting around 2013, actually. So we use Python programming language. This is our tool of choice and been tool of choice for long time. And around 2013 a core developer, Brett Cannon, announced that, "Hey. We have this PEP, Python enhancement proposal and it's been around for years. Let's pick it up and let's implement it. Let's fix it. Let's accept it." I saw that announcement. I knew about this PEP. I was using the API it was describing, and I knew that this API was suboptimal and that it wouldn't actually work. So I picked up that stale PEP and updated it with a better API. Well, basically I joined forces with Brett Cannon himself, and with Larry Hastings, he's also a Python core developer, and we just brought this PEP up to speed. Yury Selivanov: And a year later I became Python core developer. Around that time we started investing heavily in asynchronous programming internally at MagicStack. We had this asynchronous I/O framework. And [inaudible 00:15:31] also creator of Python language also started working on asynchronous programming support in Python. And somehow it all happened that we, the small Canadian consulting company, ended up with reducing async/await syntax to Python programming language. So we were going and living and breathing open source for years now. So it was mostly doing our open source Python work on the one hand, on the other hand supporting ourselves developing software for clients, and then dedicating whatever time left to EdgeDB development. Eric Anderson: You mentioned something I want to quickly ask about, and then we'll go back to the rest, but you became a Python core developer. What does that mean, and how does that happen? I imagine there's a lot of people interested in open source, that aren't really sure what the mechanics are to become a core developer. Yury Selivanov: Yeah, absolutely. Python is an interesting language actually, because it's not designed by a committee. There is no big corporation behind Python that controls how it's been developed. And there are some upsides and there are some downsides. It's just what Python is. I would say there are about 30, maybe 40 developers of Python language that are just active, that exchange emails on the Python mailing list. Usually it's Python-Dev and Python-Committers and Python Ideas, that write those Python enhancement proposals that monitor our back tracker, which is bugs.python.org. Try Edge box, fix them, review poll requests, et cetera. All those people usually have a commit bid, so they can just go and commit things to the Python interpreter. And because it's just 30, 40, and the active core is even smaller, everybody knows each other. So it's almost a club, but it's an open club. Yury Selivanov: And this is very important to understand, that everybody actually is excited whenever someone else new joins, because managing a project like Python which is just immense, it's immensely huge, it's complicated. It's number three, or maybe now number two programming language in the world. It's just a complicated thing, so whenever someone is active on GitHub or on our mailing list and starts contributing to the project, usually they are being noticed and you receive an email one day, "Hey. I noticed you've been active here and there. How about we promote you to be a core developer?" You answer, "Yes," and then there is a poll. We just ask, "Hey. Is everybody comfortable with promoting this girl or a guy to be a Python core developer?" If the poll is positive and usually it is, then you become Python core developer. There are some perks to that. Yury Selivanov: First of all, yes. You can now commit to Python itself, which is exhilarating. You're making changes that millions of people will see and experience. It's a great feeling, but then there are some other interesting things. Like there is this conference called PyCon US, and it's a big event. I would say it's about three to 5,000 people every year meeting in one place. And three days before that conference, there is an event called Python Language Summit. And that event is run behind the closed doors. This is basically one day a year, when all Python core developers meet and they discuss the plan. "What do we next?" Usually this event is later covered it in sites like LWM, for example. Sometimes those nodes and articles leak to Hacker News and other sites. So I think a lot of people know about core language assignments, but it's an interesting perk of being a Python core developer. Eric Anderson: Thank you. Yeah. The not so secret, secret summit. Very good. Yury Selivanov: Yeah. Exactly. Eric Anderson: So you've developed this data framework layer you mentioned, but separately you've also been working on Python. You introduced async/await, that seems like a whole big evolution in Python. Congratulations. And are those related, or are they a separate thread so to speak? Yury Selivanov: They are related actually in an interesting way. So basically, when we started contributing to Python heavily, we knew that EdgeDB will become a thing. And I think we actually coined the name EdgeDB, before us contributing async/await and investing into Python ecosystem. But we knew that it was going to happen, and we knew that the process is going to be painful, because no way we can get all the details about the design right from the first attempt. So we knew that, "Hey. We have this compiler of our Krill language to SQL and it's pretty complicated. Most likely we're going to be rewriting it several times." So we just had to stick to Python, because we wouldn't be able to write this much code and refactor it this quickly if we chose C, or even C++ or something like that. So we had to be using Python. And for that to happen, we also knew that there are certain requirements to EdgeDB. Yury Selivanov: It must handle lots and lots of concurrent connections, and the cost of establishing a connection to the database should be super low. How do we do that? Well, apparently asynchronous programming is the answer and that's why we started investing into it. And then we were thinking about our client APIs, how a client API would look like in Python for EdgeDB. And we knew that we have to support the synchronous clients as well. And back then, in Python the answer wasn't obvious, how do you have a transaction block? For example. You would have to basically copy and paste six lines of code, like try-finally, create_transaction, et cetera. So I just knew that, "Hey. This is not going to fly. This is way too verbose." And this is basically how our async/await proposal was born. Because we thought, "Hey. Python has this beautiful feature, a context manager. Just say, with context, then colon, and then you have your block. But there was no asynchronous equivalent of that. Yury Selivanov: So we had to have asynchronous context manager. "Okay. How about async/with?" And then, "Oh, if we have async, we can have async/await." This is how it all clicked. Then we actually were thinking about performance. Okay, we have async, we're going to say, "Oh, but Python is still pretty slow. How can we speed it up?" This is how uvloop was born. And uvloop was an interesting project. I know that a few years ago when you were browsing Instagram, a lot of traffic was going through uvloop actually. Facebook picked up uvloop super early and started using it internally, and then in some of the products. Yury Selivanov: I don't know if they still use it. Maybe they are, but the project since then accumulated 8,000, maybe 9,000 stars. It's a drop in replacement for the built in asynchronous core. With the basically two lines, you import uvloop and then say, uvloop.install() and your code just becomes three to four times faster. It works like magic. And it was created specifically for EdgeDB, because we knew, "Hey. We must be fast, but how do we do it with Python? Well, we need to accelerate it somehow." So a lot of our open source efforts we're pretty much dictated by EdgeDB. Eric Anderson: There're other approaches to accelerating Python, like Cython or other bindings to other languages. Do you employ those tactics? Yury Selivanov: We use them all. Eric Anderson: Oh yes. Anything that can be done, we do. Yury Selivanov: Whatever can be used. We have pieces of Rust code in EdgeDB, and with time we're going to probably rewrite more and more of the core logic in Rust. Now that the data model is settled, now that we understand how do we compile our Krill language, we know the algorithms, we can actually start investing in the rewriting the code base in a lower level language. But yeah, we use Cython. We compile Python basically to C in many different places and basically all bottle necks. And if you just look at benchmarks of EdgeDB, the overhead over Vanilla Postgres is actually super low. So EdgeDB is actually quite fast. Python is an implementation detail. People shouldn't notice, or probably won't even know it's in Python. And I think we're doing pretty good job of keeping it just an implementation detail. Eric Anderson: So at some point, you decided EdgeDB was going to be a thing and were working towards it. At some point, you decided that it would be an open source launch, maybe that was already clear. And also as a company, you went and raised some money and pursued this in earnest. Tell us how those steps unfolded. Yury Selivanov: We always knew that EdgeDB is going to be an open source product. Obviously after so many years of contributing to Python, we just knew that, "Hey. It has to be an open source, and it has to be under a permissive license." Apache 2 in our case. Around 18, we realized that, "Hey. We have to present EdgeDB to the broader community somehow," and PyCon US was happening in about couple of months. So we just applied to become PyCon US sponsors. We booked a booth and we knew that, "Hey. Our first technology preview has to be released right there. And we have to just show it to people and see what they tell us." So we printed 3000 booklets for PyCon, booked the booth printed a bunch of swag, and we were actually finishing this technical preview, I think, almost a night before the conference opening. So that was our, essentially, first contact with the community. When we showed EdgeDB for the first time. Yury Selivanov: And the feedback was just super positive. I think we chatted with 100s of people there and everybody was excited. The conference was in Cleveland. When we came back to the Toronto, we just knew, "Okay. So now we just have to commit 100% to make EdgeDB real." So over one year were just refining everything. We were refining the query language, the data model, we changed a bunch of things focusing on DX and in, I think, April or May 2019, we released EdgeDB alpha 1. I think we hit Hacker News with it. And I already met with a few friends and a few fellow Canadian start up founders, so I got some introductions to VCs here in the Bay Area. And mid Summer, 2019, I started flying to San Francisco every couple of weeks or so, having meetings with people and just trying to raise with what we had, an alpha 1. Yury Selivanov: Back then, I was pretty sure that we're going to launch 1.0 half a year later or year later or something like that. Unfortunately it didn't go so fast. We are building a database. It is a pretty serious thing, so it took us longer than that. But in August 2019, we finally raised our seed round led by Accel, and specifically Dan Levine. We incorporated in 2019, I think it was September 25th. Early 2020 just before the pandemics, we moved to San Francisco with a goal to build our network, meet with people, participate in meetups and everything else. And then it was a total lockdown three weeks later. Eric Anderson: Oh, that's terrible. Yury Selivanov: Yeah. It wasn't the best thing, but we were not alone in this mess. Eric Anderson: Did you stay? Yury Selivanov: Yeah, we did. We did. Climate is so much better in the Bay Area, compared to Toronto. Especially during Winter time, so it was pretty enjoyable. I'm glad that we stayed. Eric Anderson: Good. And after a couple years of work, we're now to the real launch. Yury Selivanov: Yeah. We launched 1.0, finally, over basically two years of just grinding through different issues, small incompatibilities and just streamlining the DX a lot. We've built a lot of things over the past couple of years. EdgeDB can now be installed with essentially one command. We have great workflows, great tooling. We have fixed lots and lots of little quirks in the Krill language in EdgeQL in the standard library. We worked heavily on our client API, so it was definitely a time well spent. But during this time we were almost encouraging people not to use EdgeDB, because we knew that, "Hey. It's a relational database. If something goes wrong, people's businesses can be at stake." So we were always cautious with our messaging. Like, "Hey. This is an alpha quality product. Play with it, report back, but don't build anything real with it just yet." Yury Selivanov: And amazingly, I think we actually have had a pretty great core community. It's hard to put an exact number on it. I would say about 200 people or so. People who installed all those alpha releases submitted bugs, and just communicated to us whatever pain points they had. So we were constantly refining the product, going through all those multiple period releases and multiple different release stages up until late 2021, when we released RC 4. And it was clear, "Okay, this is time." And I spent about one month of just preparing for the 1.0 Launch. Updating the website, planning the live launch event, et cetera. Not really changing EdgeDB itself that much. Eric Anderson: Well, that's great. I don't know that we've fully articulated the benefits of EdgeDB, so maybe we should spend a moment there. From the launch I did see some interesting things on video. Like making requests the database come back with types on the response object, it's fully tied which seemed exciting. How do you describe to folks all the value that's there, which I'm sure is hard to say quickly? Yury Selivanov: Exactly. It's a list of bullet points, essentially. It's a lot. So first of all, with EdgeDB you have a strictly typed schema, and we've invested a lot of time to make this schema first development possible. So first of all, you describe your schema with a high level domain specific language called SDL, Schema Declaration Language. It's very powerful. You can describe, we call them object types. Object types can link to other object types and have some properties attached to them. Object types can be treated as mix-ins essentially. So you can mix object types with each other that enables composition with EdgeDB. A composition that is not traditionally possible with any WORM or with any relational database. So now you have this schema, and the schema is just pretty much one-to-one mapable to your programming language of choice that feels native to JavaScript, this object model, and feels native to Python or any other high level programming language. Yury Selivanov: So already, you are not internally translating this mindset from objects to tables in relational data. The data model just matches what you're working with on a daily basis. And then we have a Krill language, EdgeQL. And a lot of effort went into making EdgeQL what it is today. If you just look at EdgeQL, it looks like child of SQL and GraphQL, as someone actually put on Hacker News. And it's true to an extent, it's a declarative Krill language. It allows you to fetch hierarchies of objects, just like GraphQL. But what makes it different from GraphQL is that you can write analytical queries. And basically, the goal was always to build a database that can actually replace SQL. And in order for that to happen, you cannot just have this one big feature, "Hey. I can request hierarchies of objects, or I can do that fast." Yury Selivanov: To actually replace SQL properly, meaningfully, and have a shot at becoming the next big Krill language, we have to essentially make sure any type of query that SQL can do, EdgeQL will be able to do as well. Including analytical queries, including fetching operations, everything. If something is expressible in SQL and is harder to do or isn't expressible in EdgeQL, that was a bug to us. And then we were basically fixing, and sometimes redesigning an aspect of the language. So EdgeQL now looks obvious. I cannot believe that we spent so many years designing it, because it's so, so, so simple conceptual now. But it's core property is that it's composable. So you can just pretty much refactor it just like pure Python or JavaScript code. You can move things around, you can nest things and everything just works. And the language has room to grow, like we'll introduce window functions eventually. We will introduce GROUP BY command in EdgeDB 2.0, which should come out around May 2022. Yury Selivanov: So we'll continue adding those analytical capabilities, but the foundation of EdgeQL, is already more powerful than SQL in many regards. First of all, yes, it's composable. Second, you can express multiple different operations in one query, which is possible in SQL, but is extremely cumbersome. With EdgeQL, you can just select multiple unrelated pieces of data, and receive them back in one compact object arrangement essentially, without any need to duplicate your roles or anything like that. You can insert things, update things, sometimes unrelated things, in one query. Yury Selivanov: It's totally pipelineable essentially. You can combine multiple unrelated queries into one query, and that query will be compiled under the hood to just one SQL query. And this is an interesting thing, because if it's a single query you don't need any explicit transaction. This query will be run atomically. So this ultimate composability of EdgeQL doesn't actually make easier for you to write. That's true, but it also makes it quicker to execute for you. Just basically one round trip between your client and server, you can express so much now. And if you look at how WORMs traditionally do this, they usually fire lots and lots and lots of implicit keyed on SQL queries, just inflating your communication cost with your database. Eric Anderson: I'm starting to appreciate just how much work had to go into this, because you're right. An alternative to what you did, is you could have built the client experience you wanted and then built your own database, but you wouldn't have had all the benefits, the hardening, that's come from Postgres. Yury Selivanov: Exactly. And boy, do we use Postgres to its full capabilities. We found, I think, seven or eight bugs in Postgres over the years. We were actually pushing it to its limits. So in order to do this right, we had to get the fundamentals. And that includes proper data model and the proper Krill language. And now we start to build more primitives on top of it. So for schema management, you can express your types in your application elegantly in EdgeDB schema, but then you need to evolve your application, add new features to it. So you add new types and you change your existing types, this is called schema migrations. So schema migrations are part of EdgeDB. They're just part of the core workflow. Database knows everything about migrations, about your schema and it can do it like no other tool essentially, which means that you just learn the workflow of working with this schema once, and then it doesn't matter what language you're using. Either it's Go or Elixir or Python or JavaScript, it's always the same workflow. Eric Anderson: Yeah. It's impressive you call this an alpha or a 1.0. Schema migration sounds like something that I can imagine somebody saying, "Oh, we'll get to that later. You can use it for now, and maybe that'll be in 2 or 3.0." So impressive that you had such a high bar on what folks would want. I think it's probably going to lead into really great first impressions. Yury Selivanov: Hopefully. And I think this is what actually happened in our launch day, and in Hacker News comments as well people mentioned it, because it looks like a real thing that you can just start immediately building with. Because again, migrations is such a big pain point for users, so if we can get them right it already elevates the entire offering to a new height essentially. But this is tip of the iceberg. We have a schema, we have a Krill language, we have migrations, but then we had to think about the client APIs. How do we make them great? How do we make them composable? How do we integrate with TypeScript? How do we streamline the experience of installing EdgeDB on your machine locally, or just joining a project that already uses EdgeDB. Yury Selivanov: With our common line tool and this is just one command line command, you just type, EdgeDB project, in it after you git clone something from GitHub, and it does automatically everything for you. It bootstraps the proper version of EdgeDB, runs it, and you can just type, EdgeDB, and connect to the database. It already has all the types in it, and everything is there ready for you to just start working. So we basically were looking at the entire experience of working with EdgeDB. And this is what is so hard to explain when we are talking about EdgeDB. Yury Selivanov: It's not just the new data model, graph-relational. It's not just the schema or migrations or the Krill language or libraries. It's all of this. We are trying to reimagine the entire experience of working with the relational database, not just in terms of ergonomics, but also in terms of performance and latencies and quality of service and composability, all of it. And this is why it took us so many years to just make sure that we ourselves understand what we are building, what we are capable of building, and how can we balance this 1.0 thing so that it's immediately usable and useful, and also serves this proper foundation for us to just keep evolving things into the future? Eric Anderson: You mentioned that you're a hybrid between GraphQL and SQL, and it's not even a fair comparison with GraphQL, because to your point earlier, somebody decided, "Here's what the developer experience could look like. Here's a spec, go implement it yourself." And you went miles further where you said, "Let's implement all the permutations of ways you could interact with this thing and support them." But looking at just the spec, I get the impression that you're taking another step further. Folks realize the value of some elements the developer experience encapsulated in GraphQL. And you're saying, "Okay, and more. Here's other things you would want to do when you request data from a database." Yury Selivanov: Yeah, yeah. Exactly. And by the way, GraphQL helped us a lot in the beginning. Most of the core principles of EdgeQL, like fetching of hierarchies of objects, we already had them when GraphQL was announced essentially. But explaining why this is cool was tough. At some parties we were talking to people and they were asking, "Hey. What you working on?" And we were like, "We have this magical data layer. It can do this, this and that." And they were looking at us with empty eyes, not really following and getting the idea. And when GraphQL was announced a few months later, everybody knew that, "Hey. This is a great thing." Potentially it can be used to create databases, not just for stitching APIs together. Suddenly everybody realized, "Hey. This ability of just fetch an object tree is super useful." And then it became much easier for us to explain EdgeDB to our peers. Eric Anderson: Ah, yes. No, that would be a lot easier. And I suppose it also builds on their other open source projects that have taken similar approaches. I don't know if you feel akin to things like Hasura or Dgraph that also are GraphQL first, some of them relying on Postgres as well. But again, it almost feels like you've continued to iterate and take things further in both cases. Yury Selivanov: Exactly. Yeah. We just continued pushing. And by the way, I love Hasura. I think it's an amazing product. But with EdgeDB, we just wanted to basically see how we can streamline creating of new projects essentially. What if you had no idea that other databases existed? What if you had no idea that Postgres is a thing or MS SQL is a thing? How do we take it from there? What would a database look like if it was designed in 2010 or 2020? And this is an interesting thing, because on the one hand it allowed us to explore so much in order of functionality and where we can push things forward. On the other thing, I believe it might be a little bit challenging for us, because with EdgeDB you have to start things new. So it's for Greenfield projects, not Brownfield projects. So yeah, it's an interesting dilemma. Eric Anderson: Maybe shifting gears a little bit, and we should be wrapping up soon. This is one of our longer interviews, Yury. I'm just fascinated, so I could keep going, but I should respect your calendar time. Cloud has messed up what we think of as a database to a degree, and in some cases databases look more like backend platforms and people start bundling features into so-called databases, authentication, authorization, patterns, storage and functions. Do you feel like EdgeDB needs to do some of those things, or is there a purity to being just structured data storage? Yury Selivanov: I think it has to. It absolutely has to. When we pitch EdgeDB from time to people we say, "Look at those big companies like Facebook, Uber. They all have these data layers and those data layers are amazing usually. They can do caching for you, they can do querying multiple different aspects and they make people's jobs easier. And this is why Facebook and other companies are able to ship amazing products, because they have this data layer custom tailored for their business, and does so much more than just MySQL Library." So we describe EdgeDB as basically being that. Being a data platform, for you to speed up your development and give you a tool that only big, huge, unicorn companies were able to afford before. So we have to go further than just give you an opportunity to create data. Yury Selivanov: People struggle with OAuth. It's one of those computer science program. Naming cache and validation and OAuth, it's always broken. Signup forms are painful to implement. We have to offer that, and we already the go there, because EdgeDB provides GraphQL out-of-the-box. So we already go beyond what a typical database gives you out-of-the-box. We ready to give you GraphQL. In some time we'll start adding more integration toward our future cloud offering. Just streamlining and just removing the pain points one by one, and I'm fairly optimistic about that. I'm fairly optimistic about many things, like WASN for example. It can be an interesting fit for EdgeDB. Whatever it takes to make it possible for someone to just instantly become this 20 X developer, 10 X developer, some multiplier developer, we should do it. We should give people this powerful tool. Eric Anderson: Well, it has to be really exciting, Yury, to be working on something for so long, to have had this vision and to be marching along this path for so long, and then to have all these people show up and say, "Yeah. That's exactly what I want. Where has this been my whole life?" Which is going back to our very first discussion on this call, the response from Hacker News. Everyone just seemed, like you said, unanimously positive. Never seen that before. Yury Selivanov: Right. Right. Right. Yeah. This was great. Let's just hope that we'll be able to continue building on this gradually, and continue finding this way of presenting EdgeDB and actually explaining what it can do for people. Because again, the product is just big. It's huge, and it changes so many things we do about software development. So I hope that people will be encouraged to spend some time, check it out, get familiar with it and start being excited about EdgeDB. Eric Anderson: Good. Anything we didn't cover today you wanted to discuss? And if not, maybe you can tell people how they can get involved. Or the state of the product, what they can look forward to. Yury Selivanov: I'll say a couple of things. First of all, check out EdgeDB. You don't have to build a production system with it, but you can at least check it out and start using it. Maybe you can introduce it in your company, automate some microservice with it. It's a database, you can build so many amazing things with it. We will launch a cloud version, a hosted version of EdgeDB hopefully in May 2022. Maybe it's going to be just free tier, maybe it's something more than that, but this is our goal at least. Yury Selivanov: We're working hard, all hands on deck, and just making this hosted version of EdgeDB a reality. And second thing, because we've spent so much time talking about Python and the open source ecosystem, I would like to just encourage everybody to just go and contribute to Python. It's an open source project. It's not really big by any big company or corporation. It runs by volunteers essentially. So if you ever are annoyed with Python, that something is poorly documented, or something isn't working properly, file it back, send me the pull request. That's going to be amazing, and if you do a bunch of those you'll be promoted to a Python core developer, and it's an amazing thing to be. Eric Anderson: You're heard here, folks. Yuri, has given you the path to stardom within Python. Thanks so much Yuri for coming on the show today, and thank you for of the gift of EdgeDB that you've given us over the last decade, and the world is finally getting to appreciate all the wonder. Yury Selivanov: Oh, thank you for kind words. Eric Anderson: You can find today's show notes and past at episodes at contributor.fyi. Until next time, I'm Eric Anderson, and this has been Contributor.