Hacker News new | ask | show | jobs
by twawaaay 1319 days ago
I look at the database connections the following way: how many connections can a database really serve effectively? For a connection to be actively served the database really needs to have a cpu core working on it or waiting for IO from the storage. And I am completely omitting the fact that databases really need a sizeable amount of memory to be able to do things efficiently.

Even if you have a server with hundreds of cores your database probably can't be actively working on more than a small multiple of the number of the cores.

1 comments

I'm not sure if you've seen the other post, but we can totally handle one million queries per second: https://planetscale.com/blog/one-million-queries-per-second-....

And previous HN discussion: https://news.ycombinator.com/item?id=32680957.

I am not saying you can't. I totally believe you do.

Modern hardware is totally able to execute hundreds of thousands of transactions per second on a single core. If your query is simple and you can organise getting the data from storage at the necessary speeds you should totally be able to do this many requests, possibly even tens of millions.

But handling one million queries per second is completely different from having database server making progress on one million queries in parallel. What happens is, the database server is only making progress on a small number of them (typically in tens up to hundreds on a very beefy hardware) and everything else is just queued up.

There are much, much better ways to queue up millions of things than opening a million connections to get each one done individually.

Lambda was a means to an end for us here, and we're not specifically endorsing its use in _this_ way. Our goal was explicitly to test our ability to handle many parallel connections, and to observe what that looked like from different angles.

We're a DBaaS company, and we do need to be prepared for anything users may throw at us. Our Global Routing infrastructure has seen some major upgrades/changes recently to help support new features like PlanetScale Connect and our serverless drivers.

From our point of view, this was a sizing exercise with the interesting side benefit that many people do happen to use Serverless Functions similarly.