4 posts tagged with "connection-pooling"

Part 4 of a series. Start with Two jobs, two processes for the architecture and motivation.

In a single-database setup, prepared statements are a clean win. Postgres parses the statement once, builds a plan, caches both, and subsequent EXECUTEs reuse the plan. Cheap. In a setup with many gateways in front of one Postgres instance, that win quietly evaporates unless you do something about it. This post is about what we do about it.

Part 3 of a series. Start with Two jobs, two processes for the architecture and motivation.

Connection pool modes aren't an arbitrary choice. They exist because Postgres connections carry session state - temp tables, prepared statements, settings, transactions in progress - and it's not always safe to give one client's connection to a different client. The traditional answer is to pick a mode at configuration time and live with it. We didn't want users to have to make that pick. This post is about how Multigres figures it out per-query, automatically.

Part 2 of a series. Start with Two jobs, two processes for the architecture and motivation.

Multigres maintains a separate connection pool per user. This post is about why we made that choice (it's mostly a security story), how we share the connection budget fairly across users, and the routing trick that keeps pool lookup constant time even when there are many pools.

Most connection poolers do two jobs in one process: accept client connections, and manage backend connections. In Multigres, we split them. Multigateway accepts clients; multipooler manages backends. This post is about why.