4 ms·

This desire can sometimes be so strong that people insist on truly wacky decisions. I have before demonstrated that Postgres performs perfectly well (and in fac

by cnity 3y ago

This desire can sometimes be so strong that people insist on truly wacky decisions. I have before demonstrated that Postgres performs perfectly well (and in fact exceeds) compared with a niche graph database, and heard some very strange reasons for why this approach should be avoided. A lot of the time you hear that it's engineers who chase shiny technology, but I've seen first hand what can happen when it's leadership.

tracker1 3y ago
I've been on both sides of this.. Rabbit MQ and Elastic Search for a public facing site. The dedicated queue for workers to denormalize and push updates. To elastic. Why, because the $10k/month RDBMS servers couldn't handle the search load and were overly normalized. Definitely a hard sell. I've also seen literally hundreds of lambda functions connecting to dozens of dynamo databases. I'm firmly in the camp of use an RDBMS (PostgreSQL my first choice) for most things in most apps. A lot of times you can simply apply the lessons from other databases at scale in pg rather than something completely different. I'm also more than okay leveraging a cloud's own MQ option, it's usually easy enough to swap out as/if needed.
spothedog1 3y ago
Can you expand on Postgres vs Graph Databases?
- cnity 3y ago
  It is easy to represent a graph in Postgres using edge and node tables. For the use case we have, it is more performant to query such a setup for many millions of relationships vs using the big names in graph databases. You just need a little bit of appropriate index selection and ability to read the output of EXPLAIN ANALYZE to do so. There are probably use cases where this doesn't hold, but I found in general that it is beneficial to stick to Postgres for this, especially if you want some ability to query using relations.
- mharig 3y ago
  IIRC, the biggest (AFAIK) graph DB in the world, TAO from Facebook, is based on an underlying MySQL. There must be a good reason why FB prefers a SQL DB over a dedicated graph DB.
cbreezyyall 3y ago
Often referred to as resume driven development.
- smitty1e 3y ago
  RDD leaves serious wreckage in its wake.

by cnity 3y ago

tracker1 3y ago

I've been on both sides of this.. Rabbit MQ and Elastic Search for a public facing site. The dedicated queue for workers to denormalize and push updates. To elastic. Why, because the $10k/month RDBMS servers couldn't handle the search load and were overly normalized. Definitely a hard sell. I've also seen literally hundreds of lambda functions connecting to dozens of dynamo databases. I'm firmly in the camp of use an RDBMS (PostgreSQL my first choice) for most things in most apps. A lot of times you can simply apply the lessons from other databases at scale in pg rather than something completely different. I'm also more than okay leveraging a cloud's own MQ option, it's usually easy enough to swap out as/if needed.

spothedog1 3y ago

Can you expand on Postgres vs Graph Databases?

cnity 3y ago
It is easy to represent a graph in Postgres using edge and node tables. For the use case we have, it is more performant to query such a setup for many millions of relationships vs using the big names in graph databases. You just need a little bit of appropriate index selection and ability to read the output of EXPLAIN ANALYZE to do so. There are probably use cases where this doesn't hold, but I found in general that it is beneficial to stick to Postgres for this, especially if you want some ability to query using relations.
mharig 3y ago
IIRC, the biggest (AFAIK) graph DB in the world, TAO from Facebook, is based on an underlying MySQL. There must be a good reason why FB prefers a SQL DB over a dedicated graph DB.

cbreezyyall 3y ago

Often referred to as resume driven development.

smitty1e 3y ago
RDD leaves serious wreckage in its wake.