skip to content
Notes && Anecdotes
A pool, something Postgres might benefit from to include better serverless support. Photo by Marc-Antoine Roy on UnsplashA pool, something Postgres might benefit from to include better serverless support. Photo by Marc-Antoine Roy on Unsplash

Postgres needs built-in connection pooling

serverlesspostgresdatabase

The future is serverless, and Postgres has issues fitting into that.

  1. The high cost of creating and holding a database connection, effectively stop direct connections from serverless functions.

  2. The slow startup time eliminates Postgres on-demand service. You pay for standby capacity instead.

Performance issue on multiple clients

Postgres’ performance decline rapidly with number of connections. The cost of holding and creating connections is to an extent solvable with connection-pooling. Postgres does not have pooling built-in, but it can be done with software like pgBouncer.

This is what Digitial Ocean has included by default on its database services. Since connection pooling is run on separate host, it’s not surprising that Digital Ocean charges almost twice the amount of e.g. render.com for a minimal database.

Paying for capacity

Maybe the biggest issue with paying for initial standby capacity is how it drives developers away from Postgres and towards other options like DynamoDB or Firebase. A student or someone playing around with making an app for fun will often avoid the 10$/month cost. And what you learn is what you’ll preach when starting in a “real” job.

A second issue is scaling, which is particulary relevant for new companies. Publicity might increase their database load by 100x unexpectedly, and there isn’t really great Postgres services that handle that for you (yet).

Postgres won’t adapt to serverless

I think Postgres is amazing, but I’m a bit worried that it’ll become obsolete over time unless it adapts the the ephemeral function based future.

Postgres 14 goes in the right direction, handles many connections a bit better, but it’s still leap years from NoSQL. Searching “serverless” on postgresql.org yield no results, and its TODO list neither mentions connection pooling. We can find the following in its Number of database connections page (which is from 2014!):

The decision not to include a connection pooler inside the PostgreSQL server itself has been taken deliberately and with good reason Postgres, 2014

…but it’s maybe not their responsibility?

Postgres is an open source software, not owned by any company. Anyone can set up a postgres database on their local computer or their server. Cloud providers like AWS, Google and Microsoft are the ones who would benefit greatly from a postgres-like serverless service, and maybe it’s them who should figure out how to make that work?

AWS attempts to be doing just that with Aurora Serverless 2.0 (preview). It can scale up within milliseconds and automatically scale down when traffic resides. But its cold start (scaling from 0 capacity) is still so slow it becomes unusable unless you keep minimum capacity always on (starts at about 100$/month).

The result of all this is alternative database services adapted to a serverless environment, like Firestore and FaunaDB. While that’s cool and all, I’d really like to keep living in a Postgres world. I’m just not sure I can anymore.

Previous postHow will you measure your life? 🤔
Next PostHow-to: Run npm/yarn with one command