{
  "schema_version": 2,
  "id": "develop/clients/pools-and-muxing",
  "title": "Connection pools and multiplexing",
  "url": "https://redis.io/docs/latest/develop/clients/pools-and-muxing/",
  "summary": "Manage Redis connections efficiently",
  "aliases": [
    "/develop/connect/clients/pools-and-muxing"
  ],
  "tags": [
    "docs",
    "develop",
    "stack",
    "oss",
    "rs",
    "rc",
    "oss",
    "kubernetes",
    "clients"
  ],
  "last_updated": "2026-09-29T16:29:37+01:00",
  "page_type": "content",
  "content_hash": "b8d652fbc706e8c6fa591737b23a1a7000b959a85ac67936b4599c4b95297f57",
  "sections": [
    {
      "id": "overview",
      "title": "Overview",
      "role": "overview",
      "text": "Redis example code generally opens a connection, demonstrates\na command or feature, and then closes. Real-world code typically\nhas short bursts of communication with the server and periods of\ninactivity in between. Opening and closing connections\ninvolves some overhead and leads to inefficiency if you do\nit frequently. This means that you can improve the performance of production\ncode by making as few separate connections as possible.\n\nManaging connections in your own code can be tricky, so the Redis\nclient libraries give you some help. The two basic approaches to\nconnection management are called *connection pooling* and *multiplexing*.\nThe [`redis-py`](https://redis.io/docs/latest/develop/clients/redis-py),\n[`jedis`](https://redis.io/docs/latest/develop/clients/jedis), and\n[`go-redis`](https://redis.io/docs/latest/develop/clients/go) clients support\nconnection pooling, while\n[`StackExchange.Redis`](https://redis.io/docs/latest/develop/clients/dotnet)\nsupports multiplexing.\n[`Lettuce`](https://redis.io/docs/latest/develop/clients/lettuce)\nsupports both approaches."
    },
    {
      "id": "connection-pooling",
      "title": "Connection pooling",
      "role": "content",
      "text": "When you initialize a connection pool, the client opens a small number\nof connections and adds them to the pool.\n\n![](https://redis.io/docs/latest/images/dev/connect/pool-and-mux/ConnPoolInit.drawio.svg)\n\nEach time you \"open\" a connection\nfrom the pool, the client returns one of these existing\nconnections and notes the fact that it is in use.\n\n![](https://redis.io/docs/latest/images/dev/connect/pool-and-mux/ConnPoolInUse.drawio.svg)\n\nWhen you later \"close\"\nthe connection, the client puts it back into the pool of available\nconnections without actually closing it.\n\n![](https://redis.io/docs/latest/images/dev/connect/pool-and-mux/ConnPoolDiscon.drawio.svg)\n\nIf all connections in the pool are in use but the app needs more, then\nthe client can simply open new connections as necessary. In this way, the client\neventually finds the right number of connections to satisfy your\napp's demands."
    },
    {
      "id": "multiplexing",
      "title": "Multiplexing",
      "role": "content",
      "text": "Instead of pooling several connections, a multiplexer keeps a\nsingle connection open and uses it for all traffic between the\nclient and the server. The \"connections\" returned to your code are\nused to identify where to send the response data from your commands.\n\n![](https://redis.io/docs/latest/images/dev/connect/pool-and-mux/ConnMux.drawio.svg)\n\nNote that it is not a problem if the multiplexer receives several commands close\ntogether in time. When this happens, the multiplexer can often combine the commands into a\n[pipeline](https://redis.io/docs/latest/develop/using-commands/pipelining), which\nimproves efficiency.\n\nMultiplexing offers high efficiency but works transparently without requiring\nany special code to enable it in your app. The main disadvantage of multiplexing compared to\nconnection pooling is that it can't support the blocking \"pop\" commands (such as\n[`BLPOP`](https://redis.io/docs/latest/commands/blpop)) since these would stall the\nconnection for all callers."
    }
  ],
  "examples": []
}