The originalThe author is Yury Selivanov (@1st1) and Elvis Pranskevichus (@elprans), released on February 10, 2022.

Check out the discussion of this post on Hacker News, and watch a replay of the live broadcast on YouTube. You can also participate in the Discussion in Chinese on V2EX. The video of the conference has also been posted on STATION B (Raw meat), and the bilingual subtitles in Chinese and English are under production.

After years of development (and multiple pre-releases), we are proud to announce the release of EdgeDB 1.0, the world’s first Graph-Relational database! 🎊

So let’s just answer a few questions.

What are the main features of EdgeDB?

• Modern simple style query language, in the expression of power beyond SQL;
• Rich type system;
• Declarative schemas that quickly define inheritance, computed properties, functions, and complex constraints (and soon support for permission rules);
• Built-in Migration system, which can compare and infer schema changes, has automatic and interactive manual modes;
• Built based on PostgreSQL.

What is a Graph-Relational database?

EdgeDB uses the graph-Relational Model, an extension of the relational data model that addresses the “impedance mismatch” between objects and relationships while retaining the solid foundation and superior performance of the classical relational model, making EdgeDB an ideal database for application development.

Why build a new stove?

We should not waste our limited productivity on a set of database apis from the last century. Database back-end implementations have come a long way in the last 20 years, but they are relegated to a DSL from the mainframe era. We want to change that and bring the database API and developer experience into the new era of modern application development.

How does EdgeDB do it?

EdgeDB redesigned the entire database front end: from the communication protocol to the query language, from the schema definition to the client tools and libraries. The backend is still PostgreSQL, but hosted by EdgeDB and transparent to users.

We are better than SQL

Many people have poked fun at the shortcomings of SQL, including ourselves and others. Let’s just say that for the industry to move forward, we can and must do better than SQL. This is a huge undertaking and we are not blind to its difficulty. In some ways, it’s probably safer to build a new SQL database from scratch than to build a new data model and a new query language on PostgreSQL. But we’ve risen to the challenge and are beginning to see the light of day — early EdgeQL users are raving, and native EdgeQL in TypeScript is surprisingly good.

If you’re not familiar with EdgeQL, simply put:

• EdgeQL adopts graph-relation model: manual JOIN is not required, and data relation is one of the basic concepts.
• Statements are inherently concatenable: everything can be used as an expression, and the resulting form is consistent;
• You can intuitively read and modify layers of nested associated data.

A picture is worth a thousand words.

Goals: Get all the movies Zendaya has appeared in, figure out the average rating for each movie, and the top 5 most important actors in each movie.

The EdgeQL implementation looks like this:

select
  Movie {
    title,
    rating := math::mean(.ratings.score)
    actors: {
      name
    } order by @credits_order
      limit 5,}filter
  "Zendaya" in .actors.name
Copy the code

A standard SQL modeling query looks like this:

SELECT
  title,
  Actors.name AS actor_name,
  (SELECT avg(score)
   FROM Movie_Reviews
   WHERE movie_id = Movie.id) AS rating
FROM
  Movie
  CROSS JOIN LATERAL (
    SELECT name
    FROM
      Movie_Actors
      INNER JOIN Person
        ON Movie_Actors.person_id = Person.id
      WHERE Movie_Actors.movie_id = Movie.id
      ORDER BY Movie_Actors.credits_order
      FETCH FIRST 5 ROWS ONLY
   ) AS Actors
WHERE
  'Zendaya' IN (
    SELECT Person.name
    FROM
      Movie_Actors
      INNER JOIN Person
        ON Movie_Actors.person_id = Person.id
  )
Copy the code

These two queries are not exactly equivalent because SQL does not support nested actors for movies, but we can pretend otherwise. Even so, the difference in length between the two pieces of text is striking, and it’s just one layer of nested queries.

Truly unique original definition

Now application is no longer a single server on a single program, on the contrary, a variety of services, apis and serverless function deployment in a huge number of network nodes, and all these programs should coordinate with each other, and agreed on what data is first hand, what state is legal, and more importantly – who has access to what. In other words, the ideal scenario is for the entire system to share a consistent source of state that can handle concurrent stress, and a database can do this very well, as long as your application and database agree on the correctness of the data.

And that correctness is what I’m talking about: if you can use a database to unify your data model and underlying operations, then the database can take care of data correctness and security.

Because the original text was written in haste, this paragraph is not particularly detailed and clear, using many abstract concepts and nouns. Specifically, EdgeDB solved often appear some problems in traditional technology stack, such as the same user data structures, on the front end and back end even written by different programming languages are repeated over and over again in different service definition, to form a consensus, so want to change user data structures have to change all along, very easy to get wrong. EdgeDB directly provides a schema definition language, and supports introspection. All EdgeDB clients can use the same definition, easily agree on data structures, and complete synchronous updates through built-in migration.

Another example is the basic operation. With traditional databases, some of the basic combinatorial implementations of database operations may be scattered throughout the system: database triggers, database stored procedures, drivers, ORM libraries, developer’s own wrappers in different programming languages, and so on. For applications, data manipulation can cause errors and conflicts in the end result because of the scattered and inconsistent logic, and it is difficult to debug. EdgeDB’s features, such as computational properties and generic functions, encapsulate basic operations so that different clients can easily and consistently manipulate data, making full use of the central characteristics and processing power of the database.

It’s not just database servers

Our mission is to make database superpowers available to developers, so we don’t stop at the database server itself.

We know that even the best databases can be ruined by a single bad client. That is why we always stick to their common official language for the client, currently covers Python and JavaScript/TypeScript/Deno and Go. However, it is obviously not practical to complete clients for all languages at the same time, so we also provide detailed client implementation documentation, as well as a common conformance test suite.

Although EdgeQL is far more comfortable than SQL, writing EdgeQL statement strings directly in code is not perfect. Fortunately, EdgeQL was designed with its existence as a compilation result in mind. That is, you can generate EdgeQL statements from your code so that you can construct EdgeQL queries using syntax and usage features from different programming languages. This uncompromising is one of our goals. EdgeDB 1.0 also shipped today with our JavaScript/TypeScript native query constructor.

The previous movie query, constructed in pure TypeScript, looks like this:

e.select(
  e.Movie, (movie) = > ({
    title: true.rating: e.math.mean(movie.reviews.score),
    actors: (actor) = > ({
      name: true.order_by: actor["@credits_order"].limit: 5,}).filter: e.op("Zendaya"."in", movie.actors.name)
  })
)
Copy the code

This is written with a surprisingly consistent structure to the original EdgeQL query, and almost the same number of lines of code. The advantage of this is that all fields in the query result have full type hints based on the type definitions automatically generated by the schema. . We are very pleased with this result, which proves how well EdgeQL can be incorporated into modern programming languages, further reducing the cognitive cost of developers.

Finally, there is our all-powerful CLI (edgeDB command), which not only provides interactive real-time query terminals and traditional database client commands, but also includes convenient instructions for installing and managing local database instances (soon to support cloud instances), interactive creation and execution of database migration, and more.

Apis for cloud computing

Modern applications tend to scale massively, which requires careful management of inelastic computing resources. Until cloud native databases can achieve the performance and functionality of traditional databases, we must acknowledge that databases are still a scarce resource in cloud computing. Unfortunately, traditional RDBMSS don’t perform well in cloud computing for two main reasons:

• Historically, client-server communication protocols were either too noisy or too silly, adding a lot of pointless overhead to the network.
• SQL is particularly bad for fetching and updating cascading data, and it’s common to see a series of queries for a single result, but ORM makes it worse.

This means that even simple operations are likely to result in multiple slow network traffic, which can take up valuable database connections and data locks, thus affecting overall system availability.

With that background, let’s take a look at how EdgeDB solves these problems. EdgeQL can assemble almost any number of query and modify operations into a single query statement. In order to reduce the network sending and receiving times, our client-server communication protocol has been specially designed and optimized, and usually requires only one request-response operation.

EdgeDB supports only one transaction isolation level, SERIALIZABLE, because this is the only correct posture for concurrent database interaction. SERIALIZABLE means that every now and then the server will reject a transaction and ask you to retry it; Another (less common) situation is that halfway through a transaction, the connection suddenly goes down because of a failover or network instability. In a distributed environment, these situations are quite common and are all perfectly manageable errors. Therefore, all EdgeDB client libraries natively support automatic transaction retry.

Looking to the future

The release of EdgeDB 1.0 was an important milestone for us, and we now have a solid foundation to continue our mission of building a true next-generation database! In other words, the best is yet to come.

We are planning a faster release cycle, with EdgeDB 2.0 coming in a few months. We are building a cloud service, and a lot of bold design goes far beyond the “service is up, connect to this IP yourself” usage scenario.

“Fasten your seat belt, the old driver is going to hit the gas!”

Finally, we would like to thank the early adopters in our community for helping us with feedback, testing early releases, and providing invaluable encouragement. I would like to ask you again to light up our star on GitHub and don’t forget to follow EdgeDB!

Welcome to share your experience with EdgeDB! ❤ ️

Welcome to our websiteThe official website,OSCHINA Project home page,Zhihu columnandThe nuggets columnFor more information.