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.
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 the section where you criticize graph is unfair.
1. All databases can be immature.
2. There is a whole world of graph DBs where strong schema support is the cornerstone of the system (TerminusDB, Stardog etc.).
3. Some relational Dbs have little tooling - Neo4j, as the oldest and most successful graph, has way more tooling than johnny newcomer RDBMS
4. performance characteristics are hard. That is not a necessary feature of graph.
5. Query languages - so you are saying only SQL will do? Lots of graph DBs use datalog or a variant (Datomic, TerminusDB, Opencrux). It is a well understood, powerful and composable approach to query. Yes, some query languages have flaws, but we should be open to doing better on query.
SQL fundamentalism is wrong.
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.
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.
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?
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.
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.
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.
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.
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.
"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."
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.
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.
Readit News
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.
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.
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.
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?
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.
Hard to take this piece seriously with a headline like this.
Deleted Comment
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.
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.
"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 Comment
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.
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.