20 years from now non-graph databases will be niche and legacy applications | Hacker News Reader

20 years from now non-graph databases will be niche and legacy applications

terminusdb.com

9 pointsLukeEF10 comments

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.

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.

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

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.

For me, it's less about SQL v GQL and more about the maturity and scalability of the underlying tech, Postgresql has everything I need except for niche applications.

I too put BI, rules, and shapes in the schema or design. I'm choosing to express this with Cue and generate the tech specific schemas, types, and code from that. A database will never fit this role because the better definitions span tech and would be forcing concerns upon a DB schema that don't belong there (like data presentation to a user in a UI).

Then there is the whole data lake perspective and a BI engine which can span tech and stores, paired with how enterprise companies operate... they like SQL based queries which can work on data across their legacy appliances. Analysts know SQL.

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.

I thought lunch was free :[

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

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.

My understanding is that graph databases came first and relational databases replaced them because they provided a reliable methodology to understand and accelerate nearly any new access pattern without reshaping data (joins and indexes, of course). The new graph DB rhetoric does not address what changed to make the previously-fatal flaw no longer fatal.

10 years ago, I bought into the mongo hype, jumped before it was ready (ACID? Transactions? With our new philosophy you don't need any of those silly things!) and wound up cracking my head on the bottom of that particular swimming pool. I'm not keen to repeat that mistake, so this time I want to understand before I jump.

Reply on news.ycombinator.com