What a terrible attitude to have, that's truly the worst possible interpretation.

How's that dissing anything? They are saying they have a good abstraction that will make you more productive. While it might not be, this is literally what makes software the amazing tool it is, building layers of abstraction that make you more productive.

You seem to have gotten it all wrong, how could building something on top of SQL be dissing SQL? It's as much of a diss as C is a diss to assembly and so on.

> Show me _how_ you can beat SQL in performance

It is literally a postgres instance underneath, if edgedb is malleable enough, you don't need to beat anything, you'll have the query you want (sans edge cases and some minor overheads).

> I'm just happy to go along with what I already have

Go ahead bud, I'm pretty sure it won't be legally enforced to use any time soon so you're good to go.

The fact that this low effort comments get upvoted in HN drives me mad, just the contrarian attitude will get you points no matter the depth or effort. You don't seem to have even read the landing page or tried it, maybe you did but your comment doesn't reflect that, this is the product of 4 years of effort by some devs that are trying to innovate, dissing it without even fully seem to understanding makes me want to vomit.

It's very frustrating that whenever a team is showing something new they've built to HN, so many of the top comments are focused some incredibly nitpicky, personal issue that somehow negates everything else about the project.

It's an amazingly lazy and inconsiderate way to respond to people who've put a bunch of effort into building something.

It's at least partially a programmer thing, basically bikeshedding. Just imagine doing a code review with some of these commenters!

Agreed ! Usually when you look at these "haters" there is nothing of value in their "submission" sections under their profiles, which usually tells me exactly how to "read" the comment(insult).

>> Show me _how_ you can beat SQL in performance

> It is literally a postgres instance underneath,

Exactly. So. Why? Someone created a database abstraction? God damn, that has almost never happened before! ;)

Strong reaction. In general we shouldn't discourage exploration and moving the needle forward. I actually agree with you that the language is somewhat stronger and the onus is on them to live up to it, but at the same time there is a lot of competition in this space (newer DBs) so nothing wrong with setting the bar high enough. :) They are specific with their use case (APIs), so that's excellent, as the core itself will not relinquish all the learnings of the "last century". ;)

> 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.

We'll post some benchmarks against Hasura et al soon.

"Faster than SQL" is, of course, relative and depends on "what SQL"? EdgeQL compiles into a single query that uses PostgreSQL-specific features. This is a guarantee. No matter how large or complex your query is, if it compiles, it compiles into a single SQL query. Manually written or ORM-generated SQL tends to be "multi-query" due to the whole "standard SQL composes badly" story. And this matters, because if the roundtrip network latency between the client and the server is 10ms, EdgeQL will get you a response in ~10ms, whereas a multi-query approach will in (~10ms X <number-of-queries>) even if every individual query is super-quick to compute.

Would love to see benchmarks! :)

But just for clarity in the discussion thread here, Hasura also compiles to a single query when only Postgres is being hit and I'd expect performance to be quite similar...

Ofcourse, if the GraphQL query requires federation across multiple Postgres databases or multiple databases or databases + other GraphQL / REST APIs, then Hasura breaks them up into multiple queries with a worst-case performance of a data-loader type set up.

Yeah, compiling a data access DSL down to SQL, potentially through some intermediate AST, is not as novel as it's being made to sound around here. I feel like I'm being gaslighted.

>> Show me _how_ you can beat SQL

> Scroll down. They do exactly that.

Where?

Makes you want to vomit? That's a bit over the top.

Not want to vomit, actually vomit. Apparently.