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