Build your next app with a graph database
dgraph.io
dgraph.io
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.
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
Hard to take this piece seriously with a headline like this.
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?
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.
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...
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.
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.
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.
I wonder if anyone can speak to how Hasura's approach compares to designing an architecture around a pure graph database?
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.