Hacker News new | past | comments | ask | show | jobs | submit login

There is not and will never be a solution to the problem of horizontally scaling an application and database designed jointly for a single-box ACID RDBMS. You have to compromise something to get the scaling.



Depends on your definition of horizontally scaling and the inherent size limitations you would be willing to accept.

CitusDB for example handles this by allowing FKeys between tables that share the same partition key. However it's also not -as- scalable as Vitess or as georeplication friendly but for many uses that need "more than a single box" is probably enough scalability.


> You have to compromise something to get the scaling.

And the reason why is basically “physics”. The speed of light is pretty damn slow all things considered.

Until we find ways to make all the servers in the cluster have latency measured in something like picoseconds, something is gonna have to give.


What about CockroachDB and YugabyteDB?


What is the compromise of Cockroach DB?


Heavy toll on performance and is not really postgres. For the same workload pg can be up to 30x faster or more than cockroach. At some point of course, pg won't be able to keep up and the horizontal scaling of crdb will beat it.


I believe they use some statistical analysis and declared locality tags (from config) to group related cells of data on the same nodes and regions, but I don't know how effective that proves. Pure performance isn't a strong suit of CRDB as far as I can tell, but sometimes that works fine, and it does scale well horizontally.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: