5 ms·

As others have said, graph databases push foreign keys, joins, referential integrity, and migrations to the application layer. Right now the combinations of dat

As others have said, graph databases push foreign keys, joins, referential integrity, and migrations to the application layer. Right now the combinations of databases and software just can’t handle that with nearly the sophistication of Postgres + an open source ORM. Facebook famously uses a graph database called TAO [1] with an ORM called Ent sitting on top of it. Everything lives on that - internal and external applications. Every dev at FB writing backend code uses it. Can’t talk too much and how these work since they’re internal and proprietary, but looks like we open sourced a Go ORM that’s Ent-inspired that shows the basics [2]. It’s definitely a weird mental model to get used to, but the combination of deep business logic in schema definitions, complex joins, and insane query performance make it super powerful. We’re definitely one of the bigger non-SQL shops, with thousands of developers using this every day as their primary data store. [1] https://engineering.fb.com/2013/06/25/core-data/tao-the-power-of-the-graph/ https://engineering.fb.com/2013/06/25/core-data/tao-the-powe... [2] https://entgo.io/docs/getting-started/ https://entgo.io/docs/getting-started/

eurasiantiger 5y ago
> graph databases push foreign keys, joins, referential integrity, and migrations to the application layer All graph databases? With just a bit of googling I can find ones that support migrations through ETL with foreign keys translated to edges at that point, and claim to have transactions with immediate consistency—even some claiming ACID. Joins are not even a thing in graph databases; being able to directly query across edges obviates the entire concept.
- j-pb 5y ago
  > Joins are not even a thing in graph databases; being able to directly query across edges obviates the entire concept. Nah, you do need joins if you don't only want to walk the graph from some well known roots. E.g. queries about properties of connected subgraphs
  - Scarbutt 5y ago
    Nah, you do need joins if you don't only want to walk the graph from some well known roots. E.g. queries about properties of connected subgraphs In an graphdb the engine would deduct that by the way of the query language (no explicit joins).
    - j-pb 5y ago
      Yes, and then do a join ;) I'm not arguing for explicit joins, which are an artifact of SQL and not even the relational model e.g. Datalog as a explicit join free relational language.
  - eurasiantiger 5y ago
    O(1) traversal, and filtering edges is more intuitive than joining.
    - j-pb 5y ago
      And also not O(1) nor intuitive for any non trivial query. You don't need to have an explicit `JOIN` operator in your language, but any query that goes beyond unconditional tree walking will benefit from using joins under the hood.
      - eurasiantiger 5y ago
        Depends on what’s under the hood, though. A lot of these seem to be document or columnar stores.
        j-pb 5y ago
        Well, still. Columnar and document stores still profit from performing joins under their hood. Whenever you are combining two partial query results into a coherent whole answer you need to perform some form of join. For example you could view a MongoDB map-reduce step with a subquery as a naive indexless scan join.
- jandrewrogers 5y ago
  > Joins are not even a thing in graph databases; being able to directly query across edges obviates the entire concept. Joins are the central thing in graph databases, even if you don't think of it in those terms or materialize some of the join operations. Being able to directly query across edges is a logical operation, it doesn't imply the underlying implementation. While the simple "node/edge" model in memory seems easy, it also has pathologically poor locality so most graph databases use less direct representations (traversed with join operations under the hood) with much higher average performance.
  - eurasiantiger 5y ago
    You could make the same argument for any columnar store. Getting fields from one is fast, though, independent of the table they belong to. Joining together row-based tables has more moving parts and much more runtime cost.
chakkepolja 5y ago
> graph databases push foreign keys, joins, referential integrity, and migrations to the application layer. This isn't a fundamental limitation right?
- convolvatron 5y ago
  no. not at all. this whole discussion is really about marketing terms. there is absolutely no reason why one can't apply relational operators to graphs. its just that sql doesn't normally support cyclic evaluation. that's really only the only fundamental difference in a 'graph database' that said, recursion is really handy and SQL is a really crap environment for doing anything but the most basic of evaluations.

eurasiantiger 5y ago

> graph databases push foreign keys, joins, referential integrity, and migrations to the application layer All graph databases? With just a bit of googling I can find ones that support migrations through ETL with foreign keys translated to edges at that point, and claim to have transactions with immediate consistency—even some claiming ACID. Joins are not even a thing in graph databases; being able to directly query across edges obviates the entire concept.

j-pb 5y ago
> Joins are not even a thing in graph databases; being able to directly query across edges obviates the entire concept. Nah, you do need joins if you don't only want to walk the graph from some well known roots. E.g. queries about properties of connected subgraphs
- Scarbutt 5y ago
  Nah, you do need joins if you don't only want to walk the graph from some well known roots. E.g. queries about properties of connected subgraphs In an graphdb the engine would deduct that by the way of the query language (no explicit joins).
  - j-pb 5y ago
    Yes, and then do a join ;) I'm not arguing for explicit joins, which are an artifact of SQL and not even the relational model e.g. Datalog as a explicit join free relational language.
- eurasiantiger 5y ago
  O(1) traversal, and filtering edges is more intuitive than joining.
  - j-pb 5y ago
    And also not O(1) nor intuitive for any non trivial query. You don't need to have an explicit `JOIN` operator in your language, but any query that goes beyond unconditional tree walking will benefit from using joins under the hood.
    - eurasiantiger 5y ago
      Depends on what’s under the hood, though. A lot of these seem to be document or columnar stores.
      - j-pb 5y ago
        Well, still. Columnar and document stores still profit from performing joins under their hood. Whenever you are combining two partial query results into a coherent whole answer you need to perform some form of join. For example you could view a MongoDB map-reduce step with a subquery as a naive indexless scan join.
jandrewrogers 5y ago
> Joins are not even a thing in graph databases; being able to directly query across edges obviates the entire concept. Joins are the central thing in graph databases, even if you don't think of it in those terms or materialize some of the join operations. Being able to directly query across edges is a logical operation, it doesn't imply the underlying implementation. While the simple "node/edge" model in memory seems easy, it also has pathologically poor locality so most graph databases use less direct representations (traversed with join operations under the hood) with much higher average performance.
- eurasiantiger 5y ago
  You could make the same argument for any columnar store. Getting fields from one is fast, though, independent of the table they belong to. Joining together row-based tables has more moving parts and much more runtime cost.

chakkepolja 5y ago

> graph databases push foreign keys, joins, referential integrity, and migrations to the application layer. This isn't a fundamental limitation right?

convolvatron 5y ago
no. not at all. this whole discussion is really about marketing terms. there is absolutely no reason why one can't apply relational operators to graphs. its just that sql doesn't normally support cyclic evaluation. that's really only the only fundamental difference in a 'graph database' that said, recursion is really handy and SQL is a really crap environment for doing anything but the most basic of evaluations.