Live data from Hacker News

Show HN: EdgeDB 1.0

edgedb.com

111–120 of 332 posts

Re: Show HN: EdgeDB 1.0

#111
post #78

Earlier quoted context omitted.

> Show me _how_ you can beat SQL Scroll down. They do exactly that.

Yeah, we also blogged about this extensively. Here are are some links: Pointed critique at SQL: [1] Benchmarks: [2] and [3] We'll be adding a dedicated benchmarks page to our website soon. [1] https://www.edgedb.com/blog/we-can-do-better-than-sql [2] https://www.edgedb.com/blog/edgedb-1-0-alpha-1 [3] https://www.edgedb.com/blog/edgedb-1-0-alpha-2

In [3] it says "we are assessing the code complexity and performance of a simple IMDb-like website built with Loopback, TypeORM, Sequelize, Prisma, Hasura, Postgraphile, raw SQL, and EdgeDB" but then it goes on to only explain the results of the classic ORMs but not hasura, postgraphile and prisma. Are the full results available somewhere?

That classic ORMs are kinda slow is probably not a surprise to anyone, the others which either get to compile the full query or have a hand in controlling the schema are more interesting.

They also seem more similar to your product, running as a server and managing the schema, so most worth comparing.

Edit: The fact that "Raw SQL" ends up being a suboptimal query because of the node driver limitations, which then gives you "Way faster than even raw SQL!!!" graphs also leaves a weird taste. I guess if you are comparing programming language level solutions fair enough.

Re: Show HN: EdgeDB 1.0

#112
post #99

Why a new language? I can see and understand why and where graphs beat out SQL, but what does EdgeQL have over existing graph languages? Eg. vs Cypher or the likely-Cypher-compatible forthcoming GQL standard? https://www.gqlstandards.org/

EdgeQL is designed to replace SQL, not graph query languages. Think of it as SQL getting a proper type system and GraphQL capabilities of reaching into deep relationships in an ergonomic way.

Re: Show HN: EdgeDB 1.0

#113
post #5

EdgeDB co-founder Yury here. Ask me anything :) Live launch stream: https://www.youtube.com/watch?v=WRZ3o-NsU_4

do you have plans to integrate with prisma? it's almost a DIRECT translation of how the query is expressed in Prisma compared to edgedb. Googling quickly, it seems there is a ticket already. I wonder if this could be a low hanging fruit and a great growth channel since prisma is very popular.

https://github.com/prisma/prisma/issues/10210

Re: Show HN: EdgeDB 1.0

#114
post #88

I don't understand the benefit. It's just a query language on top of Postgres? It doesn't seem to have the performance characteristics of a graph database, while acting like it does. JOINS will still be expensive. You guys shouldn't use the word graph, misleading.

I think the idea is to prove the query language more than deliver a database that has graph DB advantages. If they prove the language maybe they can implement a different backend. I'm just guessing here.

> If they prove the language maybe they can implement a different backend.

This is very true and might happen in a far future.

Re: Show HN: EdgeDB 1.0

#115
I know benchmarking DB is very hard and pretty much nonsense, but do you have any idea / production use cases of EdgeDB at large scale? Did you see a performance drawback given from the higher abstraction, and the EdgeDB stateless client between the app and postgre?

Re: Show HN: EdgeDB 1.0

#119
This query language looks really nice!

I wish GraphQL were more like this and considered built-in features like where clauses and cursors, instead of having to add those over the top with loose conventions.

Re: Show HN: EdgeDB 1.0

#120
post #91
post #7

Earlier quoted context omitted.

Thanks! The secret sauce is to pack nested shape queries into array_agg-ed SQL subquery. So we never select unnecessarily wide rows.

Sounds like this is not dissimilar from the GraphQL-to-SQL compiler in Hasura, which also brings out surprising performance for wildly nested frontend queries.

Yeah, indeed, Hasura uses json_agg, which is similar but returns you a JSON string.

We use array_agg, so we often avoid data serialization altogether. Our binary protocol just lets the data messages pass through with the original binary encoding. And because we fully control the schema, we can make all sorts of interesting optimizations, like implementing high-perf data codecs on the client side to unpack data fast.

Post reply on HN