Skip to main content

Connection Pool

When your server handles many concurrent requests, a single database connection becomes a bottleneck. PrismConnectionPool manages a pool of SQLite connections, lending them out to requests and returning them when done.

Why Pool?

Without a pool, every concurrent request either:
  • Shares one connection — serializing all database work, killing throughput
  • Opens its own connection — expensive setup cost per request, risk of hitting file descriptor limits
A pool gives you the best of both: connections are reused, concurrent requests get their own connection, and the pool caps the total to prevent resource exhaustion.

Basic Setup

Creating a Pool
The pool starts with one connection and creates new ones on demand up to maxConnections. When all connections are busy, new requests wait until one is released.

Using Connections

withConnection Pattern
The connection is released back to the pool when the closure completes — even if it throws.

Manual

Manual Acquire/Release
Always release connections back to the pool. A leaked connection means the pool shrinks permanently. Prefer withConnection to avoid this.

Pool Monitoring

Pool Status

Server Integration

Pool with Route Handlers

Sizing the Pool

SQLite uses file-level locking, so writes serialize regardless of pool size. The pool helps most with concurrent reads and preventing connection setup overhead. For write-heavy workloads, consider WAL mode: PRAGMA journal_mode=WAL.

WAL Mode for Better Concurrency

Enable Write-Ahead Logging for concurrent reads during writes:
Enable WAL Mode

Health Check Integration

Combine with the health monitoring system:
Database Health Check