Show HN: EdgeDB 1.0 • Hacker News Board

Re: Show HN: EdgeDB 1.0

#21

Post by 1st1 » Thu, Feb 10, 2022, 7:51 PM UTC

KwisaksHaderach wrote: post #19

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.

Re: Show HN: EdgeDB 1.0

#22

Post by sverhagen » Thu, Feb 10, 2022, 7:51 PM UTC

> the first open source, graph-relational database

OrientDB?

Re: Show HN: EdgeDB 1.0

#23

Post by RedCrowbar » Thu, Feb 10, 2022, 7:52 PM UTC

rahimiali wrote: post #18

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 relation…

(EdgeDB CTO here)

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.

Re: Show HN: EdgeDB 1.0

#24

Post by 1st1 » Thu, Feb 10, 2022, 7:53 PM UTC

KwisaksHaderach wrote: post #19

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.

Re: Show HN: EdgeDB 1.0

#25

Post by say_it_as_it_is » Thu, Feb 10, 2022, 7:57 PM UTC

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?

Re: Show HN: EdgeDB 1.0

#26

Post by miohtama » Thu, Feb 10, 2022, 7:58 PM UTC

RedCrowbar wrote: post #23

rahimiali wrote: post #18

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 relation…

(EdgeDB CTO here) 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-v…

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?

Re: Show HN: EdgeDB 1.0

#27

Post by 1st1 » Thu, Feb 10, 2022, 7:58 PM UTC

sverhagen wrote: post #22

> the first open source, graph-relational database OrientDB?

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.

Re: Show HN: EdgeDB 1.0

#28

Post by xdfg13345 » Thu, Feb 10, 2022, 7:58 PM UTC

Typo in the post "and also retrive the list of top 5"

should be retrieve

Re: Show HN: EdgeDB 1.0

#29

Post by 1st1 » Thu, Feb 10, 2022, 8:00 PM UTC

xdfg13345 wrote: post #28

Typo in the post "and also retrive the list of top 5" should be retrieve

Good catch! A fix will be deployed in a couple of minutes :)

Re: Show HN: EdgeDB 1.0

#30

Post by RedCrowbar » Thu, Feb 10, 2022, 8:00 PM UTC

miohtama wrote: post #26

RedCrowbar wrote: post #23

Earlier quoted context omitted.

(EdgeDB CTO here) 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-v…

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