Connection Pooling

Every SMLL database comes with a built-in PgBouncer connection pooler. The pooler sits between your application and PostgreSQL, reducing connection overhead and allowing thousands of concurrent clients.

Why connection pooling?

PostgreSQL creates a new process for each connection, which consumes memory and CPU. For applications with many short-lived connections (serverless functions, microservices), this quickly becomes a bottleneck.

PgBouncer maintains a pool of reusable connections, dramatically reducing the overhead.

Connection strings

Each database has two connection endpoints:

Endpoint	Use case
Direct	Long-lived connections, migrations, admin tools
Pooler	Application connections, serverless, high-concurrency

Both endpoints are shown on your database's Overview tab.

# Direct connection
postgresql://user:password@db-abc123.smll.io:5432/mydb

# Pooler connection (recommended for apps)
postgresql://user:password@pool-abc123.smll.io:5432/mydb

Pooler configuration

Setting	Value
Mode	Transaction
Default pool size	20
Max client connections	200
Server idle timeout	600s

Transaction mode means each transaction gets a server connection, which is returned to the pool when the transaction completes.

When to use direct connections

Use the direct connection endpoint for:

Running migrations (ALTER TABLE, CREATE INDEX)
LISTEN/NOTIFY (requires session-level state)
Prepared statements (not supported in transaction mode)
Administrative operations (pg_dump, psql admin commands)

When to use the pooler

Use the pooler endpoint for:

Application database connections
Serverless functions (Lambda, Edge workers)
Connection-heavy microservice architectures
Any workload with many short-lived connections