pika/pika: A Pure Python AMQP 0-9-1 Client for RabbitMQ

What Pika Is For, and Who Ends Up Using It

Pika is a pure Python implementation of the AMQP 0-9-1 protocol, including RabbitMQ's extensions, according to the README. Pure Python is the load-bearing phrase here. There is no C extension to compile, no librabbitmq to link against, and the pyproject.toml lists an empty dependencies array. On a build machine that cannot compile native code, or in a container where you would rather not add a toolchain, that matters more than raw throughput.

The audience is Python developers talking directly to RabbitMQ. If you are writing a worker that drains a queue, a publisher that emits events, or a service that needs publisher confirms, Pika is aimed at you. The README states support for Python 3.7 and later on CPython and PyPy, and notes that Pika 1.1.0 was the last release supporting Python 2.7. The pyproject.toml classifiers go up to Python 3.14. If your codebase is still on Python 2, this library is not for you, and no amount of adapter choice will fix that.

One Library, Six Adapters, and Why the Choice Is the Whole Design

Pika does not impose an event loop. Instead it ships several connection adapters and expects you to pick one. The README lists pika.BlockingConnection for synchronous use, pika.SelectConnection as an asynchronous adapter with no third-party dependencies, pika.adapters.asyncio_connection.AsyncioConnection for asyncio, plus adapters for gevent, Tornado and Twisted. A seventh, pika.adapters.thread_safe_connection.Connection, runs a SelectConnection IOLoop in a background thread.

The README describes the core library as taking care not to forbid threads, greenlets, callbacks, continuations or generators, and states that most connection adapters are single-threaded. That single-threaded constraint is the mechanism behind the most common Pika failure: a consumer whose callback spends a long time processing a message can miss AMQP heartbeats, and the broker drops the connection. The README names this explicitly as a consequence of the single-threaded constraint.

The documented workaround for adapters other than the thread-safe one is to hand processing to another thread and acknowledge back on the IOLoop thread through add_callback_threadsafe. The README's own comment on that helper is blunt: messages processed in another thread may not be acknowledged directly from that thread. The newer thread-safe adapter removes the ceremony. Its consumer callbacks run on a per-channel worker thread, and the README's example acknowledges inline with channel.basic_ack(method.delivery_tag), annotated as safe with no callback scheduling needed. Slow processing then does not stall heartbeats.

Connection parameters are a separate axis. You can pass a sequence of pika.ConnectionParameters instances for fault tolerance, and the README says retries are configured with connection_attempts and retry_delay on the last element of that sequence. Retries happen only after connection attempts using all of the given parameters fail. That is failover across hosts, not a retry loop around a single host, and reading it the other way around will surprise you in production. The repository ships examples/blocking_consume_recover_multiple_hosts.py and a _retry variant, which is where the intended shape of that pattern lives.

Installing Pika and Publishing Your First Message

The package is on PyPI as pika, and the README's example section is the shortest path to a working publish. Install it with pip, then run the publish snippet the README gives.

pip install pika

import pika

connection = pika.BlockingConnection()
channel = connection.channel()
channel.basic_publish(exchange='test', routing_key='test',
                      body=b'Test message.')
connection.close()

Note what the README omits: no host argument, so the default connection parameters apply, and the exchange and routing key are both named test. The exchange has to exist on the broker, or the publish will not reach a queue. If you need a specific host, pass pika.ConnectionParameters('localhost') as the thread-safe example does.

Consuming is the same shape, with a loop over channel.consume. The README's blocking consumer prints the method frame, properties and body, acknowledges with channel.basic_ack(method_frame.delivery_tag), and breaks after ten messages. After the loop it calls channel.cancel(), which returns the number of requeued messages, then closes the connection. That return value is the part people skip: it tells you how many unacknowledged messages went back to the queue.

For anything multi-threaded, start from the thread-safe adapter rather than BlockingConnection. The README's example constructs Connection(pika.ConnectionParameters('localhost')), opens a channel, and registers a callback with ch.basic_consume('work', on_message). The callback acknowledges inline, which the README marks as safe with no callback scheduling needed. The repository points to examples/basic_consumer_threaded.py and examples/basic_publisher_threaded.py as the full versions.

Where Pika Gets in Your Way

The adapter model is the source of most of Pika's friction. A connection instance is confined to a single thread for every adapter except the thread-safe one, so sharing a BlockingConnection between threads is not a supported pattern. The README's recommended fix is to switch adapters, which is a structural change to how your application is wired, not a flag you flip.

The thread-safe adapter carries its own cost. Running the IOLoop in a background thread and dispatching consumer callbacks onto per-channel worker threads means you now have threads, and with them the usual questions about shared state in your callback. The README does not document a shutdown or drain procedure for that adapter, so how in-flight callbacks are handled at close time is something you will have to establish from the code and the examples rather than the prose.

Pika is also RabbitMQ-shaped by design. It implements AMQP 0-9-1 plus RabbitMQ's extensions. If you need to talk to a broker that speaks AMQP 1.0, or you want one client library that covers RabbitMQ, Kafka and SQS behind a single API, this is the wrong tool. The same applies if you want a framework to manage task routing, retries and result backends for you. Pika hands you a channel and a delivery tag; the rest is your application's problem.

Finally, the README's fault-tolerance snippet is easy to misread. Multiple ConnectionParameters give you ordered failover across hosts, and retries are configured on the last element. It is not a general reconnect strategy for a single broker that restarts.

Pika Against Kombu and aio-pika

The closest alternative in the Python ecosystem is Kombu, the messaging layer underneath Celery. The difference is abstraction level. Pika exposes AMQP 0-9-1 directly: you declare exchanges and queues, you call basic_publish, you acknowledge delivery tags. Kombu wraps that in a transport-agnostic API so the same application code can target RabbitMQ, Redis or SQS. If you need to switch brokers without rewriting your publish and consume paths, Kombu is the layer that makes that possible, and Pika is not trying to be.

If your application is already asyncio-native, aio-pika is the other comparison worth making. It is built around asyncio rather than offering asyncio as one adapter among several, which means its API is async throughout instead of presenting a blocking surface with an asynchronous adapter bolted alongside. Pika's AsyncioConnection is real and documented, but the library's center of gravity, including its README examples, is the blocking and thread-safe adapters.

The trade-off is consistent across both comparisons: Pika gives you the protocol and nothing above it. That is a feature when you want to reason about AMQP semantics directly, and a liability when you want someone else to have already solved reconnection, serialization and routing.

Maintenance, Licensing and Upgrade Cost

The repository is not archived, and the last push was on 2026-09-22. Recent releases include 1.4.4 on 2026-08-06, 1.4.2 on 2026-07-23 and 1.4.1 on 2026-05-22. The project is BSD-3-Clause, which the pyproject.toml also records as license = {text = "BSD-3-Clause"}. That is a permissive licence, and it is the same licence family most Python shops already accept. This is not legal advice; check with whoever handles licensing in your organisation if the distinction matters to you.

Upgrade cost is dominated by the adapter surface. The README's threading documentation presents pika.adapters.thread_safe_connection.Connection as the simplest way to use Pika from multiple threads, which reads as the direction the project wants new code to take. Applications built on the manual add_callback_threadsafe pattern still work, but they carry more code and more places to get acknowledgement wrong. If you are on that pattern, the migration is a rewrite of your connection setup and callback registration, not a version bump.

The pyproject.toml still declares version = "1.4.0" while the most recent release is 1.4.4, so the in-repo version string is not the release you are installing. Read the published release notes rather than the file when you need to know what changed.

Editorial conclusion

Adopt Pika if you want a pure Python AMQP 0-9-1 client with no runtime dependencies and your concurrency model maps onto one of its adapters. Do not adopt it if you need a broker-agnostic abstraction, a maintained Python 2 path, or a connection object you can freely share across threads. Before writing application code, verify on your target Python version which adapters import cleanly, and read the whole Threading section of the README, because the adapter choice is the decision that is hardest to reverse later.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. pika/pika on GitHub
3. Project website
4. README
5. Releases