
Build your next app with a graph database - fernandogmo
https://dgraph.io/blog/post/graphdb-for-your-next-app/
======
the_duke
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
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
He did show concrete examples of how relational DBMSs force you to model and
query in an unintuitive way.

------
freehunter
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
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
Some graph databases, like TerminusDB and others, give strong ACID guarantees
and enforce data integrity - you can have the best of all worlds

------
whalesalad
"Relational databases: a software engineering fail"

Hard to take this piece seriously with a headline like this.

~~~
travisjungroth
That tech that quietly gives persistence to most of the software of the world:
fail.

------
jacquesm
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)

------
poorman
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.

------
plantel
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
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.

------
snicker7
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.

------
chvid
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?

~~~
staticassertion
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.

~~~
AnimalMuppet
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.

~~~
staticassertion
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.

~~~
AnimalMuppet
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.)

~~~
staticassertion
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.

~~~
AnimalMuppet
> 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.

------
vikingcaffiene
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
Could you elaborate?

------
jexp
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...](https://web.archive.org/web/20200709192510/https://dgraph.io/blog/post/graphdb-
for-your-next-app/)

------
mikeabraham
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.

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

------
mvitorino
"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.

------
ageitgey
This reads more like a sermon than a technical article.

~~~
guepe
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...

------
wayneftw
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.

------
FpUser
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.

------
znpy
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
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.

------
OrderlyTiamat
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.

------
wenc
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
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
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
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)

------
thelazydogsback
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.

------
nick_
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.

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

------
lol666
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

------
lol666
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

