6 ms·

Build your next app with a graph database

56 points by fernandogmo 6y ago

OrderlyTiamat 6y ago
I'm sorry, how many different ways are there of saying "you likely think relational databases are good, but they are not" without any substance? I'm up to 6, and no longer interested in the article.
ageitgey 6y ago
This reads more like a sermon than a technical article.
- guepe 6y ago
  I agree. I could not get to the point where author states the advantages of graph database. If author is preaching, then it's not convincing to the audience at stake...
- pantaloony 6y ago
  Shit-talking relational DBs this hard makes me assume all other material in the article is BS, or else the person writing it isn’t very experienced.
- balfirevic 6y ago
  I had to stop and check if it was satire.
plantel 6y ago
I built an app with Neo4j once. It was a Rails app, built it from scratch in Neo4j.rb. I was hired by business where the owner hadn't coded any apps in 15 years and was obsessed with the theory of the graph database and how it was so much "easier" than using SQL. Suddenly, every useful gem that allows you to throw together an app in 5 minutes had to be rewritten from the ground up. Things like authentication, pagination, etc. which could be done in 10 minutes in a standard Rails app took days. The worst part is that I was not permitted to contribute these customs gems back to Open Source. He was a very selfish person who used almost exclusively proprietary software and thought that any of the long hours we spent to rebuild all of these basic puzzle pieces to work with Neo4J would give other people a leg up or advantage - as if competitors out there would decide to build a direct competitor with our identical tech stack and we wanted to slow them down as much as possible... sorry boss, but if they wanted to build a competitor prototype they would just build it with an SQL relational database and have the entire app done in 2 weeks. About 3 months into the project I mentioned to someone at a technology meetup that I was building in app in Neo4j.rb and he laughed at me. I was drinking the graph koolaid still at the time and tried telling him about the advantages. He told me that as soon as the app was deployed I would see how much extra work I would have in-store for me. To be fair, he was right. Migrations just didn't work the same. Eventually I was discharged from the company because I did not agree with the management's unethical business practices and continue doing shady things and agree with their moral jusitifcations for crimes so the app never actually saw the light of day. I am sure there are many production apps succeeding with Neo4j, but in the end I just saw a project whose scope was 10x what it should have been. If you have a "slow" app that launches 3 months earlier than your competitor, you still win.
- pantaloony 6y ago
  I also once got stuck under an org with leadership that’d fallen for N4J’s marketing. It was a bad fit for their needs by most any metric and leading to tons of stability problems, bugs, and development slowness. Hell one application they were developing on it would have been (much) better off with SQLite. Seriously. It was like early Mongodb hype all over again.
znpy 6y ago
It's a shame that almost no one knows or uses Versant OODBMS (object-oriented database management system). As the name suggest it's object oriented and queries return graphs of objects. It's heavily multi-threaded and has been around since 1989 (iirc). The only big downside (besides being proprietary) is that it's almost impossible to scale out (horizontally). But it scales enormously well vertically (throw resources at it and it will happily use it in a very efficient manner).
- p_l 6y ago
  Another case of less known but powerful tool - Allegro Graph. An RDF triple store, with advanced security, and most importantly, on-line materialization and application of schemas/ontologies.
- fractallyte 6y ago
  There's also Gemstone, a proprietary Smalltalk object database (https://gemtalksystems.com/ https://gemtalksystems.com/). You do all your coding within the database, so it really blurs the distinction between data and code. Magma is a rather nice open source Smalltalk database (https://wiki.squeak.org/squeak/2665 https://wiki.squeak.org/squeak/2665), available for Squeak and Pharo.
whalesalad 6y ago
"Relational databases: a software engineering fail" Hard to take this piece seriously with a headline like this.
- travisjungroth 6y ago
  That tech that quietly gives persistence to most of the software of the world: fail.
  - deleted 6y ago
    [deleted]
vikingcaffiene 6y ago
Currently migrating off a graph database and back to a relational one. It's been a bit of a nightmare. I think there are legitimate use cases for the tech. Yours probably isn't it.
- charleskinbote 6y ago
  Could you elaborate?
freehunter 6y ago
I have never used a graph database but I can say there is one truth in the article: I find I have to stop and structure my app around the tables I need, and have had to stop and reorganize my code and data to fit a proper table structure when I realize my existing table structure doesn't make sense or hits the database too hard. I have no idea if graph databases are the answer to that problem, but I do get tired of building code to work around my database and it's oddities rather than my data just fitting nicely into the code. The number of migrations I've built just to change something because the database needed it built differently rather than my application needing it is silly.
- hitpointdrew 6y ago
  You probably just want any NO-SQL database then, not necessarily a Graph DB. MongoDB or Elasticsearch should fit your needs. The thing that is great about relational databases is data integrity, the thing that sucks about relational databases is data integrity. NO-SQL is fantastic, but if you want you data to adhere to ACID then there is simply no substitute for a relational database.
  - LukeEF 6y ago
    Some graph databases, like TerminusDB and others, give strong ACID guarantees and enforce data integrity - you can have the best of all worlds
- nawgszy 6y ago
  Could you say more about some of these times? I'm curious what it means in more concrete terms. I only say this because I am a UI engineer who has been in some scrappy situations, so obviously I don't get to change the data model. What kind of structures do you find that "hit the database too hard" or otherwise invoke performance penalties?
  - freehunter 6y ago
    When I say "hit the database too hard" what I actually mean is making too many calls to the database. If I have to make three or four calls just to get all the data I need, performance is going to take a hit. And databases are often the worst-performing part of the tech stack, so you have to craft your queries around the performance bottleneck of the database. So you have to balance your table structure around getting the data you need in as few calls as possible while also only returning exactly as much data as you need and no more. Because pulling extra data out puts more load on the database and shipping more data across the network is slower. In general, relational databases (RBDs) like Postgres or MySQL are great for making sure your data follows the correct structure (this field is a string, this is an integer, this field in table1 has to be the same as this field in table2, etc) but make it hard to make changes to the data structure later. What happens if that int should actually be a float? Now you have to write a migration that makes fundamental changes to the structure of the data and hope there are no negative side effects. Someone else mentioned NoSQL databases, which offer a lot more flexibility at the cost of the data integrity that RDBs enforce. If you suddenly want to store a float instead of an int, go ahead. No one is stopping you, you just need to make sure your code is updated to handle the possibility of getting back an int or float (or coerce the value to the right type and pray). Basically a database is integral to almost all applications but they're complex monsters with their own structure and rules and performance implications. If you're building an application you really have to know the data structure of the final product before you even _start_ configuring the database.
snicker7 6y ago
Like most tech marketing pieces, this comes across as very absolutist and preachy -- to the point where its hard to take it seriously. The concept of relational databases (and SQL) are not "failures of engineering", they are among few software innovations that have withstood the test of time.
mvitorino 6y ago
"Why you should build your next app with a graph database" Please don't. Graph databases have only a few niche use cases which, even then, in most occasions, can be adequately covered by a relational database.
poorman 6y ago
I think the potential for dgraph is really awesome. After doing a survey of various graph databases, they seem to be well positioned for one that has the ability to scale horizontally. This is not something many of the others have. From what I can tell the others require a single write master. My only gripe with it so far is their documentation could use some updating. The onboarding path isn't real straight forward. I've had to jump around to different parts of the documentation and piece together stuff to get started.
mikeabraham 6y ago
That's like saying, "whatever you're building, you should use a saw to do it." The DB is just a tool. Use the right tool for the job.
wenc 6y ago
I've been looking at Hasura [1] due to the accolades it's gotten on HN. It throws up a GraphQL interface to PostgreSQL. I wonder if anyone can speak to how Hasura's approach compares to designing an architecture around a pure graph database? [1] https://hasura.io/how-hasura-works/ https://hasura.io/how-hasura-works/
- pantaloony 6y ago
  GraphQL isn’t particularly “graphy” nor does it have much to do (necessarily) with graph databases. Its name is, for the reason that it continually generates that sort of confusion, pretty bad.
  - wenc 6y ago
    You're correct -- it's more of a query-language-ish alternative to REST. However, it does let one work with hierarchical data structures that map more closely to the JSONish mental model that most app developers have, rather than with pure SQL tabular data structures which have to be object-mapped. I'd imagine most developers just want that, rather than capabilities for doing relationship/connection queries which real graph databases specialize in.
    - pantaloony 6y ago
      Right—HierarchyQL or NestQL would be a better name, even. I’m not aware of its being much more ergonomic or helpful for graph queries than SQL is. Certainly nothing like Cypher or another actual query language for graphs. Doesn’t mean it’s bad, it just has a misleading name (in fact TFA even seems a bit confused about what it is)
chvid 6y ago
From the article: "Relational databases: a software engineering fail ... That you were taught relational databases at all is an accident. It's simply that they are an early tech that became widely used, so your teacher knows about them, and, importantly, that they are a dream to teach." What. Really?
- deleted 6y ago
  [deleted]
- staticassertion 6y ago
  Is this really so hard to believe? Lots of things that are "Default" are just that way for historic purposes. One example, and I say this as someone who's generally a fan of the language, would be Java - it's taught in so many schools, because it's taught in so many schools. Everyone says things like "You don't need a graphdb" because their default assumption is that there is a cost relative to rdbms, that's the bias of knowing rdbms. The "you don't need X" is one of the most common tropes, I read those words roughly every day on HN. As a user of a graph database I'm quite pleased with the experience. I can model things extremely naturally, and relationships are dead simple to express. Did I need a graph database? No, obviously, I could have used any database, but a graph matched my requirements.
  - jtth 6y ago
    Historical entrenchment is not a chance occurrence.
    - staticassertion 6y ago
      I didn't say it was.
  - AnimalMuppet 6y ago
    There were two lines held up for mocking. The first one described relational DBs as a software engineering fail. That's patently absurd. (If that's failure, what would success look like?) You addressed the second one, which is slightly less absurd. You were taught relational DBs because they are enormously widely used. And why are they used so widely? Because they work. What the article should be saying is, "Here's this approach that works better than relational, and here's how and why it works better." Mocking relational DBs, as if they had been a failure, just makes the authors look clueless.
jacquesm 6y ago
Beware of dgraph 'made for HN' content, it is essentially just an advertisement. See the submission history for this domain: https://news.ycombinator.com/from?site=dgraph.io https://news.ycombinator.com/from?site=dgraph.io
kgraves 6y ago
A lot of words and not a lot of stats on relational DB's vs graph DBs.
the_duke 6y ago
I'm currently on my first project involving a graph database . Dgraph coincidentally, and I somewhat like the product. But this is a horrible article that would immediately leave a bad taste in my mouth if I were researching the product. It boils down to a shallow dismissal of relational databases that does not have much more substance than "Relational dbs are old and bad! Graphs are awesome because relations and queries!". Graph databases are often immature, don't enforce schemas, have little tooling, poorly understood or hard to tune performance characteristics, are somewhat messy when it comes to query languages (OpenCipher? weird GraphQL dialect? homegrown solution X?). The list goes on. A colleague who is an expert in this domain recommended to use (current) graph DBs only if you care more about the are relationships than the data. And probably only for data that you can lose, eg as a secondary storage. Criticizing the relative awkwardness of relations in relational DBs is valid, and has both historical and practical reasons. But the author wrote it himself: relational DBs are the first choice for developers. Not by accident, or because the internet told me to. But because they are excellent, mature, well understood, versatile products that can handle most of a regular applications requirements very well. No, you should not throw away every database and write all your future applications with DGraph. You may investigate if a graph database fits your specific use case, if the product is mature enough to rely on it, and if the added complexity (from devs to ops) is worth it. Vendors should promote the strength of their products, but also be clear about when it might not be a good fit. This kind of writing does not inspire trust in the quality of DGraph, rather the opposite.
- madrox 6y ago
  I'm pleased to hear so many comments saying this. I don't think this style of writing is appropriate for engineering. This is computer science, and even in marketing posts like this one we should be reading analysis of performance benchmarks along with pros and cons. I'm immediately skeptical of technology that takes this marketing approach.
  - it 6y ago
    He did show concrete examples of how relational DBMSs force you to model and query in an unintuitive way.
Dowwie 6y ago
OP claims that the relational database is a software engineering fail. If anything, it's one of the longest run successes-- 50 years?
lol666 6y ago
i liked it, but i do work with bigger data sets... make it easy? orm... if its active record or even datamapper just try throwing 100k new rows in a table every day, and then the joins... bah, skip the orm and start working with any sets that add couple hundres of thousands rows every day and you will very quickly see the aches of using sql... and the price of hardware you need to run it smoothly... and then if they related and youre using locks... probably a lot ppl have same feelings as me
lol666 6y ago
in shortcut im gonna try it, thank you for art :) i will treat what u say is shaming as effect of frustration of someone who needed to work with tech that wasnt great for the needs
wayneftw 6y ago
I learned basic SQL in a few weeks in my twenties. The knowledge of it lasted me 2 decades. I regularly learn new technologies and I can use them immediately. Things like ELK (ElasticSearch), React, Golang, modern JS. For some reason, trying to learn DGraph and graph databases in general has always been very difficult for me. I wanted to like them, but just about everything I want to do can be done more easily with a relational database. And RDBMS tools mostly just work. Setting up DGraph was a freaking nightmare. I think you need a minimum of 3 Docker containers to run it and I'm not even sure what each container is actually responsible for. If they want people to use this, I think DGraph should make their stuff easier to use and give us some better tools.
nick_ 6y ago
Cool to see the general shift back to relational databases. Back at peak graph DB hype I felt like a crazy person reading all these comments about how amazing graph and key-value stores were.
FpUser 6y ago
I have nothing against graph database concept. I used it myself in some server applications. But reading this article: >"Relational databases: a software engineering fail" I would tell this to the author: it is a bad marketing strategy trying to diminish competitor. Don't worry about relational databases. With the comment like in the quote it is clear that you are either incompetent or spreading BS on purpose. Not all of your audience are single cell organisms and they are perfectly able to judge claims on merits rather than propaganda.
thelazydogsback 6y ago
The OP also misses the point that rather than modeling the 1:n relationship as he describes ("backwards" from the Comment to the Card) one could have a separate [Card.Comments] table that maps comments to and from cards (in either direction if so indexed) -- in other words, you could model the relationship directly and implements a graphDB w/your RDBMS. This allows one to add/remove relationships while leaving the data, to reference/reify the relationship, etc. Easy enough to create your own client-side query pre-processor or stored-procs to make queries easier of this graph if you desire.
jexp 6y ago
Not sure why, but the blog post in question (same URL), has been sneakily replaced with one replacing "graph database" with "GraphQL" in the title. And changing the tagline on relational database from "Relational databases: a software engineering fail" to "Relational databases: engineering success is not always the best software engineering fit" https://dgraph.io/blog/post/graphdb-for-your-next-app/ https://dgraph.io/blog/post/graphdb-for-your-next-app/ Fortunately internet archive still has the previous version, that the comments here were discussing. https://web.archive.org/web/20200709192510/https://dgraph.io/blog/post/graphdb-for-your-next-app/ https://web.archive.org/web/20200709192510/https://dgraph.io...

56 points by fernandogmo 6y ago

I'm sorry, how many different ways are there of saying "you likely think relational databases are good, but they are not" without any substance? I'm up to 6, and no longer interested in the article.

ageitgey 6y ago

This reads more like a sermon than a technical article.

guepe 6y ago
I agree. I could not get to the point where author states the advantages of graph database. If author is preaching, then it's not convincing to the audience at stake...
pantaloony 6y ago
Shit-talking relational DBs this hard makes me assume all other material in the article is BS, or else the person writing it isn’t very experienced.
balfirevic 6y ago
I had to stop and check if it was satire.

plantel 6y ago

I built an app with Neo4j once. It was a Rails app, built it from scratch in Neo4j.rb. I was hired by business where the owner hadn't coded any apps in 15 years and was obsessed with the theory of the graph database and how it was so much "easier" than using SQL. Suddenly, every useful gem that allows you to throw together an app in 5 minutes had to be rewritten from the ground up. Things like authentication, pagination, etc. which could be done in 10 minutes in a standard Rails app took days. The worst part is that I was not permitted to contribute these customs gems back to Open Source. He was a very selfish person who used almost exclusively proprietary software and thought that any of the long hours we spent to rebuild all of these basic puzzle pieces to work with Neo4J would give other people a leg up or advantage - as if competitors out there would decide to build a direct competitor with our identical tech stack and we wanted to slow them down as much as possible... sorry boss, but if they wanted to build a competitor prototype they would just build it with an SQL relational database and have the entire app done in 2 weeks. About 3 months into the project I mentioned to someone at a technology meetup that I was building in app in Neo4j.rb and he laughed at me. I was drinking the graph koolaid still at the time and tried telling him about the advantages. He told me that as soon as the app was deployed I would see how much extra work I would have in-store for me. To be fair, he was right. Migrations just didn't work the same. Eventually I was discharged from the company because I did not agree with the management's unethical business practices and continue doing shady things and agree with their moral jusitifcations for crimes so the app never actually saw the light of day. I am sure there are many production apps succeeding with Neo4j, but in the end I just saw a project whose scope was 10x what it should have been. If you have a "slow" app that launches 3 months earlier than your competitor, you still win.

pantaloony 6y ago
I also once got stuck under an org with leadership that’d fallen for N4J’s marketing. It was a bad fit for their needs by most any metric and leading to tons of stability problems, bugs, and development slowness. Hell one application they were developing on it would have been (much) better off with SQLite. Seriously. It was like early Mongodb hype all over again.

znpy 6y ago

It's a shame that almost no one knows or uses Versant OODBMS (object-oriented database management system). As the name suggest it's object oriented and queries return graphs of objects. It's heavily multi-threaded and has been around since 1989 (iirc). The only big downside (besides being proprietary) is that it's almost impossible to scale out (horizontally). But it scales enormously well vertically (throw resources at it and it will happily use it in a very efficient manner).

p_l 6y ago
Another case of less known but powerful tool - Allegro Graph. An RDF triple store, with advanced security, and most importantly, on-line materialization and application of schemas/ontologies.
fractallyte 6y ago
There's also Gemstone, a proprietary Smalltalk object database (https://gemtalksystems.com/ https://gemtalksystems.com/). You do all your coding within the database, so it really blurs the distinction between data and code. Magma is a rather nice open source Smalltalk database (https://wiki.squeak.org/squeak/2665 https://wiki.squeak.org/squeak/2665), available for Squeak and Pharo.

whalesalad 6y ago

"Relational databases: a software engineering fail" Hard to take this piece seriously with a headline like this.

travisjungroth 6y ago
That tech that quietly gives persistence to most of the software of the world: fail.
- deleted 6y ago
  [deleted]

vikingcaffiene 6y ago

Currently migrating off a graph database and back to a relational one. It's been a bit of a nightmare. I think there are legitimate use cases for the tech. Yours probably isn't it.

charleskinbote 6y ago
Could you elaborate?

freehunter 6y ago

I have never used a graph database but I can say there is one truth in the article: I find I have to stop and structure my app around the tables I need, and have had to stop and reorganize my code and data to fit a proper table structure when I realize my existing table structure doesn't make sense or hits the database too hard. I have no idea if graph databases are the answer to that problem, but I do get tired of building code to work around my database and it's oddities rather than my data just fitting nicely into the code. The number of migrations I've built just to change something because the database needed it built differently rather than my application needing it is silly.

hitpointdrew 6y ago
You probably just want any NO-SQL database then, not necessarily a Graph DB. MongoDB or Elasticsearch should fit your needs. The thing that is great about relational databases is data integrity, the thing that sucks about relational databases is data integrity. NO-SQL is fantastic, but if you want you data to adhere to ACID then there is simply no substitute for a relational database.
- LukeEF 6y ago
  Some graph databases, like TerminusDB and others, give strong ACID guarantees and enforce data integrity - you can have the best of all worlds
nawgszy 6y ago
Could you say more about some of these times? I'm curious what it means in more concrete terms. I only say this because I am a UI engineer who has been in some scrappy situations, so obviously I don't get to change the data model. What kind of structures do you find that "hit the database too hard" or otherwise invoke performance penalties?
- freehunter 6y ago
  When I say "hit the database too hard" what I actually mean is making too many calls to the database. If I have to make three or four calls just to get all the data I need, performance is going to take a hit. And databases are often the worst-performing part of the tech stack, so you have to craft your queries around the performance bottleneck of the database. So you have to balance your table structure around getting the data you need in as few calls as possible while also only returning exactly as much data as you need and no more. Because pulling extra data out puts more load on the database and shipping more data across the network is slower. In general, relational databases (RBDs) like Postgres or MySQL are great for making sure your data follows the correct structure (this field is a string, this is an integer, this field in table1 has to be the same as this field in table2, etc) but make it hard to make changes to the data structure later. What happens if that int should actually be a float? Now you have to write a migration that makes fundamental changes to the structure of the data and hope there are no negative side effects. Someone else mentioned NoSQL databases, which offer a lot more flexibility at the cost of the data integrity that RDBs enforce. If you suddenly want to store a float instead of an int, go ahead. No one is stopping you, you just need to make sure your code is updated to handle the possibility of getting back an int or float (or coerce the value to the right type and pray). Basically a database is integral to almost all applications but they're complex monsters with their own structure and rules and performance implications. If you're building an application you really have to know the data structure of the final product before you even _start_ configuring the database.

snicker7 6y ago

Like most tech marketing pieces, this comes across as very absolutist and preachy -- to the point where its hard to take it seriously. The concept of relational databases (and SQL) are not "failures of engineering", they are among few software innovations that have withstood the test of time.

mvitorino 6y ago

"Why you should build your next app with a graph database" Please don't. Graph databases have only a few niche use cases which, even then, in most occasions, can be adequately covered by a relational database.

poorman 6y ago

I think the potential for dgraph is really awesome. After doing a survey of various graph databases, they seem to be well positioned for one that has the ability to scale horizontally. This is not something many of the others have. From what I can tell the others require a single write master. My only gripe with it so far is their documentation could use some updating. The onboarding path isn't real straight forward. I've had to jump around to different parts of the documentation and piece together stuff to get started.

mikeabraham 6y ago

That's like saying, "whatever you're building, you should use a saw to do it." The DB is just a tool. Use the right tool for the job.

wenc 6y ago

I've been looking at Hasura [1] due to the accolades it's gotten on HN. It throws up a GraphQL interface to PostgreSQL. I wonder if anyone can speak to how Hasura's approach compares to designing an architecture around a pure graph database? [1] https://hasura.io/how-hasura-works/ https://hasura.io/how-hasura-works/

pantaloony 6y ago
GraphQL isn’t particularly “graphy” nor does it have much to do (necessarily) with graph databases. Its name is, for the reason that it continually generates that sort of confusion, pretty bad.
- wenc 6y ago
  You're correct -- it's more of a query-language-ish alternative to REST. However, it does let one work with hierarchical data structures that map more closely to the JSONish mental model that most app developers have, rather than with pure SQL tabular data structures which have to be object-mapped. I'd imagine most developers just want that, rather than capabilities for doing relationship/connection queries which real graph databases specialize in.
  - pantaloony 6y ago
    Right—HierarchyQL or NestQL would be a better name, even. I’m not aware of its being much more ergonomic or helpful for graph queries than SQL is. Certainly nothing like Cypher or another actual query language for graphs. Doesn’t mean it’s bad, it just has a misleading name (in fact TFA even seems a bit confused about what it is)

chvid 6y ago

From the article: "Relational databases: a software engineering fail ... That you were taught relational databases at all is an accident. It's simply that they are an early tech that became widely used, so your teacher knows about them, and, importantly, that they are a dream to teach." What. Really?

deleted 6y ago
[deleted]
staticassertion 6y ago
Is this really so hard to believe? Lots of things that are "Default" are just that way for historic purposes. One example, and I say this as someone who's generally a fan of the language, would be Java - it's taught in so many schools, because it's taught in so many schools. Everyone says things like "You don't need a graphdb" because their default assumption is that there is a cost relative to rdbms, that's the bias of knowing rdbms. The "you don't need X" is one of the most common tropes, I read those words roughly every day on HN. As a user of a graph database I'm quite pleased with the experience. I can model things extremely naturally, and relationships are dead simple to express. Did I need a graph database? No, obviously, I could have used any database, but a graph matched my requirements.
- jtth 6y ago
  Historical entrenchment is not a chance occurrence.
  - staticassertion 6y ago
    I didn't say it was.
- AnimalMuppet 6y ago
  There were two lines held up for mocking. The first one described relational DBs as a software engineering fail. That's patently absurd. (If that's failure, what would success look like?) You addressed the second one, which is slightly less absurd. You were taught relational DBs because they are enormously widely used. And why are they used so widely? Because they work. What the article should be saying is, "Here's this approach that works better than relational, and here's how and why it works better." Mocking relational DBs, as if they had been a failure, just makes the authors look clueless.

jacquesm 6y ago

Beware of dgraph 'made for HN' content, it is essentially just an advertisement. See the submission history for this domain: https://news.ycombinator.com/from?site=dgraph.io https://news.ycombinator.com/from?site=dgraph.io

kgraves 6y ago

A lot of words and not a lot of stats on relational DB's vs graph DBs.

the_duke 6y ago

I'm currently on my first project involving a graph database . Dgraph coincidentally, and I somewhat like the product. But this is a horrible article that would immediately leave a bad taste in my mouth if I were researching the product. It boils down to a shallow dismissal of relational databases that does not have much more substance than "Relational dbs are old and bad! Graphs are awesome because relations and queries!". Graph databases are often immature, don't enforce schemas, have little tooling, poorly understood or hard to tune performance characteristics, are somewhat messy when it comes to query languages (OpenCipher? weird GraphQL dialect? homegrown solution X?). The list goes on. A colleague who is an expert in this domain recommended to use (current) graph DBs only if you care more about the are relationships than the data. And probably only for data that you can lose, eg as a secondary storage. Criticizing the relative awkwardness of relations in relational DBs is valid, and has both historical and practical reasons. But the author wrote it himself: relational DBs are the first choice for developers. Not by accident, or because the internet told me to. But because they are excellent, mature, well understood, versatile products that can handle most of a regular applications requirements very well. No, you should not throw away every database and write all your future applications with DGraph. You may investigate if a graph database fits your specific use case, if the product is mature enough to rely on it, and if the added complexity (from devs to ops) is worth it. Vendors should promote the strength of their products, but also be clear about when it might not be a good fit. This kind of writing does not inspire trust in the quality of DGraph, rather the opposite.

madrox 6y ago
I'm pleased to hear so many comments saying this. I don't think this style of writing is appropriate for engineering. This is computer science, and even in marketing posts like this one we should be reading analysis of performance benchmarks along with pros and cons. I'm immediately skeptical of technology that takes this marketing approach.
- it 6y ago
  He did show concrete examples of how relational DBMSs force you to model and query in an unintuitive way.

Dowwie 6y ago

OP claims that the relational database is a software engineering fail. If anything, it's one of the longest run successes-- 50 years?

lol666 6y ago

i liked it, but i do work with bigger data sets... make it easy? orm... if its active record or even datamapper just try throwing 100k new rows in a table every day, and then the joins... bah, skip the orm and start working with any sets that add couple hundres of thousands rows every day and you will very quickly see the aches of using sql... and the price of hardware you need to run it smoothly... and then if they related and youre using locks... probably a lot ppl have same feelings as me

lol666 6y ago

in shortcut im gonna try it, thank you for art :) i will treat what u say is shaming as effect of frustration of someone who needed to work with tech that wasnt great for the needs

wayneftw 6y ago

I learned basic SQL in a few weeks in my twenties. The knowledge of it lasted me 2 decades. I regularly learn new technologies and I can use them immediately. Things like ELK (ElasticSearch), React, Golang, modern JS. For some reason, trying to learn DGraph and graph databases in general has always been very difficult for me. I wanted to like them, but just about everything I want to do can be done more easily with a relational database. And RDBMS tools mostly just work. Setting up DGraph was a freaking nightmare. I think you need a minimum of 3 Docker containers to run it and I'm not even sure what each container is actually responsible for. If they want people to use this, I think DGraph should make their stuff easier to use and give us some better tools.

nick_ 6y ago

Cool to see the general shift back to relational databases. Back at peak graph DB hype I felt like a crazy person reading all these comments about how amazing graph and key-value stores were.

FpUser 6y ago

I have nothing against graph database concept. I used it myself in some server applications. But reading this article: >"Relational databases: a software engineering fail" I would tell this to the author: it is a bad marketing strategy trying to diminish competitor. Don't worry about relational databases. With the comment like in the quote it is clear that you are either incompetent or spreading BS on purpose. Not all of your audience are single cell organisms and they are perfectly able to judge claims on merits rather than propaganda.

thelazydogsback 6y ago

The OP also misses the point that rather than modeling the 1:n relationship as he describes ("backwards" from the Comment to the Card) one could have a separate [Card.Comments] table that maps comments to and from cards (in either direction if so indexed) -- in other words, you could model the relationship directly and implements a graphDB w/your RDBMS. This allows one to add/remove relationships while leaving the data, to reference/reify the relationship, etc. Easy enough to create your own client-side query pre-processor or stored-procs to make queries easier of this graph if you desire.

jexp 6y ago

Not sure why, but the blog post in question (same URL), has been sneakily replaced with one replacing "graph database" with "GraphQL" in the title. And changing the tagline on relational database from "Relational databases: a software engineering fail" to "Relational databases: engineering success is not always the best software engineering fit" https://dgraph.io/blog/post/graphdb-for-your-next-app/ https://dgraph.io/blog/post/graphdb-for-your-next-app/ Fortunately internet archive still has the previous version, that the comments here were discussing. https://web.archive.org/web/20200709192510/https://dgraph.io/blog/post/graphdb-for-your-next-app/ https://web.archive.org/web/20200709192510/https://dgraph.io...