EdgeDB: A New Beginning | Hacker News Reader

EdgeDB: A New Beginning

edgedb.com

116 points1st165 comments

Well ... I kinda like the query syntax's ability to traverse relationships, nest objects/sub-headings, and apply filters at the level of projected expressions!

This has been done before of course, but I'm not sure I've seen this combination of syntax on an RDB before. It's certainly easier to read and write that a bunch of outer joins.

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

While their last example makes _sense_:

  open_prs := User.<assignee[IS PullRequest] {  
      title
  } FILTER .status = 'Open'

I don't find it easy to read/understand. If the [bracketed expression] acts as a filter, why not:

  open_prs := User.<assignee[IS PullRequest AND 
                            .status='open'].title

which preserves the nice dot-chaining for link traversal.

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

Glad to hear about the FDWs ... but wouldn't foreign keys be your friend here? What else would you need, really, to layer this on an existing DB?

If your schema consistently uses synthetic primary keys, maybe like the ones produced by some active record ORMs, then, yes. Theoretically, we could make an adapter that would make EdgeDB "understand" Django schemas, for example.

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.

I would love to see some auto generated (non-techie) graphical user interface for this like phpmyadmin but w/o all the developer focused options.

Eg. if there is a m:n relationship do not make me enter some foreign key values into a join table but give me some nice autocomplete fields or checkboxes on either side of the relationships' types.

Or if there is some transitive relationship like "country -> city -> district -> office", give me some nice way to filter the list of offices by a given country oder district.

Auto generates this from the schema as web interface.

I already tried building this for SQL schemata but it seems like a schema definition as provided by EdgeDB seems predestined for this use case.

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

You aware of any graphsql layer for postgres implemented in pgsql or pl/python?

Something like using JSONB datatype in a entity key value store table. Mapping materialized views using pgsql json functions. To flatten out the data into sql tables for normal consumption?

postgraphile# is a good solution, even more this project allow u to write ur custom adapters for each db

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.

Have you looked at dumping json-schema? Because then something like json-editor[0] will just work out of the box.

Got extensively tested with swagger v2(openapi)[1].

After the json-schema you write a quick swagger spec and modify a couple of mustache templates[3] to generate a crud interface for server and client. In your language of choice.

All with one magic yaml file; but file format agnostic as well;

Personally I struggle to read the json format.

[0]: https://github.com/json-editor/json-editor [1]: https://github.com/swagger-api/swagger-editor/tree/2.x [3]: https://github.com/swagger-api/swagger-codegen/

I understand the desire to distance oneself from the term graph database, but this is a graph database.

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.

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.

It seems more similar in spirit to triplestores, which are pretty neat all things considered. It also reminds me a lot of Datomic, but without the Clojure-ness and immutability.

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.

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

We don't want to distance EdgeDB from graph databases. We just want to clearly show the difference between EdgeDB and, for example, neo4j.

> 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?

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.

Graph database operates on Nodes and Edges between Nodes. Object Database operates on objects with fields. EdgeDB looks more like object database.

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

redcrowbar (Elvis) and I (Yury) are the authors of the post. Happy to answer questions ;)

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

It's closer to the storage layer: postgres is in the core and not directly exposed (i.e. you won't be able to access it).

Does it mean it will be possible to use EdgeDB with hosted Postgres databases, like RDS and maybe Amazon Aurora (on Postgres mode)?

Maybe. This is something that we'll have to figure out later.

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)?

> materialized views

Yes, although not in the initial release. EdgeDB _does_ support regular views, which, like the queries, can define arbitrary data hierarchies which can be treated like real object types. This topic deserves a separate blog post.

> built-in versioning

Not planned as a native feature as of now, although that's something that can be implemented on top with the query rewrite system.

> story on how to play it nice with backend languages

Immediately, EdgeDB supports a RESTful protocol with JSON as the exchange format. We will be adding native protocol implementations for major languages as well.

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

Matisse is close to a traditional ODBMS which implements .NET class mapping to SQL. EdgeDB is not an ODBMS in that sense, it is not tied to any platform or class model.

The main differentiating point of EdgeDB is EdgeQL (and native GraphQL support).

What are your future plans? Which license?

We'll soon offer a public preview of the database. The license will likely be some form of GPL.

ETA for release?

License?

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

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

They don't mention CAP, 2PC or anything like that, so obviously no sharding, no scaling, no consistency guarantees in a distributed environment.

We don't want to focus on scalability at this point. Getting the data model and query language right is our top priority.

As for scaling, citusdata clearly demonstrates that its possible to scale Postgres, so we are not particularly worried about this.

So there were not major changes to postgres that may complicate using citusdata?

"Databases have always been and will always be the defining piece of any technological stack".

Sorry, I don't see this as true. Databases are no more "defining" of a tech stack than any other part, comms, security, ui, business logic, etc.

You only see it as "defining" if the database is your product. In most cases, the business logic is the defining part of the system, all parts of the tech stack should be replaceable.

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.

Something you need isn't necessarily what defines you. We all need food and water but that's not what defines us -- at least not at the level of abstraction people care about. Google has a ton of databases, etc. but one would hardly call it a database company.

If you're architecting your application around a particular mechanism, be that a db or comms mechanism or whatever, then you're tightly coupled to it. This is a mistake.

Most applications need to store data, but most applications dont need to store data in a particular db.

Taking this attitude to your design is a great way to tank your performance before you've even started. I have seen too many projects suffer from overzealous architecture that treats the database as a persistence layer. Designs that start out trying to abstract away the persistence layer wind up building a complex caching layer.

I agree, I'm not arguing for complete abstractions here, just showing that the fact that you can abstract away the differences means that the db is not a "defining" part of the system.

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?

True. I have no idea (having skimmed the post) why I would choose EdgeDB over any other.

I just saw lots of waffling.

Does EdgeDB support variants[0]? I've always dreamed of a database that did.

[0] e.g. https://reasonml.github.io/docs/en/variant.html

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'
  };

Definitely sounds cool in theory but where's the call to action? There's only a form to sign up for an email update on the home page. Where is the source code? How can I try this now?

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

You must've done some benchmark tests, would it be possible to elaborate on a plethora of different test speeds? Insertions per second, queries per second, calculating sums, etc.

I got an email about this this morning but I have no idea how I got on your email list.

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

If it was me it must have been a long time ago.

"EdgeDB is based on PostgreSQL, and inherits all of its strengths: reliability, ACID compliance, and performance."

So, basically PostgreSQL with a different query language. Can't figure out what problem this is trying to solve.

On the home page it says, it is "relied upon in production by large businesses". Which large business rely upon it?

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 :)

So instead of having an ORM which I control, let’s bake it into the database instead? This seems like a really bad idea.

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.

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.

This is undesirable

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

I see no need for another query language, I don't find using SQL to be that taxing, and I don't find using different tools for different parts of the stack to be a huge hurdle. This feels like it's made for people who have never programmed before and will entice people to use it for that reason. Much like MongoDB it will not work well at a scale of production and will need to be replaced or scaled up to such an extent as to being too costly. Everything about this in undesirable.

I don't think people who have never programmed before are the only ones who would be interested in more consistency and maintainability in their code.

I don't see how letting something I don't control gives better maintainability.

I don’t think it’s possible to determine from a single blogpost that it’ll work poorly in production.

Reply on news.ycombinator.com