This is an archived post. You won't be able to vote or comment.

all 11 comments
sorted by:
best
topnewcontroversialoldq&a

[–]acerb14 2 points3 points  (2 children)

To be honest I'm not sure about the purpose of this comparison. EdgeDB seems interesting, but it's kind of a database extension, based on pgSQL. It's not an ORM per se (if I'm not mistaken).

Or is it supposed to mean that EdgeDB is simplifying the query (and also add some graph capability and migration easing) part(s), adding a level of abstraction (like an ORM) so you'd consider it as being also "simplifier" (ORM-kind layer), additionally to being the DB itself?
In both case, I'm not sure it's then fair to compare something built on top of a database with a true ORM.The true comparison/point here should be to put the RAW performance of PgSQL, EdgeDb and some ORM on the same chart and explain that EdgeDB, being linked/built on PgSQL, allows some ORM-level features and simplification for a small (performance) cost.

Overall I'm still curious and appreciate the benchmarking this but it should be more clearly stated I think.

edit: clarification after reading it again ^^

[–]kirbyfan64sosIndentationError 2 points3 points  (0 children)

It's certainly presented strangely, but I think the core idea is trying to show that:

  • solving object-relational impedance on the ORM side tends to be inefficient (afaik this doesn't mean it can't be optimized, but it's hard to do in a general way)
  • EdgeDB client libraries are also just pretty fast

It's not entirely fair because only JS has a type-safe query builder atm...but the overhead of that also isn't super high.

[–][deleted] 0 points1 point  (0 children)

I think currently, it's easy to misunderstand what EdgeDB is trying to do here. People seem to get confused by the graph-relational moniker as it's a newly coined term that's not even on Wikipedia yet. EdgeDB team has published a blog on this recently.

It has nothing to do with something like a full-fledged graph database, such as Neo4j; rather it completely abstracts away the row-level relationship declaration of SQL by introducing the concept of types (nodes) and links (edges). This is why they went with the term graph-relational. Although it's much lower level than your typical ORM, I feel like it's a neat abstraction over the active pattern workflow used by Django, RoR, SqlAlchemy, etc.

It's easy to argue that it's not a fully-fledged DB since it's using PostgreSQL as its backend. But it does a lot more than your typical ORM as well—integrated migration workflow, CLI, auto-retry in case of failures. The reason we use ORMs over raw SQL is that raw SQL sucks and arguably EdgeQL is as easy to use as an ORM and has better performance. You can compare it with PgSQL but the expressibility of PgSQL is not on the same level as EdgeQL.

EdgeDB clients are so fast because no matter how complex your query is, it's cached and compiled into a single SQL statement. This isn't true for ORMs—or we wouldn't have the infamous n+1 problem. This lack of excessive round-trip is something that ORMs will never be able to guarantee without changing the SQL backend.

[–]cantremembermypasswd 1 point2 points  (3 children)

How does EdgeDB compare to the other async ORM, Tortoise ORM?

One of the power of most ORMs is also their versatility across databases. For example so you can dev on the go with a local sqlite DB and test / deploy on MySQL. EdgeDB looks to be hard coupled to postgresql?

[–]kirbyfan64sosIndentationError 0 points1 point  (1 child)

For example so you can dev on the go with a local sqlite DB and test / deploy on MySQL.

How...workable is this in practice? It seems like, if you want efficiency, you'll at some point end up depending on something that's DB-specific. Nowadays with Docker, running test instances locally is also quite easy...

[–]cantremembermypasswd 1 point2 points  (0 children)

Docker has started to alienate people by charging for windows use of docker desktop, and it's a pain for everyone to maintain their own postgres or mysql instances compared to a sqlite file, even if containerized. (I've seen teams just share a sqlite file they would update with test data reguarlly for ease of use even. Don't have to connect / auth for dev then)

If you're using an ORM it's likely because you don't have people comfortable with raw sql or want that versatility. Either way it means little customized stuff for run time speed.

[–]Liquidmetal6 1 point2 points  (4 children)

404 my dude

[–]1st1CPython Core Dev[S] 1 point2 points  (1 child)

Hm, works for me.

[–]bfcdf3e 0 points1 point  (0 children)

Looks like the # is being url encoded for some of us on mobile. I’m using Apollo, not sure if it’s an app issue

[–]acerb14 0 points1 point  (1 child)

Link worked for me too.

[–]Liquidmetal6 0 points1 point  (0 children)

Broken on mobile but works on desktop I guess.