EdgeDB employee here. We're beyond excited to finally publish a stable release of EdgeDB after 4 years of active development and 15 pre-releases. Happy to answer any questions on here!
Very interested in what data engineers think about this project!
I am not a developer, but the founders (including Yury Selivanov, Python Core Developer, see also https://github.com/MagicStack) and the fact that these people have been investing in the project for four years already, make me think that EdgeDB can be an important project for the database world!
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.
Yeah, that‘s an appealing idea, if there never even has to be any json.
Hasura has the frontend safe API and strong authz going for it. Is that something you might also do, or are you focused on serving the backend? End-user row and column level authz gives me a lot of peace of mind when writing bigger queries.
Our topmost priority now is launching a hosted version of the product, all hands on deck. Having a proper (and potentially fully type-safe) query builder for Python is literally the next to-do.
How do we migrate from existing Postgres database to EdgeDB? Can traditional app still access all the relational as before and new app access via EdgeDB? We're making use of existing environment and extending it with our own frontend. I would like to understand how I can mix legacy and new code.
We plan to introduce a tool for assisting migration from SQL databases, but at this very moment, the only way to migrate an existing app is to re-create your DB schema in EdgeDB and then write a script to import the data. EdgeDB right now is definitely more geared towards starting new projects with it.
Maybe if you move all data to be managed by EdgeDB, then create a separate "legacy" schema that just contains views & triggers that forwards queries and mutations to the EdgeDB database.
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.
Ctrl-c cancels running processes, but not shells. When a process becomes a shell I can not say, but if make an infinite loop in the Python repl you can Ctrl-C that loop.
$ python
>>> while True:
... pass
...
^CTraceback (most recent call last):
File "<stdin>", line 1, in <module>
KeyboardInterrupt
I have a few questions I can't find after skimming the documentation..
Can someone use Postgres extensions with EdgeDB, like TimescaleDB, PostGIS, Zombodb and Postgres_fdw?
How are sum types (called enums in Rust) modelled in EdgeDB? (like Rust's Result). Do I need to define it with inheritance, where each variant inherits from it? What about adding specific syntax for sum types?
Regarding extensions: we plan to wrap the most popular ones like PostGIS to give them idiomatic EdgeQL flavor. We need to do a bit of work to make that the right way.
Sum types can be modeled with inheritance. You can create an abstract base type and use that as target for the links. You can then derive types from it and write polymorphic EdgeQL queries to select/match data.
Rust client is still work on progress, not really open to tinkering unless you want to experiment.
Technically speaking though, using GraphQL as a data model is quite limiting: just basic scalar types and a handful of custom types implemented by DGraph (Polygon, etc). By contrast EdgeDB schemas support a much wider range of granular types, constraints, computed properties, link properties, etc.
Perhaps more importantly EdgeQL is a full query language with composable syntax, a standard library of functions and operators, for loops, primitive literal manipulations (e.g. string indexing and slicing), the ability to cast values to different types, subqueries, etc. Basically it's a complete query language contrast GraphQL is closer to an ORM in that it really only supports CRUD.
Thank you. The feature set is indeed pretty deep. We are going to have a C# client for sure, but I don't have any ETA yet. FWIW you can interact with EdgeDB over HTTP!
If you use a graph database to store application data and you want a strict schema (and potentially improved performance), then YES.
If you use a graph database to run graph algorithms on your data, then NO. Although we'll be working on adding support for recursive queries to EdgeQL in the near future.
Right on. I have been in the position before where I needed to do some graph-like queries (where I had to traverse several levels of joins with the number of joins unknown a priori) but at the same time this was an application storing structured data. I found myself in a tight spot between doing some really clunky Postgres stuff or going the graph DB route. I would have loved to have something that can be used like a relational DB 95% of the time but can still handle that 5% of graph-like queries with reasonable performance and complexity.
Could someone explain what a graph-relational database is? I'm not able to extract a technical definition from the paragraph below:
"What is a graph-relational database? 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. This makes EdgeDB an ideal database for application development."
In a classic relational model everything is a tuple containing scalar values. Graph-relational extends the relational data model in three ways:
- every relation always has a global immutable key independent of data (explicit autoincrement keys aren't needed)
- this enables us to add a "reference type", which is essentially a pointer to some other record (i.e. a foreign key)
- attributes can be set-valued, so you can have nested collections in queries and in your data model.
This is what lets us do `Movie.actors.name` instead of a bunch of `JOINs`, because `actors` is declared as a set-valued reference type in the `Movie` relation.
This is a nice example. How the data is stored physically? Does the model work for large datasets and when it could break down? What are optimal workloads? Do we still need to fiddle with indexing and such?
Data is stored relationally in Postgres in 3NF. References are indexed automatically, but you still need to index type properties if you use them in `filter`.
Wait, it stores the data in Postgres? So this is essentially a data model on Postgres?
FWIW, I do think there's a space in the market for a thin wrapper over Postgres (or MySQL) which would automate certain optimisations such as whether to index a particular table. It always struck me as perverse that that optimisation was delegated to the developer, when it's no more subjective or application-specific than a thousand other automated optimisations the engine makes. I'd be really interested if your project covered that.
It's built on Postgres, but it isn't a _thin_ wrapper. We lean hard into Postgres query machinery and type system in order to pull off EdgeQL and graph-relational efficiently.
Ah, OK, interesting! I don't have an immediate use case personally, but I wish you guys the very best. Honestly, database space needs way more competition than it has at present.
There are countless permutations of the choices that database designers face, so it's a shame there aren't mature products for more of them. I hope this particular permutation turns out to be a good one for lots of people :)
We compile EdgeQL queries into SQL currently, because it makes the architecture simpler and less us run on unmodifed Postgres, but conceptually nothing stops us from targeting the query planner directly via an extension or an alternative frontend that consumes EdgeQL IR direclty.
Ah, this is interesting: so Postgres is effectively a 'backend' for you, in much the same way that e.g. InnoDB is a backend for MySQL[0]?
And you - or hypothetically the end user - could change the backend, e.g. to Cockroach for better horizontal scalability, while trusting that EdgeDB will only rely on Postgres's public API at least in meeting its own public API/contract?
[0] It's hard to make that analogy with Postgres b/c it only has one storage engine, but of course the separation still exists.
I’ve always wished for MongoDB to have a “deepFind”, so that when I fetch a document, it will fetch the nested relations also instead of doing an aggression to do the lookup. Feel like if their objectID only included a collection name reference then somehow it should be possible. Perhaps a depth parameter would use be useful for more relational data.
Congrats on the milestone! Will definitively have a look at edgeDB.
There used to be a DBLink data type containing both collection and id. But without any additional features using it.
It was considered bad practice and eventually got deprecated. Since 99% of the time the collection link in a given attribute is fixed and known in advance so it’s just duplicate information.
We're working on a more comprehensive explanation of why EdgeDB isn't an ORM. Does EdgeDB do "object-relational mapping" under the hood — absolutely. The reason we try to distance ourselves from the category of ORMs is that the term "ORM" comes with a big bag of preconceptions that don't apply here.
EdgeDB has:
- Full schema model with indexing, constraints, defaults, computed properties, stored procedures
- A query language that replaces SQL. If there's something you can do in SQL that isn't possible in EdgeQL, it's a bug.
- The query language is backed by a full type system, grammar, set of functions and operators, etc.
- A set of drivers for different languages that implement our binary protocol.
By any definition, EdgeDB is a database. It's a new abstraction built on a lower-level abstraction: Postgres's query engine. Both abstractions indubitably fit any reasonable definition of "database".
Basically: just because there's a declarative object-oriented schema doesn't mean this "is just an ORM" (unless your definition is quite pedantic).
It runs as a separate (stateless) process between the client and the PostgreSQL server. There was a talk about the details of the architecture on the live stream today: https://youtu.be/WRZ3o-NsU_4?t=5294
It's something we want to do at some point, but unlike Hasura, which operates on GraphQL which is conceptually much simpler and limited, EdgeQL would be much harder to fit onto a "pipelined polling" model that Hasura utilizes to implement subs.
So, there is, basically, no way to work with Postgres directly, as well as installing EdgeDB with the use of the existing Postgres installation and its data, right? Feels like a Postgres is a prisoner of the EdgeDB :)
If you look at the code they used to have —postgres-dsn URL, now they changed it to —backend-dsn. If you go beyond the marketing, edgedb is a postgres connection pool+orm combined together with a query language (its a huge work in itself and commendable given it takes away many dependencies and provide a consistent developer experience). It’s leveraging postgresql server which is the true database providing ACID compliance.
Edgedb is more akin to hasura than to a database in traditional sense.
Hi there!
Yes, I do understand and that the EdgeDB is "a postgres connection pool+orm combined together" and the work guys did is incredible. And I do beleive it will find its niche. But for me, personaly, the idea of "postgres is now a black box for you, don't even try to go deeper into it" stops me from digging into EdgeDB right away (the tooling is amazing! migrations!) and even trying it in our production for our enterprize clients. Probably, with time, when edgeql can fully replace sql and plpgsql, we could say that EdgeDB is ready for everything.
BTW, @RedCrowbar, how can I call a udf or procedure (written in sql/plpgsql) from edgeql? I didn't find it in the docs.
There is no way to call UDF SQL (or PL/pgSQL) functions from EdgeDB, because there is no way to _define_ or manage them. The only place that is allowed to do this is the standard library (and, in the near future, extensions).
We realize that the database must be extensible and flexible, so non-EdgeQL UDF will become a reality (and if things work out the way we hope they will, they'll be amazing and far beyond what you can do with plpgsql).
Re "just an ORM", it seems like the word "mapper" is the hint that it isn't, since there's no "mapping" from the object-oriented view to the big-pile-of-scalars in a traditional relational db.
It's the first time I hear about graph-relational DBs. I remember back in college learning about graph databases, but since I never touched one I don't remember much TBH.
Is a graph-relational database something completely disjointed from a graph database? Or do they share some performance improvements to some use cases? Also does EdgeDB keep the advantages of a true graph database even being based on Postgres?
> It's the first time I hear about graph-relational DBs.
This is unsurprising, because we just invented the term :-)
> Is a graph-relational database something completely disjointed from a graph database?
Graph-relational is still relational, i.e. it's a relational model with extensions that make modeling and querying graph-like data easier. And in apps everything is graph-like (hence GraphQL etc). An important point is that graph-relational, like relational is storage-agnostic, i.e. it makes no assumptions on how data is actually arranged on disk.
Pure graph databases, on the other hand, encode the assumption that data is actually _physically_ organized as a graph into their model and query languages.
I guess the word "graph" is simply too overloaded in computing.
There’s at least one German-Bulgarian company called Plan-Vision that implemented such graph-relational approach like 15 years ago. their VSQL is similarly working on the E/R conceptual level and gets translated (or compiled into) to the underlying Postgresql or Oracle. You also get a neat EcmaScript like language that works with the collections in a graph like manner.
Long before Arango, Orient etc.
The company is absolutely nowhere near to you guys in terms of marketing, but their thing works with more than 40 enterprise clients so far.
So you definitely did not ‘just’ invent the concept. A lot of companies approach the problem one way or another…
>Pure graph databases, on the other hand, encode the assumption that data is actually _physically_ organized as a graph into their model and query languages.
What would be the benefit / disadvantage in each case?
Firstly, what happens to the performance when I have a sizeable resultset of set-valued data?
I've seen similar ideas implemented in the past that look fine for the Movies and Actors or Books and Authors examples but fall apart badly when you query a number of fields (20+) that have sets within them, which can happen on say, a sizeable reference database of marketing information.
Another question: How deep in the graph can I go, and how much circular reference protection is there? E.g. if I query Movie.actors.movies.actors?
I'm interested in graph databases and data modeling and while it offers some convenience I'm always skeptical but hopeful (mostly from having lost a lot of hours) that these problems have been solved sufficiently to keep performance good in practical use cases.
EdgeDB is graph-relational, not a pure graph database, and so the performance characteristics of traversing links are that of a relational JOIN. Which, of course, depends wholly on the size of each relation being joined. So, if you want to select the list of actors for _every_ movie in your database and there are lots of movies, it'd be a pretty expensive operation. If, on the other hand, you want to select some relationships on a handful of objects (or even just one), then it doesn't really matter that much how deep your link traversal is, because all of the steps would be fast index scans.
> How deep in the graph can I go,
As much as you want, though the path must be explicit, EdgeQL currently doesn't have any way to say "traverse link foo recursively".
That's awesome. I think you've hit the nail on the head by trying to fix the SQL part of relational databases and not the relational part. It's been a pet peeve of mine for ages that relational databases have been described as inadequate for modelling relationships and graph databases have been described as the solution. You CAN'T fix the problem just by going from n-ary to binary relationships.
How deeply is EdgeDB integrated into Posgresql? Any chance it could be used to query other databases eventually?
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.
The key insight here is that we still have schema. We have high-level object types and a first-class notion of a "reference" - we call it "link". Our other extension of the relational model is that every "row" must have a unique ID. Both things combined implement a graph or your types and a graph of your data as it's stored in the underlying tables. Everything is strictly typed and efficient.
But EdgeDB isn't ideal for storing loosely typed graph data, neo4j is built for that.
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.
As far as I'm aware OrientDB don't call themselves "graph-relational". In fact, they're positioning themselves as a multi-model NoSQL database. Where's EdgeDB positions itself as a relational database and a successor of SQL.
I think this work is absolutely commendable, but at the end of the day it's a database written in Python with Rust extensions sprinkled here and there. Is 1.0 your MVP?
EdgeDB is built on top of Postgres. The performance critical bits are either Python compiled to C with Cython or Rust, so there's almost no Python overhead.
I tried the beta around August last year. I struggled grokking it mostly because I had had very minimal experience with SQL - which it kind of assumed you already know the drawbacks of. However, I did like the idea very much.
It's a matter of taste. We decided to do a "looks like SQL + GraphQL" style because that's what most people are familiar when they think about a query language.
That said, the functional variant is a likely way to represent EdgeQL in programming languages.
Keep in mind that EdgeQL is a query language that can be used from any programming language (either over the official libraries, or over HTTP). Functional JS-inspired dialects aren't appealing to everybody.
Congrats - this looks really interesting, and this is coming from a person who generally ignores new shiny database news. Def will be checking this out!
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.
a graph database is not useful because of its query language, it's useful because of its performance characteristics when bringing linked data — it could never be performant on a Postgres backend.
to be fair, I don't know EdgeDB's architecture but to the degree that a system can bring its graph structures into memory, using PostgreSQL as the durable storage but not for every on-demand query, it can certainly provide fast results. I would assume EdgeDB likely has concepts like this integrated into its design.
On https://www.edgedb.com/tutorial/basic-queries/objects, if I change "SELECT User.name;" to "SELECT User.Name;" the page crashes with, "Application error: a client-side exception has occurred." It crashes on Chrome and Edge.
Oh, EdgeDB is so much more than "basically an ORM layer". I suggest to scroll to the bottom of our home page edgedb.com and read the dedicated FAQ entry. I just don't want to restate the entire explanation here.
Can someone from EdgeDB explain why the SQL isn't as simple as what I have below? What am I missing? Why is that cross join lateral necessary:
SELECT
title,
ARRAY_SLICE(ARRAY_AGG(movie_actors.name WITHIN GROUP (order by movie_actors.credits_order asc)),0,5)
avg(movie_reviews.score)
FROM movie
JOIN movie_actors on (movie.id = movie_actors.movie_id)
JOIN person on (movie_Actors.person_id = person.id)
JOIN movie_reviews on (movie.id = movie_reviews.id)
WHERE person.name like '%Zendaya%'
group by title
Also, this query is wrong because we want movies where Zendaya played, but _also_ other actors in order, possibly without Zendaya, so you really need to do the actors join twice.
> We should not continue wasting our productivity with a database API architecture from the last century.
Sorry, but dissing proven technology like this just makes me vomit. Show me _how_ you can beat SQL in performance and features on the frontpage, or I'm just happy to go along with what I already have.
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.
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.
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". ;)
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.
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).
One thing that can facilitate adoption is a smooth path from a working software based on Postgresql to EdgeDB:
We have a software that's a GraphQL interface to a database that's populated with a project (let's call it the indexer project) we do not control. It would be great if we could check the database schema for problems it might have to be used as an EdgeDB database. Then we would migrate our application to use EdgeDB, while the indexer keeps loading our database through direct interaction with PostgreSql.
> EdgeDB does not treat Postgres as a simple standard SQL store. The opposite is true. To realize the full potential of the graph-relational model and EdgeQL efficiently, we must squeeze every last bit of functionality out of PostgreSQL's implementation of SQL and its schema. Even then we've bumped into the ceiling quite a few times, and needed to send patches and bug reports upstream. That's also why EdgeDB currently requires PostgreSQL 13 or later.
331 comments
[ 7.5 ms ] story [ 307 ms ] threadVery interested in what data engineers think about this project!
I am not a developer, but the founders (including Yury Selivanov, Python Core Developer, see also https://github.com/MagicStack) and the fact that these people have been investing in the project for four years already, make me think that EdgeDB can be an important project for the database world!
Live launch stream: https://www.youtube.com/watch?v=WRZ3o-NsU_4
How do you folks solve the large amount of joins that are the result of graph queries? Any worst-case-optimal multi-way-join secret sauce :D?
Also, with DBs like Datomic competing in the same area, do you have an immutability/versioning story?
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.
Hasura has the frontend safe API and strong authz going for it. Is that something you might also do, or are you focused on serving the backend? End-user row and column level authz gives me a lot of peace of mind when writing bigger queries.
https://github.com/prisma/prisma/issues/10210
See also this reply by Colin: https://news.ycombinator.com/item?id=30293544
Can someone use Postgres extensions with EdgeDB, like TimescaleDB, PostGIS, Zombodb and Postgres_fdw?
How are sum types (called enums in Rust) modelled in EdgeDB? (like Rust's Result). Do I need to define it with inheritance, where each variant inherits from it? What about adding specific syntax for sum types?
edit: also, I see there's a WIP custom #[derive] for Rust in https://github.com/edgedb/edgedb-rust - can it store Rust types on EdgeDB? Something like http://diesel.rs/ or even https://lib.rs/crates/turbosql
Sum types can be modeled with inheritance. You can create an abstract base type and use that as target for the links. You can then derive types from it and write polymorphic EdgeQL queries to select/match data.
Rust client is still work on progress, not really open to tinkering unless you want to experiment.
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!
Technically speaking though, using GraphQL as a data model is quite limiting: just basic scalar types and a handful of custom types implemented by DGraph (Polygon, etc). By contrast EdgeDB schemas support a much wider range of granular types, constraints, computed properties, link properties, etc.
Perhaps more importantly EdgeQL is a full query language with composable syntax, a standard library of functions and operators, for loops, primitive literal manipulations (e.g. string indexing and slicing), the ability to cast values to different types, subqueries, etc. Basically it's a complete query language contrast GraphQL is closer to an ORM in that it really only supports CRUD.
I think DQL is marginally more powerful though admittedly I'm not very familiar with it: https://dgraph.io/docs/get-started/
impoart * as edgedb from "edgedb";
If you use a graph database to run graph algorithms on your data, then NO. Although we'll be working on adding support for recursive queries to EdgeQL in the near future.
Is there a roadmap I can subscribe to somewhere?
Looking forward to trying this out!
"What is a graph-relational database? 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. This makes EdgeDB an ideal database for application development."
In a classic relational model everything is a tuple containing scalar values. Graph-relational extends the relational data model in three ways:
- every relation always has a global immutable key independent of data (explicit autoincrement keys aren't needed)
- this enables us to add a "reference type", which is essentially a pointer to some other record (i.e. a foreign key)
- attributes can be set-valued, so you can have nested collections in queries and in your data model.
This is what lets us do `Movie.actors.name` instead of a bunch of `JOINs`, because `actors` is declared as a set-valued reference type in the `Movie` relation.
FWIW, I do think there's a space in the market for a thin wrapper over Postgres (or MySQL) which would automate certain optimisations such as whether to index a particular table. It always struck me as perverse that that optimisation was delegated to the developer, when it's no more subjective or application-specific than a thousand other automated optimisations the engine makes. I'd be really interested if your project covered that.
There are countless permutations of the choices that database designers face, so it's a shame there aren't mature products for more of them. I hope this particular permutation turns out to be a good one for lots of people :)
And you - or hypothetically the end user - could change the backend, e.g. to Cockroach for better horizontal scalability, while trusting that EdgeDB will only rely on Postgres's public API at least in meeting its own public API/contract?
[0] It's hard to make that analogy with Postgres b/c it only has one storage engine, but of course the separation still exists.
From the docs:
Performs a recursive search on a collection, with options for restricting the search by recursion depth and query filter.
https://docs.mongodb.com/manual/reference/operator/aggregati...
It was considered bad practice and eventually got deprecated. Since 99% of the time the collection link in a given attribute is fixed and known in advance so it’s just duplicate information.
EdgeDB has:
- Full schema model with indexing, constraints, defaults, computed properties, stored procedures
- A query language that replaces SQL. If there's something you can do in SQL that isn't possible in EdgeQL, it's a bug.
- The query language is backed by a full type system, grammar, set of functions and operators, etc.
- A set of drivers for different languages that implement our binary protocol.
By any definition, EdgeDB is a database. It's a new abstraction built on a lower-level abstraction: Postgres's query engine. Both abstractions indubitably fit any reasonable definition of "database".
Basically: just because there's a declarative object-oriented schema doesn't mean this "is just an ORM" (unless your definition is quite pedantic).
If I build a DB Schema in EdgeDB, can I interact with the underlying Postgres instance using regular SQL?
Edgedb is more akin to hasura than to a database in traditional sense.
We realize that the database must be extensible and flexible, so non-EdgeQL UDF will become a reality (and if things work out the way we hope they will, they'll be amazing and far beyond what you can do with plpgsql).
Is a graph-relational database something completely disjointed from a graph database? Or do they share some performance improvements to some use cases? Also does EdgeDB keep the advantages of a true graph database even being based on Postgres?
This is unsurprising, because we just invented the term :-)
> Is a graph-relational database something completely disjointed from a graph database?
Graph-relational is still relational, i.e. it's a relational model with extensions that make modeling and querying graph-like data easier. And in apps everything is graph-like (hence GraphQL etc). An important point is that graph-relational, like relational is storage-agnostic, i.e. it makes no assumptions on how data is actually arranged on disk.
Pure graph databases, on the other hand, encode the assumption that data is actually _physically_ organized as a graph into their model and query languages.
I guess the word "graph" is simply too overloaded in computing.
Long before Arango, Orient etc.
The company is absolutely nowhere near to you guys in terms of marketing, but their thing works with more than 40 enterprise clients so far.
So you definitely did not ‘just’ invent the concept. A lot of companies approach the problem one way or another…
What would be the benefit / disadvantage in each case?
I have a couple of questions around this.
Firstly, what happens to the performance when I have a sizeable resultset of set-valued data?
I've seen similar ideas implemented in the past that look fine for the Movies and Actors or Books and Authors examples but fall apart badly when you query a number of fields (20+) that have sets within them, which can happen on say, a sizeable reference database of marketing information.
Another question: How deep in the graph can I go, and how much circular reference protection is there? E.g. if I query Movie.actors.movies.actors?
I'm interested in graph databases and data modeling and while it offers some convenience I'm always skeptical but hopeful (mostly from having lost a lot of hours) that these problems have been solved sufficiently to keep performance good in practical use cases.
> How deep in the graph can I go,
As much as you want, though the path must be explicit, EdgeQL currently doesn't have any way to say "traverse link foo recursively".
How deeply is EdgeDB integrated into Posgresql? Any chance it could be used to query other databases eventually?
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.
But EdgeDB isn't ideal for storing loosely typed graph data, neo4j is built for that.
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.
OrientDB?
How you guys compare yourself to dgraph database?
We perform quite favorably in benchmarks, see our old blog post with some: https://www.edgedb.com/blog/edgedb-1-0-alpha-2#results
> Is 1.0 your MVP?
EdgeDB is ready for production and is light years ahead of its first technical preview MVP release published a few years ago.
should be retrieve
Looking forward to giving it another try soon!
To quickly learn EdgeQL I recommend our online interactive in-browser tutorial: [1]
We also have a book, it's called Easy EdgeDB, check it out here: [2]
[1] https://www.edgedb.com/tutorial
[2] https://www.edgedb.com/easy-edgedb
That said, the functional variant is a likely way to represent EdgeQL in programming languages.
Also, it looks like your version also does implicit joins (like EdgeDB), but I'm not sure how they would work in that style.
[1] Or maybe only movies where Zendaya is in the first 5 credited actors; I'm not sure.
This is very true and might happen in a far future.
a graph database is not useful because of its query language, it's useful because of its performance characteristics when bringing linked data — it could never be performant on a Postgres backend.
> InvalidReferenceError: object type 'default::User' has no link or property 'Name' > Hint: did you mean 'name'?
Which is the expected response (same as the edgedb cli)
Are you going to support some kind of subscriptions for realtime?
Would a graphql API be part of your roadmap?
Sorry, but dissing proven technology like this just makes me vomit. Show me _how_ you can beat SQL in performance and features on the frontpage, or I'm just happy to go along with what I already have.
Scroll down. They do exactly that.
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
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.
"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.
> Scroll down. They do exactly that.
Where?
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 an amazingly lazy and inconsiderate way to respond to people who've put a bunch of effort into building something.
> It is literally a postgres instance underneath,
Exactly. So. Why? Someone created a database abstraction? God damn, that has almost never happened before! ;)
We have a software that's a GraphQL interface to a database that's populated with a project (let's call it the indexer project) we do not control. It would be great if we could check the database schema for problems it might have to be used as an EdgeDB database. Then we would migrate our application to use EdgeDB, while the indexer keeps loading our database through direct interaction with PostgreSql.
https://github.com/edgedb/edgedb/discussions/3403