271–280 of 332 posts
This seems kind of cool, but honestly the benefits described don't really solve actual problems I've run into in development. The overall article reads like marketing talk and doesn't actually describe concretely why it's better than existing solutions. For something as core as a database I would expect more rigorous descriptions and benchmarks. > We shall do better than SQL The EdgeQL language looks cool, and I'm su…
Earlier quoted context omitted.
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 compos…
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-ca…
EdgeDB is built on an extension of the relational data model that we call the graph-relational model. This model completely eliminates the object-relational impedance mismatch while retaining the solid basis of and performance of the classic relational model. I don't see how can they retain the performance of the relational model when using graphs on top of PG unless they are using PG as storage k/v layer only.
Can use these techniques on top of typical, existing relation model tables as well. Consider a join table, or even a polymorphic join table, that gives you the edges. But you can use unions and stuff to join up data across various tables. Can get really creative with it.
EdgeDB co-founder Yury here. Ask me anything :) Live launch stream: https://www.youtube.com/watch?v=WRZ3o-NsU_4
Do you offer fully managed service to host this or do I need to spin up some compute instances of my own ?
EdgeDB co-founder Yury here. Ask me anything :) Live launch stream: https://www.youtube.com/watch?v=WRZ3o-NsU_4
I looked through the documentation and all I could find was how to spin this up locally. How do I run this on the cloud? Do you offer fully managed service to host this or do I need to spin up some compute instances of my own ?
Can't wait for edgeDB cloud!
One use case I have (solved by some current graph DBs) is performing a complex full text search (boolean operators, stopword removal, fuzzy matching etc.), which alters search ranking based on graph properties (e.g. a node with more edges might get a reduction in score, the root of a tree might get a boost, etc.).
I'm still going through the tutorial, so haven't got to grips with what the DB is capable of yet.
I'm particularly excited about the HTTP and the GraphQL interface. This could potentially mean no need for a backend. One thing I am curious about it the authorization part of it - how can I limit the result set, similar to Row Level Security in Postgres?
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/
Forthcoming? Given that the last sign of live has been from 3 years ago in a space with already little movement GQL seems to be most likely dead.
Standardization projects typically take awhile, specifically for something complicated as a query language spec.
I feel like a graph database is a solution to an issue I've faced (and, continue to face) and it may just be because that I haven't spun one up and tried or that the documentation/examples don't stick out. But could someone confirm my feeling? If my feeling is correct, I'd enjoy verifying it with EdgeDB or the like. My example/requirement: I have a user wanting to find best-matching blog posts. Every post is tagged w…
EdgeDB employee here. I couldn't have asked for a better question to demonstrate the power of subqueries! Here's how I'd do this in EdgeQL: with tag_names := {"angular", "nestjs", "cypress", "nx"}, select BlogPost { title, tag_names := .tags.name, match_count := count((select .tags filter .name in tag_names)) } order by .match_count desc; Which would give you a result like this: [ { title: 'All the frameworks!', tag_…
So to only get blog posts with matching tags we would need to add a filter „match_count > 0“, right?
Update: I am very excited about EdgeDB :)
Hmm, no JVM or .NET support ... seems problematic for any widescale adoption at this point. Are there fundamental reasons why this is problematic or just not got around to it? (And, is it likely to be possible to build it against standard interfaces like JDBC - or is it too different?)