We've spent a lot of time formally defining our data model (a paper will be soon published on that, stay tuned!) and the query language. Designing it we had a few goals in mind:
* composability shouldn't be limited for any part of the language. You can shift things around and they'll continue to work. EdgeQL kinda feels like writing Python or JS code.
* performance should be great, and that is made possible by two things: we're building on top if Postgres (basically using it as the engine replacing its frontend) and by writing a sophisticated compiler from EdgeQL to optimized SQL.
* readability -- we always wanted EdgeQL to be quick to learn and master, and on average it takes just a couple of minutes for someone to write their first query, you can try it yourself in your browser here [1]
* composability shouldn't be limited for any part of the language. You can shift things around and they'll continue to work. EdgeQL kinda feels like writing Python or JS code.
* performance should be great, and that is made possible by two things: we're building on top if Postgres (basically using it as the engine replacing its frontend) and by writing a sophisticated compiler from EdgeQL to optimized SQL.
* readability -- we always wanted EdgeQL to be quick to learn and master, and on average it takes just a couple of minutes for someone to write their first query, you can try it yourself in your browser here [1]
[1] https://www.edgedb.com/tutorial