1. 24

  2. 2

    Good article. I’ve been tentatively looking for a slim, performant and asynchronous web-service framework, considering various languages and this article repels me from using Rust due to its syntax.

    One of the first scaling problems you’re likely to run into with Postgres is its modest limits around the maximum number of allowed simultaneous connections. Even the biggest instances on Heroku or GCP (Google Cloud Platform) max out at 500 connections, and the smaller instances have limits that are much lower (my small GCP database limits me to 25). Big applications with coarse connection management schemes (e.g., Rails, but also many others) tend to resort to solutions like PgBouncer to sidestep the problem.

    pgBouncer is not really “a solution you resort to in order to sidestep the problem”, it’s something that should be built into core Postgres but isn’t.

    At the end of the day, your database is going to be a bottleneck for parallelism, and the synchronous actor model supports about as much parallelism as we can expect to get from it, while also supporting maximum throughput for any actions that don’t need database access.

    I don’t know why. Especially since all the Postgres parallelization work that’s been put into PG 9.6 and 10.