4 ms·

Its all well and good to sit there and say "get a dedicated graph database". But there are two problems with that : (a) In many cases, running a graph databas

Its all well and good to sit there and say "get a dedicated graph database". But there are two problems with that : (a) In many cases, running a graph database will require getting involved with the monstrosity that is managing Java (since that is what most of them are written in). Managing Java is all well and good if you (or your team) have experience. For mere mortals its a nightmare to manage. (b) In the case of pretty much all graph databases, you only get basic features in the free / open-source version. If you want access to any genuinely useful features, you have to pay for "enterprise" with the associated $$$$$$$$$$. Meanwhile Postgres gives everyone a solid database, with all the features included out of the box, no pay to play. So what if you need to - shock horror - actually learn how a database works and write some proper SQL queries. The reason so many people have horror stories about SQL databases is because they let some inept developers loose on their RDBMS who treat a database like a black box dumping ground with zero thought about table design, index design, SQL queries or anything else. Rant over. ;-)

pas 6y ago
Not to mention that dumping "big data" amounts of stuff into any system and running complex search and sort computations on them is still a complexity theoretically hard problem. SQL or dedicated graph DB won't save anyone from coughing up the resources. Sure, it's easy to look at SQL and see the big ugly hundred line queries, but they would be hundred line code for graph DBs too. It's not a big surprise that FB for example for a few years just treated everything that stored data as a fast NAND store with some compaction algorithm on top plus a fancy API. SQL is that. (There was a great talk about this but I haven't managed to find it :/ )
WJW 6y ago
I don't mind writing SQL queries, quite the opposite in fact. In all my jobs so far I've been the go-to guy for rewriting queries to be more efficient. Don't know what you are ranting at tbh. It's just that the UNION ALL trick to fetch all related rows and then join them seems like it would need to rebuild (the relevant part of) the graph for each query and that simply "looks inefficient" compared to keeping all data in graph form all the time. If you are at a scale that you don't have to worry yet about CPU efficiency in your database layer, by all means just stick it in Postgres.

pas 6y ago

Not to mention that dumping "big data" amounts of stuff into any system and running complex search and sort computations on them is still a complexity theoretically hard problem. SQL or dedicated graph DB won't save anyone from coughing up the resources. Sure, it's easy to look at SQL and see the big ugly hundred line queries, but they would be hundred line code for graph DBs too. It's not a big surprise that FB for example for a few years just treated everything that stored data as a fast NAND store with some compaction algorithm on top plus a fancy API. SQL is that. (There was a great talk about this but I haven't managed to find it :/ )

WJW 6y ago

I don't mind writing SQL queries, quite the opposite in fact. In all my jobs so far I've been the go-to guy for rewriting queries to be more efficient. Don't know what you are ranting at tbh. It's just that the UNION ALL trick to fetch all related rows and then join them seems like it would need to rebuild (the relevant part of) the graph for each query and that simply "looks inefficient" compared to keeping all data in graph form all the time. If you are at a scale that you don't have to worry yet about CPU efficiency in your database layer, by all means just stick it in Postgres.