3 ms·

1. "Easier to scale" Scaling is such a weired topic, its like that joke about teenage sex, everybody always talks and is concerned about it but how many people

1. "Easier to scale" Scaling is such a weired topic, its like that joke about teenage sex, everybody always talks and is concerned about it but how many people really have to scale? And generally if you have to scale you have money and money can make any system work 2. "Closer to how we model the world in our minds, hence easier to reason about" I don't think i agree. I would argue, most peoples mental model of data is strongly inspired by tables. Thus, the big success of excel. 3."Easier to query" ok maybe I am just too used to SQL databases but i would very strongly disagree there. SQL or using any ORM its super easy to query. Of course some joins might get complicated. But if you always have to run a lot of complicated joins you can probably work on the data model, or use caching.

mxz3000 5y ago
> And generally if you have to scale you have money and money can make any system work That's the thing, this is not always true. It's true that generally you can throw money and hardware at a problem, but at some point you just reach the fundamental limit of the technology, at which point throwing money at the problem doesn't work. In fact, being in a position where you can throw money at the problem is _brilliant_, as spending money is easy. So the point of _scalable_ technologies is to enable you to scale just by throwing money at the problem. Case in point, at my old company we had this _massive_ Pg database running in RDS. It did not scale. Performance was terrible, and made the user experience shit. We were basically using the biggest instance size we could, with a few replicas powering read only endpoints. So at some point we migrated parts of it to Dynamo, and poof all of our problems went away, including operational ones.
jandrewrogers 5y ago
One of the primary issues with graph databases is that they don't scale no matter how much money you throw at them. Many organizations quickly hit a very hard scaling wall with graph databases, and no amount of effort will resolve it. Money doesn't make hard computer science problems disappear. The US military has been willing to write a blank check to anyone that builds a graph database that actually scales for decades. No one has collected on that.

mxz3000 5y ago

> And generally if you have to scale you have money and money can make any system work That's the thing, this is not always true. It's true that generally you can throw money and hardware at a problem, but at some point you just reach the fundamental limit of the technology, at which point throwing money at the problem doesn't work. In fact, being in a position where you can throw money at the problem is _brilliant_, as spending money is easy. So the point of _scalable_ technologies is to enable you to scale just by throwing money at the problem. Case in point, at my old company we had this _massive_ Pg database running in RDS. It did not scale. Performance was terrible, and made the user experience shit. We were basically using the biggest instance size we could, with a few replicas powering read only endpoints. So at some point we migrated parts of it to Dynamo, and poof all of our problems went away, including operational ones.

jandrewrogers 5y ago

One of the primary issues with graph databases is that they don't scale no matter how much money you throw at them. Many organizations quickly hit a very hard scaling wall with graph databases, and no amount of effort will resolve it. Money doesn't make hard computer science problems disappear. The US military has been willing to write a blank check to anyone that builds a graph database that actually scales for decades. No one has collected on that.