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...
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.
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).
There's also Gemstone, a proprietary Smalltalk object database (https://gemtalksystems.com/). You do all your coding within the database, so it really blurs the distinction between data and code.
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.
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.
> 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.
This is often stated, but it's not true. RDBMS make it easier to make changes to the data structure precisely because you only have to write migration and after that you are guaranteed to only ever get the data out of database in the new format. Which means your application code doesn't accumulate the cruft of dealing with two possible database data formats.
I strongly disagree that this pattern makes it easier to make changes. It makes it easier to use the data (because you know this data will always be this type), but changing the data is harder than if it did not enforce a type.
I'm not arguing that un-typed data in a DB is easy to use or a good idea, just that it's harder to change the structure of RDBMS if you didn't plan properly from the beginning.
Basically: I think data is hard and I wish there were better tools for interacting with it.
Well, this was maybe a bit entry level description.
Q: "databases are often the worst-performing part of the tech stack" - compared to what? nginx throughput? I find this to be a bit of a strange view, surely business logic is always the slowest part of the tech stack
Q: "What happens if that int should actually be a float?" - how often do you actually need to run migrations versus just extending the data? From my end, I have a small idempotent database schema-maintaining tool, and if I need a new column or a new table there's no need for a migration, and you know your whole stack will interact with the new schema or old schema identically assuming you set sane defaults etc. I've built a lot of medium-quality low-traffic apps so I'm yet to encounter a real-world case where a migration wasn't just bad planning
>I'm yet to encounter a real-world case where a migration wasn't just bad planning
That's basically the root of the issue. Poor planning in your code means you re-write some code. Poor planning in your database means you have to start restructuring data, and if it's already running in production you have to hope you don't accidentally corrupt production data. It's a lot harder to restore corrupted data in production than it is to roll back a code deployment. And the answer to the problem is obviously just spending more time thinking about the proper data structure, which is the entirety of my complaint: I want my data to fit my application, I don't want to have to write my application to fit my data. I don't want to have to think "does this field belong in the Users table or the Accounts table or the [insert table here]".
I'm not sure what you mean by "just extending the data"... if I'm writing a Rails app and I need to change an int to a float, the way I do that is by writing and executing a migration.
As for the speed... a database typically stores its data on disk and is often not hosted on the same physical machine as the web server. Meanwhile the app and web server store a lot of things in-memory on the local server and even when it has to read from disk, it's a local disk attached to that machine. Check these numbers for how long it takes to read from memory (or even local disk) versus reading a remote disk over the network: https://gist.github.com/jboner/2841832
> >If it's already running in production you have to hope you don't accidentally corrupt production data
Or you write use a read replica to transform your data into a non-live DB and validate it before you put it into production, with backups of your final old schema available? Plus I really don't think a migration is that hard. Much harder than having a litany of shitty backends you have to glue together in your front-end app, trust me as someone who's done both.
I mean, I hear you, persisting data is hard, but that's not the database's fault, it's because you pick two of three on data: performance, persistence, and flexibility
> a database typically
But that's not the "worst performing" part of the stack, that's the highest latency part of the stack. Is there some specific reason you can not have co-located web & db servers? Also, is there a reason you still reference 2012 disk numbers when SSDs clearly have reduced all "disk" operations by an order of magnitude?
> just extending the data
What I mean by this is if you start with a minimal amount of columns in your database, and someone is like "we need new property x", it's easy to add X outside a migration - adding new columns or new tables does not require migrations if you don't modify existing columns
So this is my approach. Use as few bits as possible to persist your data, and then you can generally add new features migration-free
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.
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.
"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.
Yes, I only addressed the part I agreed with. I'm not the author or trying to defend the entire article, just saying that I strongly agree with entrenched technologies being entrenched for very weak reasons. Do I think relational databases have no merit? IDK, probably not, though I haven't chosen to use one in a very long time.
Well... entrenched technologies can be entrenched for very weak (or, if you prefer, path-dependent) reasons, over other technologies that are approximately as good. I'm not sure that lesser technology gets entrenched against clearly superior technology very often. (I mean, there's COBOL...)
Graph databases may be as good as relational DBs. They may be better for some use cases. Are they significantly better for many (say, the majority) of use cases? No? Well then, it's really not an issue that they're what became entrenched, is it?
(And if your answer was "yes" instead of "no": That takes some evidence to believe. And the way this article was written leads me to think that they don't actually have any such evidence.)
I think the problem is that we have a very weak understanding of "better" or "worse" or "use cases". What would a better database look like? Maybe it's faster, or more stable, etc. But if what makes it better is that it is a better model, you end up with religious wars - it's the same reason why no one can really agree on whether a static or dynamic language will lead to "better" code, it's just too hard to tell.
As a user of KV stores and graphdbs myself I would have to use a traditional rdbms. It's been an absolute breath of fresh air being able to express queries in a graph-oriented way. For me the combination has been totally "better", but of course, that's not evidence based! Nor, really, could it be.
> As a user of KV stores and graphdbs myself I would have to use a traditional rdbms. It's been an absolute breath of fresh air being able to express queries in a graph-oriented way. For me the combination has been totally "better", but of course, that's not evidence based! Nor, really, could it be.
Well, it's anecdote. But if a statistically-significant number of people feel that it's "an absolute breath of fresh air", that's totally "better" in a very concrete sense.
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.
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.
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)
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 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
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
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.
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.
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.
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.
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"
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.
57 comments
[ 0.17 ms ] story [ 134 ms ] threadSuddenly, 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.
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).
An RDF triple store, with advanced security, and most importantly, on-line materialization and application of schemas/ontologies.
Magma is a rather nice open source Smalltalk database (https://wiki.squeak.org/squeak/2665), available for Squeak and Pharo.
Hard to take this piece seriously with a headline like this.
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.
This is often stated, but it's not true. RDBMS make it easier to make changes to the data structure precisely because you only have to write migration and after that you are guaranteed to only ever get the data out of database in the new format. Which means your application code doesn't accumulate the cruft of dealing with two possible database data formats.
I'm not arguing that un-typed data in a DB is easy to use or a good idea, just that it's harder to change the structure of RDBMS if you didn't plan properly from the beginning.
Basically: I think data is hard and I wish there were better tools for interacting with it.
Q: "databases are often the worst-performing part of the tech stack" - compared to what? nginx throughput? I find this to be a bit of a strange view, surely business logic is always the slowest part of the tech stack
Q: "What happens if that int should actually be a float?" - how often do you actually need to run migrations versus just extending the data? From my end, I have a small idempotent database schema-maintaining tool, and if I need a new column or a new table there's no need for a migration, and you know your whole stack will interact with the new schema or old schema identically assuming you set sane defaults etc. I've built a lot of medium-quality low-traffic apps so I'm yet to encounter a real-world case where a migration wasn't just bad planning
That's basically the root of the issue. Poor planning in your code means you re-write some code. Poor planning in your database means you have to start restructuring data, and if it's already running in production you have to hope you don't accidentally corrupt production data. It's a lot harder to restore corrupted data in production than it is to roll back a code deployment. And the answer to the problem is obviously just spending more time thinking about the proper data structure, which is the entirety of my complaint: I want my data to fit my application, I don't want to have to write my application to fit my data. I don't want to have to think "does this field belong in the Users table or the Accounts table or the [insert table here]".
I'm not sure what you mean by "just extending the data"... if I'm writing a Rails app and I need to change an int to a float, the way I do that is by writing and executing a migration.
As for the speed... a database typically stores its data on disk and is often not hosted on the same physical machine as the web server. Meanwhile the app and web server store a lot of things in-memory on the local server and even when it has to read from disk, it's a local disk attached to that machine. Check these numbers for how long it takes to read from memory (or even local disk) versus reading a remote disk over the network: https://gist.github.com/jboner/2841832
Or you write use a read replica to transform your data into a non-live DB and validate it before you put it into production, with backups of your final old schema available? Plus I really don't think a migration is that hard. Much harder than having a litany of shitty backends you have to glue together in your front-end app, trust me as someone who's done both.
I mean, I hear you, persisting data is hard, but that's not the database's fault, it's because you pick two of three on data: performance, persistence, and flexibility
> a database typically
But that's not the "worst performing" part of the stack, that's the highest latency part of the stack. Is there some specific reason you can not have co-located web & db servers? Also, is there a reason you still reference 2012 disk numbers when SSDs clearly have reduced all "disk" operations by an order of magnitude?
> just extending the data
What I mean by this is if you start with a minimal amount of columns in your database, and someone is like "we need new property x", it's easy to add X outside a migration - adding new columns or new tables does not require migrations if you don't modify existing columns
So this is my approach. Use as few bits as possible to persist your data, and then you can generally add new features migration-free
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.
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.
"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?
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.
Graph databases may be as good as relational DBs. They may be better for some use cases. Are they significantly better for many (say, the majority) of use cases? No? Well then, it's really not an issue that they're what became entrenched, is it?
(And if your answer was "yes" instead of "no": That takes some evidence to believe. And the way this article was written leads me to think that they don't actually have any such evidence.)
As a user of KV stores and graphdbs myself I would have to use a traditional rdbms. It's been an absolute breath of fresh air being able to express queries in a graph-oriented way. For me the combination has been totally "better", but of course, that's not evidence based! Nor, really, could it be.
Well, it's anecdote. But if a statistically-significant number of people feel that it's "an absolute breath of fresh air", that's totally "better" in a very concrete sense.
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/
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.
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 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.
>"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.
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/
Fortunately internet archive still has the previous version, that the comments here were discussing. https://web.archive.org/web/20200709192510/https://dgraph.io...