The rise of EdgeDB: PostgreSQL needs a new query protocol?
Having received a request about the necessity of more straightforward access to the DBMS-managed data, I began to analyse the project EdgeDB [1], which has already received more than 13k stars on GitHub. It looks like we have a hidden request. Passing through advertising noise was never an easy job, but on their website, you can find a couple of conceptual blog posts [2, 3] that we can analyse to answer a question: What’s the real issue here?
What I see there is a continuing statement that ORMs divide logic into small queries, causing many roundtrips. But in my mind, it doesn’t matter if it is formulated as a single query or as many smaller ones—it is still ORM. The SQL-generation core must be covered under that ORM’s hood, right?
The next claim is that SQL is too complex and contains many keywords. Real applications, being written with object-oriented languages need something more laconic. ORMs, providing such a more native interface, have no uniformity. So, reading between the lines, I see the request to implement a kind of DB library for each language where an implementation would not generate SQL queries but request objects from the database instance, which means a new query protocol that will parse language-native requests into a query tree.
One more thing: they argue about a declarative approach to schema definition in object-oriented terms with declarative migration.
People tell me: why not implement something like bytecode [4] in PostgreSQL? In that case, we could send a binary representation of the query directly from the client to the instance core without intermediate checks.
Summarising the data I have learned from this project, I see real issues are:
Performance degradation because of the multi-query approach.
Non-uniformity of ORM languages.
ORMs have limited functionality in comparison to full-fledged SQL queries.
In toto, I see that developers want to remove the client-side layer, which translates OO → SQL and add the OO → parse tree functionality as an extension or directly into the core. This is all about performance concerns.
It makes sense. The main point here is to learn DBMS to receive object-oriented language statements and translate them directly to a single parse tree. Do we have enough flexibility to allow an extension to fully replace the current core parser with a custom-made one, and would it be safe?
References
EdgeDB: A next-generation graph-relational database.
https://github.com/edgedbA solution to the SQL vs. ORM dilemma
https://www.edgedb.com/blog/a-solution-to-the-sql-vs-orm-dilemmaWhy ORMs are slow (and getting slower)
https://www.edgedb.com/blog/why-orms-are-slow-and-getting-slowerWhy SQLite Uses Bytecode
https://sqlite.org/draft/whybytecode.html