17 unstable releases (7 breaking)

0.8.2 Jul 16, 2021
0.8.0 May 20, 2021
0.7.0 Dec 26, 2020
0.6.0 Nov 4, 2020
0.2.0 Nov 14, 2019

#5 in Database interfaces

Download history 10315/week @ 2021-04-07 12047/week @ 2021-04-14 13056/week @ 2021-04-21 12574/week @ 2021-04-28 13469/week @ 2021-05-05 16106/week @ 2021-05-12 13875/week @ 2021-05-19 13171/week @ 2021-05-26 13528/week @ 2021-06-02 15172/week @ 2021-06-09 15578/week @ 2021-06-16 16894/week @ 2021-06-23 16148/week @ 2021-06-30 20168/week @ 2021-07-07 20655/week @ 2021-07-14 20318/week @ 2021-07-21

65,119 downloads per month
Used in 70 crates (21 directly)


820 lines

Deadpool Latest Version Build Status

Deadpool is a dead simple async pool for connections and objects of any type.

This crate provides two implementations:

  • Managed pool (deadpool::managed::Pool)

    • Creates and recycles objects as needed
    • Useful for database connection pools
    • Enabled via the managed feature in your Cargo.toml
  • Unmanaged pool (deadpool::unmanaged::Pool)

    • All objects either need to to be created by the user and added to the pool manually. It is also possible to create a pool from an existing collection of objects.
    • Enabled via the unmanaged feature in your Cargo.toml


Feature Description Extra dependencies Default
managed Enable managed pool implementation async-trait yes
unmanaged Enable unmanaged pool implementation - yes
config Enable support for config crate config, serde/derive yes
rt_tokio_1 Enable support for tokio crate tokio/time no
rt_async-std_1 Enable support for async-std crate async-std no

The runtime features (rt_*) are only needed if you need support for timeouts. If you try to use timeouts without specifying a runtime at pool creation the pool get methods will return an PoolError::NoRuntimeSpecified error.

Managed pool (aka. connection pool)

This is the obvious choice for connection pools of any kind. Deadpool already comes with a couple of database connection pools which work out of the box.


use async_trait::async_trait;

enum Error { Fail }

struct Computer {}
struct Manager {}
type Pool = deadpool::managed::Pool<Manager>;

impl Computer {
    async fn get_answer(&self) -> i32 {

impl deadpool::managed::Manager for Manager {
    type Type = Computer;
    type Error = Error;
    async fn create(&self) -> Result<Computer, Error> {
        Ok(Computer {})
    async fn recycle(&self, conn: &mut Computer) -> deadpool::managed::RecycleResult<Error> {

async fn main() {
    let mgr = Manager {};
    let pool = Pool::new(mgr, 16);
    let mut conn = pool.get().await.unwrap();
    let answer = conn.get_answer().await;
    assert_eq!(answer, 42);

Database connection pools

Deadpool supports various database backends by implementing the deadpool::managed::Manager trait. The following backends are currently supported:

Backend Crate Latest Version
tokio-postgres deadpool-postgres Latest Version
lapin (AMQP) deadpool-lapin Latest Version
redis deadpool-redis Latest Version
async-memcached deadpool-memcached Latest Version
rusqlite deadpool-sqlite Latest Version
diesel deadpool-diesel Latest Version

Reasons for yet another connection pool

Deadpool is by no means the only pool implementation available. It does things a little different and that is the main reason for it to exist:

  • Deadpool is compatible with any executor. Objects are returned to the pool using the Drop trait. The health of those objects is checked upon next retrieval and not when they are returned. Deadpool never performs any actions in the background. This is the reason why deadpool does not need to spawn futures and does not rely on a background thread or task of any type.

  • Identical startup and runtime behaviour. When writing long running application there usually should be no difference between startup and runtime if a database connection is temporarily not available. Nobody would expect an application to crash if the database becomes unavailable at runtime. So it should not crash on startup either. Creating the pool never fails and errors are only ever returned when calling Pool::get().

    If you really want your application to crash on startup if objects can not be created on startup simply call pool.get().await.expect("DB connection failed") right after creating the pool.

  • Deadpool is fast. Whenever working with locking primitives they are held for the shortest duration possible. When returning an object to the pool a single mutex is locked and when retrieving objects from the pool a Semaphore is used to make this Mutex as little contested as possible.

  • Deadpool is simple. Dead simple. There is very little API surface. The actual code is barely 100 lines of code and lives in the two functions Pool::get and Object::drop.

Differences to other connection pool implementations

  • r2d2 provides a lot more configuration options but only provides a synchroneous interface.

  • bb8 provides an async/.await based interface and provides the same configuration options as r2d2. It depends on the tokio executor though and the code is more complex.

  • mobc provides an async/.await based interface and provides a lot more configuration options. It requires an executor though and the code is a lot more complex.

Unmanaged pool

An unmanaged pool is useful when you can't write a manager for the objects you want to pool or simply don't want to. This pool implementation is slightly faster than the managed pool because it does not use a Manager trait to create and recycle objects but leaves it up to the user.

Unmanaged pool example

use deadpool::unmanaged::Pool;

struct Computer {}

impl Computer {
    async fn get_answer(&self) -> i32 {

async fn main() {
    let pool = Pool::from(vec![
        Computer {},
        Computer {},
    let s = pool.get().await.unwrap();
    assert_eq!(s.get_answer().await, 42);


Why does deadpool depend on tokio? I thought it was runtime agnostic...

Deadpool depends on tokio::sync::Semaphore. This does not mean that the tokio runtime or anything else of tokio is being used or will be part of your build. You can easily check this by running the following command in your own code base:

cargo tree --format "{p} {f}"


Licensed under either of

at your option.


~84K SLoC