Follow BigDATAwire:

November 9, 2022

EdgeDB Seeks to Bring Relational Databases Out of the 1970s

(iKandy/Shutterstock)

Disco. Bell-bottom pants. Platform shoes. Relational database management systems. Some of us have soft spots for the 1970s. But if you’re EdgeDB CEO Yury Selivanov, you would prefer to put relational databases behind us–or at least modernize the way we use them.

“The interesting aspect about relational databases specifically is that they were invented in the ‘70s by IBM and later companies like Oracle and Microsoft continued to push improvements to them,” Selivanov tells Datanami. “But they haven’t seen a significant change in terms of developer productivity or developer experience since pretty much the ‘70s.”

Selivanov doesn’t have anything personal against the relational database management system. In fact, he appreciates what RDBMSs have done for us, in particular the mathematical completeness of SQL and the proven power of relational theory. It’s just the way RDBMSs are exposed to developers–such as writing straight SQL or working through object-relational mappers (ORMs)–that he has a beef with. Developers hate RDBMS and SQL because the developer experience hasn’t improved since the 1970s, he says.

“The sad truth about relational databases is that they’re extremely powerful,” Selivanov continues. “Postgres and MySQL and Oracle–they’re basically marvels of modern computer science and engineering. The problem is that we are only…scratching the surface of what they can do. Basically, they just use 10% of the functionality.”

The developer experience for relational databases hasn’t improved in 50 years, says EdgeDB CEO Yuri Selivanov

The ORMs are central to the impedance mismatch posed by RDBMS to developers, Selivanov says. When developers write their Python, JavaScript, or C# code, they’re not thinking in terms of database tables, even though that’s how the data is ultimately accessed and stored. Instead, developers think in terms of data objects. And most of them are not writing SQL to directly manipulate data in tables. They’re working one step removed from the tables through the ORM layer, which keeps them from 90% of the functionality available in the RDBMS.

That led to the insight at the core of EdgeDB: “What if your relational database could have a higher-level data schema, essentially, so tables would have object-like data in it?” Selivanov asks.

This was the insight that Selivanov and his business partner, Elvis Pranskevichus, arrived at back in 2016. The pair were building enterprise software products for data companies, and they leveraged RDBMSs as general-purpose tools to power complex applications in finance, education, and social media.

To speed up their work, they developed an internal framework that allowed them to more effectively leverage RDBMSs. That was the genesis of EdgeDB. “We realized, hey we don’t actually want to be a consulting company,” Selivanov says. “We want to become a product company, and productize the amazing data layer that we have. How about we generalize it and make it available to people?”

The partners raised some seed money in 2019, then went into stealth mode to develop a new database, dubbed EdgeDB. They came out of stealth earlier this year with the launch of EdgeDB 1.0. Earlier this week, the company announced the completion of a Series A round worth $15 million led by Nava Ventures and Accel, with participation by Vercel, Firebase, GitHub, IBM, OpenAI, ICONIQ Capital, and Netlify.

EdgeDB can be thought of as a high-level optimizing compiler that allows developers to access data as objects (Image source EdgeDB)

EdgeDB is a graph-relational database, which is a term Selivanov and his partner invented. Instead of thinking about accessing data sitting in tables with a certain schema, EdgeDB developers think about accessing objects with properties connected by links.

“It’s like a relational database with an object-oriented data model, or a graph database with strict schema,” the company says on its website.

The database was implemented atop a Postgres core, which Selivanov says is an implementation detail that may change in the future. What matters, he says, is that the EdgeDB data model and the strictly typed EdgeQL query language enable developers to get more work done in a more intuitive manner, without working with ORMs.

“Ultimately you can think of EdgeDB…as a high-level optimizing compiler,” Selivanov explains. “We compiled a high-level data model down to a lower-level model. We compile our high-level clear language down to low-level SQL.”

EdgeQL enables developers to get more work done with a single query, Selivanov says. The language is composable, and allows developers to pipeline multiple different operations into one query, he says. Early benchmarks show the language and the database have the capacity to run from 5x to 100x faster than a traditional RDBMS.

Selivanov says the company has plans to publish a white paper that demonstrates the power of EdgeDB and EdgeQL, which he says is “an extension to relational algebra relational theory.”

“Fundamentally, there is still the same mathematics. We just expose it from slightly different way,” he explains. “We spent years making sure that our data model and the query language are sound, are proper, that they have solid mathematical foundations.”

Now that the Series A money is in the bank, the big push is to build a cloud version of EdgeDB. The EdgeDB cloud offering, which is slated to become available on AWS in mid-2023, will plug right into existing cloud Postgres instances, such as Amazon Aurora.

The company hopes to pull a page out of the MongoDB playbook in terms of making its cloud databases drop-dead simple for developer to use, with one important distinction: EdgeDB is a relational database at the end of the day. Despite the pain of using RDBMSs and SQL, Selivanov is convinced that developers would be happy to use them, if they were just a little bit more approachable.

“Basically, if you actually tap into the full capabilities of what fundamentally SQL allows you to do, if you actually exploit and expose this fundamental functionality in a nicer way that developers can actually use, they suddenly can find themselves way more productive with the database and use it way more efficiently,” he says.

As for disco, platform shoes, and bell-bottom pants–well, maybe some things are best left in the 70s.

Related Items:

Choosing a Database for Your Enterprise? Here Is What You Need to Consider

The Shifting Landscape of Database Systems

Who’s Winning the Cloud Database War

 

BigDATAwire