EdgeDB: A New Beginning (edgedb.com)

It’s definetly not a graph database, if it‘s based on postgresql - no index free adjecency as provided by real graphdbs like neo4j

I don't think their intent is to distance themselves from the term. Right there in the post, they're mentioning that the object-relational universe they're talking about is essentially a property graph. However, it doesn't seem like it's built to mirror a traditional graph database.

I agree. I don’t really know why it’s not considered a graph database. My understanding is that graph databases are about how relationships between data are represented, not that it’s schemaless.

> EdgeDB is not a graph database: the data is stored and queried using relational database techniques and requires a strict schema.

I feel like they make a pretty good case as to why this isn't a graph database, though I wonder if you might expand on your reasoning?

Why do you believe there should be a desire to distance oneself from a graph database? Graph databases are great when used correctly.

It seems like a _strongly typed_ graph database, which is significant. The lack of enforced typing has made me scared of graph databases in the past, so this feels significant to me as a potential user. Granted, maybe there are strongly typed graph databases, and I just don't know about them, or misinterpreted what I've read about existing graph databases.

If you are basing this on the idea that something that can store a graph is a graph database, I'm not sure that definition really holds up.

It has been argued -- for example by Neo4j, which is one of the leading graph databases -- that index-free adjacency is an essential feature for any real graph database, or as they put it, "Index-free adjacency is the key differentiatior of native graph processing." https://neo4j.com/blog/why-graph-databases-are-the-future/

By my reading, this system doesn't feature index-free adjacency as it uses relational tables as the substrate for edges. Thus EdgeDB won't be especially well suited type of graph traversals and queries that people actually select graph databases for. Which seems like a compelling reason not to identify it as a graph database.

What are your future plans? Which license?

What are the difference between EdgeDB and http://www.matisse.com ?

ETA for release?

License?

Given it's based off of postgres, whats the story look like for sharding/scaling?

Is EdgeDB going to be Postgres fork, extension or a service that uses just uses Postgres as a storage layer (like Datomic)?

Interesting concept, thanks for sharing.

I know most of these are heavy lifts, but any ideas around...

...materialized views?

...built-in versioning (Datomic-like)?

...story on how to play it nice with backend languages (One thing MongoDB imo did right)?

In some typical app, you have relational data with SQL on top of them, with ORM model on top of that, with some <Orm>QL on top of that, and your typical <Orm>QL query is transformed to SQL using ORM model. It is all some complexity. Having just object model and some object query language is a great simplification.

EdgeDB is very far from being an "ORM in the database". It properly implements an object data model on top of relational model, along with a properly designed query language.

I would like to rebuttal. If there exists any dynamic application, you need some type of data store to keep all of the records, whether it be a persistent database or simply an in-memory database. So, in my opinion, this is a truthy statement.

A lot of the content of that blog post is just pompous, nebulous marketing speak. I wish they would talk more about the technical details (like release some numbers or benchmarks). The example is the only part that is really interesting. I guess technical people aren't its target audience?

Thanks for the interest! We'll release a technology preview (along with the source code) in just a few weeks.

Your comment doesn’t have any substance. For what reason do you think it’s undesirable?

In a way, yes. EdgeDB implements type inheritance and abstract types, so you can have a schema like:

  abstract type Text:
    link body -> str

  type Post extending Text
  type Comment extending Text
  

And then query Text instances like this:

  SELECT Text {
    body,
    title := 'Post'    IF Text IS Post ELSE
             'Comment' IF Text IS Comment ELSE
             'unknown'
  };

Yes, automatic UI generation is something we've been doing with EdgeDB for years in our products. Having a uniform object data model and introspection makes it easy to automatically generated complex nested forms and grids. We'll likely build a React microframework to generate UIs for EdgeDB at some point after beta release.

I recently tried Postgraphile [1] on an existing postgres database (briefly just for fun, not in prod) and it sort of does what you want. As long as the foreign keys are there, it will generate the correct graphql queries. It even pluralizes the query names depending on whether it's a one-to-one or one-to-many relationship. Once it's in graphql you can just use the interactive graphql endpoint which has autocomplete and documentation to write your queries.

A schema like:

  create table post (
    id serial primary key,
    author_id int non null references user(id),
    headline text,
    body text,
    ...
  );

Can query relations like so:

  allPosts {
    edges {
      node {
        headline
        body
        author: userByAuthorId {
          name
        }
      }
    }
  }

[1] https://github.com/graphile/postgraphile/tree/postgraphile#a...

The [bracketed expression] is a target object type specifier in a path expression and can appear at any point in the path:

  User.<assignee[IS PullRequest].assignees[IS User].name

The reason for the FILTER clause is that you may want to write something like:

  FILTER User.name = 'Alice' OR User.<assignee[IS PullRequest].status = 'Open'

which is impossible to express if we were to simply filter each node set in the path separately.

> What would be nice to know is whether this can work on top of an existing PG database, providing easier syntax.

That would require introspecting arbitrary relational schemas and trying to represent them as an object graph. I don't think something like this can be done automatically and reliably.

That said, we have a tentative plan to introduce support for external databases (through FDWs, so not necessarily Postgres). The mapping specification would have to be explicit though.

We created a number of business applications that used earlier versions of EdgeDB. The list of companies we worked with is on our magic.io page :)

You or somebody else must have subscribed your email address. We've never added any single email to our MailChimp list ourselves.