
20 years from now non-graph databases will be niche and legacy applications - LukeEF
https://terminusdb.com/blog/2020/03/02/why-graph-will-win/
======
verdverm
Postgresql has a graph like plugin, I plan to try that out before any custom /
nacent graphdb. Postgres is solid all around and I expect it to still be the
primary go-to for a long time for first DB to use. SQL is here to stay for
sure, as one of the most popular languages, with extensive usage outside of
the dev community.

The main problem I have with this article is that I takes a POV around schema
modelling, claims other DBs aren't good at this so graph will win(?), and yet
overlooks the very specific, tuned, and appropriate use cases of these
alternatives.

~~~
LukeEF
Yes, as I say, we tried postgres as a DB running a graph layer and found it
impossibly slow for network oriented queries (shortest path etc.).

The article is certainly taking a strong position, but I think it can boil
down to the new base line for workhorse transactional DBs will be graph and
other databases, while being valuable in special cases, will be niche.

~~~
verdverm
My understanding is the FB took MariaDB, hacked on it, and that's how they do
their graph like queries. In most end user applications, it's unlikely for
there to be many hops.

With Postgres, did you use the Graph extension (plugin?) or use the näive
method of 1±N queries / joins?

Claiming Graph DBs will replace everything else because of domain modelling
and scheme definitions, I don't see this logical jump.

If you are interested in my take and view on where domain modelling / schema
def is going, take a look at our [https://github.com/hofstadter-
io/hof](https://github.com/hofstadter-io/hof) and
[https://cuelang.org](https://cuelang.org)

In short, there will be a single source of truth to designs and they will be
written outside of all tech that needs to make use of them. Largely because
the design from business is a larger set and each piece of the stack needs a
slightly different subset.

~~~
LukeEF
That is interesting, thanks. As you can probably imagine, I fall in the build
business logic into data with constraints at the schema layer.

Yes, I understand that FB have a bunch of MySQL instances with a hacked graph
layer - same in other places. Makes the case for native solutions and I think
that is why Dgraph exist.

Graph will become the base, because it does everything an RDBMS can do and
some more.

~~~
oldandtired
When you state "Graph will become the base, because it does everything an
RDBMS can do and some more.", you show that you fail to understand what an
RDBMS is and that there is NO commercially available RDBMS around. There are
significant differences between SQL DBMS's and RDBMS.

The other thing you have also forgotten, is that you can rewrite your
statement as "RDBMS will become the base, because it does everything a Graph
can do and some more." The last part of this "and some more" makes both
statements equally false. Or if you view it in another way, equally true.

These things are tools that we have available to us so that we can solve the
various problems laid before us.

~~~
verdverm
I thought lunch was free :[

------
LukeEF
There was a Dgraph blog about why you should build your next app on a graph
database on HN yesterday
([https://news.ycombinator.com/item?id=23783923#23784866](https://news.ycombinator.com/item?id=23783923#23784866)).
I think it made a number of very valid points, but it was imho harshly
criticized by SQL fundamentalists.

At TerminusDB, we share their perspective about the future of graph and wrote
this slightly hyperbolic blog about the future of databases and 'why graph
will win'. It won't be to everybody's taste, and we might be accused of
fanning the flames; however, we genuinely think that graph DBs are a better
way to store and query data. We tried to implement our solution as a layer on
postgres and the performance for the types of queries we wanted to run was
poor. If RDBMS were sufficient, there would be no TerminusDB, just a data
quality layer on a postgres.

The strongest point in the Dgraph article is 'Graph databases let you model in
a more natural way than relational databases.' As one HN comment said 'I get
tired of building code to work around my database and it's oddities rather
than my data just fitting nicely into the code.' We couldn't agree more.

It is a polemic contribution to a debate - a debate we should be having. Graph
has come of age and fresh eyes are needed.

~~~
oldandtired
As happens, each generation thinks that what they have developed will
supersede what has happened in the past. This involves a failure to understand
the lessons of the past. As far as database technologies are concerned, no one
technological model will fill every area to the exclusion of all the others.
Graph based databases are not an exception here. They are a rehash of network
databases from the past. They have their uses, but it is not universal by any
means.

What too many people have failed to understand is that SQL databases are not
relational databases (though you can build a relational database on a SQL
DBMS). There are certain problem domains for which different underlying DBMS's
are a far better fit. It depends very much on what you are trying to achieve.

No one technology will "win" as there are always problems that are better
solved using a different tool. There is an old saying that is oft forgotten
and that is: If all you have is a hammer, everything looks like a nail.

We are supposed to have a large number of tools in our toolbox to solve the
various problems that come before us. Let's be Master Craftsmen and use the
whole range of tools available to us. This is applicable in the choice of
database technology as it is in the choice of language or the choice of
programming style or any other tool choice we may use.

