Edgedb feedback, comparison of edgedb vs sqlmodel/sqlalchemy

edgedb_feedback.markdown

Notes on edgedb

I’ve made a test evaluation of edgedb for the purposes of a small company.

My order of priorities (starting from most important):

1. correctness of results (data and code)
2. developer convenience
3. minimal maintenance
4. efficiency/scalability

Setup that I compare to: postgresql on AWS aurora (managed with AWS CDK) + sqlalchemy + sqlmodel + alembic

EdgeDB provides a number of significant improvements over reference setup:

• SDL (schema definition language). I’d prefer it over ORM for schema management
• generation of migrations is provided by database tools. Finally
• select part of EdgeQL is expressive and readable
• (multi)links are more friendly than (double)joins
• computeds look extremely helpful, specially links
• access controls also looks very useful, as protecting access on db level is the best option

Downsides:

1. there is no way to migrate down (undo migration). I use it quite often, and don’t want to clutter history with experiments. (migrating down mostly happens in local and dev stages)

   Migration rewrite is undocumented. Github discussion did not help me at all.

2. edgedb website really pushes on composability of edgeql, i.e. you can ‘nest’ one query into another (like in graphQL).

   While the statement is correct, my understanding of composability includes ability to name some piece of code and refer to it by name. In other words, composability is useful when you can decompose into parts and combine them. SQL has temporary tables, views, common table expression - all far from being great tools, but to some degree they satisfy this requirement; edgeql queries don't.

   Another example of composability: ORMs can define some expression, and then pass it to outer scope, where expression can be narrowed down by subselecting for data required in this context. I don’t see a similar tool in edgedb/edgeql - queries are isolated and can't be combined.

3. Python client. That’s the biggest point, and edgedb loses to sqlalchemy/sqlmodel here.

   Official examples (e.g. for Flask) commonly use inline queries, which

   • are not statically checked against schema. For contrast, pycharm can read and validate sql queries even in python strings
   • results do not have helpful type hinting.

   Both points are a significant downgrade from sqlalchemy2/sqlmodel.

   Another available option is code generation. Queries written in .edgeql are wrapped into python code with proper typing. This addresses previous problems: code generation verifies query against the schema, and typing is available. Inconveniently, every query should be its own file.

   Code generation however does not reduce amount of code you need to write. To insert/update/upsert/select by id, you need to write a query with all parameters typed. I like that parameters are typed, but why can’t I just have it autogenerated from schema? This could be just a number of typed functions create_movie(id: Optional[uuid], title: str, …), update_movie(id: uuid, title: Optional[str]=NoValue, …)

   Or even embrace TypedDicts to map objects to deliver help with typing inputs/outputs without ORMs and classes.

   As a result, most common operations require a significant hassle in edgedb.

Comments:

• Some other things (uuid, inheritance, insert.. on conflict...) are available in postgres, so I don't mention them
• Typescript client is far more advanced. Well, if I used typescript, I'd probably compare with prisma.
• Syntax for back links doesn't click in my head
• I did not figure out how I manage edgedb with aurora (without cloudformation). Should be solvable.
• EdgeDB ui provides query editor, schema viewer, data viewer/editor. It simpolifies onboarding of new developers as they don't need to install any tools. Editor, on the other hand is not as convenient/advanced as e.g. IntelliJ's solutions.
• I've made a pass thru python repos on github that depend on edgedb, and none of them made a significant usage of edgedb. Best match actually ended up creating query builder on top of edgeql, in line with my previous points.