7 ms·
EdgeDB: A New Beginning
- perfmode 9y agoI understand the desire to distance oneself from the term graph database, but this is a graph database.
- JanSt 9y agoIt’s definetly not a graph database, if it‘s based on postgresql - no index free adjecency as provided by real graphdbs like neo4j
- eigen-vector 9y agoI 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.
- andrioni 9y agoIt 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.
- martin-adams 9y agoI 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.
- riku_iki 9y agoGraph database operates on Nodes and Edges between Nodes. Object Database operates on objects with fields. EdgeDB looks more like object database.
- johnhenry 9y ago> 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?
- rankam 9y agoWhy do you believe there should be a desire to distance oneself from a graph database? Graph databases are great when used correctly.
- 1st1 9y agoWe don't want to distance EdgeDB from graph databases. We just want to clearly show the difference between EdgeDB and, for example, neo4j.
- jessep 9y agoIt 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.
- threepipeproblm 9y agoIf 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/ 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.
- 1st1 9y agoredcrowbar (Elvis) and I (Yury) are the authors of the post. Happy to answer questions ;)
- JanSt 9y agoWhat are your future plans? Which license?
- 1st1 9y agoWe'll soon offer a public preview of the database. The license will likely be some form of GPL.
- elviejo 9y agoWhat are the difference between EdgeDB and http://www.matisse.com http://www.matisse.com ?
- RedCrowbar 9y agoMatisse 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).
- XR0CSWV3h3kZWg 9y agoETA for release? License? Given it's based off of postgres, whats the story look like for sharding/scaling?
- zzzcpan 9y ago> 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.
- 9y ago
- slaymaker1907 9y agoSo instead of having an ORM which I control, let’s bake it into the database instead? This seems like a really bad idea.
- riku_iki 9y agoIn 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.
- 1st1 9y agoEdgeDB 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.
- tuccinator 9y agoYou 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.
- TickleSteve 9y ago"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.
- tuccinator 9y agoI 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.
- hangonhn 9y agoSomething 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.
- TickleSteve 9y agoIf 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.
- fusiongyro 9y agoTaking 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.
- zzzcpan 9y 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.
- senoroink 9y agoDefinitely 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?
- 1st1 9y agoThanks for the interest! We'll release a technology preview (along with the source code) in just a few weeks.
- Arzh 9y agoThis is undesirable
- ovao 9y agoYour comment doesn’t have any substance. For what reason do you think it’s undesirable?
- Arzh 9y agoI 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.
- ziftface 9y agoI 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.
- Arzh 9y agoI don't see how letting something I don't control gives better maintainability.
- ovao 9y agoI don’t think it’s possible to determine from a single blogpost that it’ll work poorly in production.
- simplify 9y agoDoes EdgeDB support variants[0]? I've always dreamed of a database that did. [0] e.g. https://reasonml.github.io/docs/en/variant.html https://reasonml.github.io/docs/en/variant.html
- RedCrowbar 9y agoIn 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' };
- laszlokorte 9y agoI 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.
- 1st1 9y agoYes, 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.
- oneweekwonder 9y agoHave 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 https://github.com/json-editor/json-editor [1]: https://github.com/swagger-api/swagger-editor/tree/2.x https://github.com/swagger-api/swagger-editor/tree/2.x [3]: https://github.com/swagger-api/swagger-codegen/ https://github.com/swagger-api/swagger-codegen/
- zawerf 9y agoI 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#automatic-relation-detection https://github.com/graphile/postgraphile/tree/postgraphile#a...
- quizotic 9y agoWell ... 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.
- RedCrowbar 9y agoThe [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.
- RedCrowbar 9y ago> 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.
- quizotic 9y agoGlad 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?
- jessep 9y agoOn the home page it says, it is "relied upon in production by large businesses". Which large business rely upon it?
- 1st1 9y agoWe 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 :)
- jazoom 9y agoI got an email about this this morning but I have no idea how I got on your email list.