deadpool

Deadpool is a generic async object and connection pool for Rust, offering both a managed pool (deadpool::managed::Pool) that creates and recycles objects on demand, and an unmanaged pool (deadpool::unmanaged::Pool) for pooling pre-created objects. It’s runtime-agnostic by default and adds optional Tokio, async-std, or smol support only when timeout functionality is needed.

The deadpool-rs org builds on this core crate with ready-made backends for popular services — deadpool-postgres, deadpool-redis, deadpool-sqlite, deadpool-diesel, deadpool-lapin, and others — each implementing the Manager trait to recycle connections for that specific client library. This makes deadpool the shared foundation most Rust database/service connection pools in the ecosystem are built on top of.

What You Get

• A managed Pool<M: Manager> that creates and recycles objects via a user-implemented Manager trait
• An unmanaged Pool for holding pre-created objects with no creation/recycling logic
• Pluggable async runtime support (Tokio, async-std, smol) enabled only via opt-in rt_* features
• Pre/post hooks for custom checkout/recycle behavior, plus timeout and queue-mode configuration
• Serde support for deserializing pool configuration from config files or environment variables

Common Use Cases

• Pooling database connections for Postgres, SQLite, or MySQL via the deadpool-postgres/deadpool-sqlite/deadpool-diesel backend crates
• Pooling Redis connections via deadpool-redis for caching and pub/sub workloads
• Pooling AMQP/RabbitMQ channels via deadpool-lapin for message-queue producers/consumers
• Building a custom pool for any expensive-to-create resource (HTTP clients, gRPC channels) by implementing the Manager trait directly

Under The Hood

Architecture - The core crate (crates/deadpool/src/) splits into managed/ and unmanaged/ modules behind separate feature flags. The managed pool (managed/pool.rs) wraps an Arc<PoolInner<M>> guarded by a tokio::sync::Semaphore for checkout concurrency control, with Object<M> (managed/object.rs) wrapping the pooled value plus metadata and a DropGuard (managed/dropguard.rs) that returns objects to the pool automatically on drop. Manager (managed/manager.rs) is the trait downstream crates (deadpool-postgres, deadpool-redis, etc.) implement to define how their specific connection type is created and recycled, making deadpool a policy layer over a caller-supplied resource lifecycle.

Tech Stack - Pure Rust (93% of the repo by bytes), edition 2024, minimum Rust 1.85, with #![forbid(unsafe_code)] declared in the README badge. Depends non-optionally on tokio::sync::Semaphore for the checkout primitive, but keeps full Tokio runtime features, async-std, and smol behind separate opt-in rt_* feature flags so non-Tokio users aren’t forced to pull in the full runtime. The repo is a Cargo workspace (crates/) housing the core crate alongside ten sibling backend crates.

Code Quality - The deadpool crate has 11 files under tests/ covering managed/unmanaged pool behavior, plus Criterion benchmarks (benches/managed.rs, benches/unmanaged.rs) for performance regression tracking. CI is defined via a shared Jsonnet template (ci.jsonnet) generating per-crate GitHub Actions workflows, and a check-reexports.sh script guards against accidental API drift across the workspace’s many crates.

API Design - The Manager trait’s two required methods (create, recycle) are the only things a new backend needs to implement to gain a fully-featured async pool, which is why the ecosystem has ten-plus deadpool-* backend crates built on this core. The managed/unmanaged split, opt-in runtime features, and hook system (pre/post-checkout) add real configurability but also mean new users must pick the right feature combination up front — the README’s feature table exists precisely to guide that choice.