3 ms·

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 htt

by LukeEF 6y ago

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 6y ago
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.
jjoonathan 6y ago
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.

by LukeEF 6y ago

oldandtired 6y ago

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.

jjoonathan 6y ago

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.