kombu is a free, open source databases project written in Python and released under BSD-3-Clause. It has 3,141 GitHub stars, 1,043 forks and 217 open issues, and was last pushed 19 hours ago. On this registry it ranks #179 of 203 tracked projects in Databases, with 5 head-to-head comparisons available.

What is kombu?

Kombu is a BSD-3-Clause licensed Python messaging library that gives application authors an idiomatic, high-level interface to the AMQP protocol and pluggable transports for Redis, Amazon SQS, MongoDB, PGMQ, ZooKeeper, SoftLayer MQ, and Pyro, aimed at Python developers and Celery-based teams that need one consistent messaging API across several brokers.

What it is

Kombu is a messaging library for Python whose stated aim is to make messaging in Python as easy as possible by providing an idiomatic high-level interface for the AMQ protocol, alongside proven and tested solutions to common messaging problems. It lives in the Python ecosystem and is maintained under the celery GitHub organisation, with documentation at kombu.readthedocs.io and distributions published to PyPI as the kombu package. The protocol at its centre is AMQP, the Advanced Message Queuing Protocol, an open standard for message orientation, queuing, routing, reliability and security, for which RabbitMQ is the most popular implementation.

The concrete problem it solves is broker lock-in and low-level protocol handling in Python applications. Earlier code either spoke directly to a specific client such as amqplib, or was written against carrot, and inherited that client's limitations. Kombu abstracts the broker behind pluggable transports, so application authors can support several message server solutions without rewriting publish and consume paths. It also fixes specific annoyances present in amqplib, including support for timeouts and the ability to wait for events on more than one channel, and it offers a compatibility layer so projects already using carrot can be ported easily.

Key capabilities

  • Pluggable transports let one application talk to several message server solutions, with an AMQP transport built on the py-amqp or qpid-python libraries.
  • Virtual transports extend support beyond AMQP to Redis, Amazon SQS, ZooKeeper, SoftLayer MQ, MongoDB, PGMQ, and Pyro.
  • An in-memory transport is provided for unit testing.
  • Automatic encoding, serialization, and compression of message payloads are handled by the library.
  • Exception handling is consistent across transports, and connection and channel errors are handled gracefully so operations still complete.
  • A documented transport comparison table records per-transport support for Direct, Topic, and Fanout routing plus Priority and TTL, showing that amqp and mongodb support TTL while redis, qpid, pgmq, and SQS do not.
  • A carrot compatibility layer allows projects already using carrot to be ported.

Who uses it and how

  • Celery deployments, where Kombu is the messaging layer beneath distributed task queues, including setups where tasks are routed through RabbitMQ.
  • Applications that must switch or mix brokers, using the Redis, Amazon SQS, PGMQ, or MongoDB virtual transports instead of the native AMQP transport.
  • Test suites that exercise publish and consume logic against the in-memory transport rather than a live broker.
  • Teams migrating legacy code from carrot, which can be ported through the built-in compatibility layer.
  • Projects that need to wait for events on more than one channel or rely on timeouts, which the amqplib-derived limitations did not permit.

Getting started

Install from PyPI as the kombu package (current version 5.6.2, download page at pypi.org/project/kombu/); full setup and transport guidance is at kombu.readthedocs.io, and source is at github.com/celery/kombu.

How it compares

The facts do not list commercial or paid products that Kombu replaces, so no licence, hosting, or cost-model contrast can be drawn from them. Within Python messaging it sits alongside the lower-level clients it builds on or supersedes, namely py-amqp and qpid-python for AMQP and carrot for legacy code, and it stands alone in this registry as the transport-abstracting layer that those clients do not provide.

When to use it — and when not to

A self-hoster still has to run and operate the message server itself, whether that is RabbitMQ, Redis, MongoDB, PGMQ, or a cloud service such as Amazon SQS, and Kombu does not remove that operational burden. Teams that need only one fixed broker may find a direct client simpler, since the transport abstraction is the main reason to adopt the library. Worth noting as an honest limitation: the project carries 217 open issues, and the provided facts do not state supported Python versions or release cadence beyond version 5.6.2 and a last push in September 2026.

project readme (upstream, from github) — read inline

======================================== kombu - Messaging library for Python

|build-status| |coverage| |license| |wheel| |pyversion| |pyimp| |downloads|

:Version: 5.6.2 :Documentation: https://kombu.readthedocs.io/ :Download: https://pypi.org/project/kombu/ :Source: https://github.com/celery/kombu/ :DeepWiki: |deepwiki| :Keywords: messaging, amqp, rabbitmq, redis, mongodb, python, queue

About

Kombu is a messaging library for Python.

The aim of Kombu is to make messaging in Python as easy as possible by providing an idiomatic high-level interface for the AMQ protocol, and also provide proven and tested solutions to common messaging problems.

AMQP_ is the Advanced Message Queuing Protocol, an open standard protocol for message orientation, queuing, routing, reliability and security, for which the RabbitMQ_ messaging server is the most popular implementation.

Features

  • Allows application authors to support several message server solutions by using pluggable transports.

    • AMQP transport using the py-amqp, or qpid-python libraries.

    • Virtual transports makes it really easy to add support for non-AMQP transports. There is already built-in support for Redis, Amazon SQS, ZooKeeper, SoftLayer MQ, MongoDB, PGMQ and Pyro_.

    • In-memory transport for unit testing.

  • Supports automatic encoding, serialization and compression of message payloads.

  • Consistent exception handling across transports.

  • The ability to ensure that an operation is performed by gracefully handling connection and channel errors.

  • Several annoyances with amqplib_ has been fixed, like supporting timeouts and the ability to wait for events on more than one channel.

  • Projects already using carrot_ can easily be ported by using a compatibility layer.

For an introduction to AMQP you should read the article Rabbits and warrens, and the Wikipedia article about AMQP.

.. _RabbitMQ: https://www.rabbitmq.com/ .. _AMQP: https://amqp.org .. _py-amqp: https://pypi.org/project/amqp/ .. _qpid-python: https://pypi.org/project/qpid-python/ .. _Redis: https://redis.io .. _Amazon SQS: https://aws.amazon.com/sqs/ .. _Zookeeper: https://zookeeper.apache.org/ .. _Rabbits and warrens: http://web.archive.org/web/20160323134044/http://blogs.digitar.com/jjww/2009/01/rabbits-and-warrens/ .. _amqplib: https://barryp.org/software/py-amqplib/ .. _Wikipedia article about AMQP: https://en.wikipedia.org/wiki/AMQP .. _carrot: https://pypi.org/project/carrot/ .. _librabbitmq: https://pypi.org/project/librabbitmq/ .. _Pyro: https://pyro4.readthedocs.io/ .. _SoftLayer MQ: https://web.archive.org/web/20180313081320/http://sldn.softlayer.com/reference/messagequeueapi .. _MongoDB: https://www.mongodb.com/ .. _PGMQ: https://pgmq.github.io/pgmq/ .. _AWS SNS: https://aws.amazon.com/sns/

.. _transport-comparison:

Transport Comparison

+---------------+----------+------------+------------+---------------+--------------+-----------------------+ | Client | Type | Direct | Topic | Fanout | Priority | TTL | +---------------+----------+------------+------------+---------------+--------------+-----------------------+ | amqp | Native | Yes | Yes | Yes | Yes [#f3]_ | Yes [#f4]_ | +---------------+----------+------------+------------+---------------+--------------+-----------------------+ | qpid | Native | Yes | Yes | Yes | No | No | +---------------+----------+------------+------------+---------------+--------------+-----------------------+ | redis | Virtual | Yes | Yes | Yes (PUB/SUB) | Yes | No | +---------------+----------+------------+------------+---------------+--------------+-----------------------+ | mongodb | Virtual | Yes | Yes | Yes | Yes | Yes | +---------------+----------+------------+------------+---------------+--------------+-----------------------+ | pgmq | Virtual | Yes | Yes | Yes | No | No | +---------------+----------+------------+------------+---------------+--------------+-----------------------+ | SQS | Virtual | Yes | Yes [#f1]_ | Yes [#f2]_ | No | No | +---------------+----------+------------+------------+---------------+--------------+-----------------------+ | zookeeper | Virtual | Yes | Yes [#f1]_ | No | Yes | No | +---------------+----------+------------+------------+---------------+--------------+-----------------------+ | in-memory | Virtual | Yes | Yes [#f1]_ | No | No | No | +---------------+----------+------------+------------+---------------+--------------+-----------------------+ | SLMQ | Virtual | Yes | Yes [#f1]_ | No | No | No | +---------------+----------+------------+------------+---------------+--------------+-----------------------+ | Pyro | Virtual | Yes | Yes [#f1]_ | No | No | No | +---------------+----------+------------+------------+---------------+--------------+-----------------------+

.. [#f1] Declarations only kept in memory, so exchanges/queues must be declared by all clients that needs them.

.. [#f2] Fanout is supported via AWS SNS. A notification is sent to SNS, and a copy is set to all subscribed Amazon SQS queues. Please consult the AWS SNS and SQS pricing pages to see how this will affect your usage costs. Disabled by default, but can be enabled by using the supports_fanout transport option.

.. [#f3] AMQP Message priority support depends on broker implementation.

.. [#f4] AMQP Message/Queue TTL support depends on broker implementation.

Documentation

Kombu is using Sphinx, and the latest documentation can be found here:

https://kombu.readthedocs.io/

Quick overview

.. code:: python

from kombu import Connection, Exchange, Queue

media_exchange = Exchange('media', 'direct', durable=True)
video_queue = Queue('video', exchange=media_exchange, routing_key='video')

def process_media(body, message):
    print(body)
    message.ack()

# connections
with Connection('amqp://guest:guest@localhost//') as conn:

    # produce
    producer = conn.Producer(serializer='json')
    producer.publish({'name': '/tmp/lolcat1.avi', 'size': 1301013},
                      exchange=media_exchange, routing_key='video',
                      declare=[video_queue])

    # the declare above, makes sure the video queue is declared
    # so that the messages can be delivered.
    # It's a best practice in Kombu to have both publishers and
    # consumers declare the queue. You can also declare the
    # queue manually using:
    #     video_queue(conn).declare()

    # consume
    with conn.Consumer(video_queue, callbacks=[process_media]) as consumer:
        # Process messages and handle events on all channels
        while True:
            conn.drain_events()

# Consume from several queues on the same channel:
video_queue = Queue('video', exchange=media_exchange, key='video')
image_queue = Queue('image', exchange=media_exchange, key='image')

with connection.Consumer([video_queue, image_queue],
                         callbacks=[process_media]) as consumer:
    while True:
        connection.drain_events()

Or handle channels manually:

.. code:: python

with connection.channel() as channel:
    producer = Producer(channel, ...)
    consumer = Consumer(channel)

All objects can be used outside of with statements too, just remember to close the objects after use:

.. code:: python

from kombu import Connection, Consumer, Producer

connection = Connection()
    # ...
connection.release()

consumer = Consumer(channel_or_connection, ...)
consumer.register_callback(my_callback)
consumer.consume()
    # ....
consumer.cancel()

Exchange and Queue are simply declarations that can be pickled and used in configuration files etc.

They also support operations, but to do so they need to be bound to a channel.

Binding exchanges and queues to a connection will make it use that connections default channel.

::

>>> exchange = Exchange('tasks', 'direct')

>>> connection = Connection()
>>> bound_exchange = exchange(connection)
>>> bound_exchange.delete()

# the original exchange is not affected, and stays unbound.
>>> exchange.dele

readme truncated — read the full docs on github

Frequently asked questions

Is kombu free to use?

kombu is open source under the BSD-3-Clause licence. There is no licence fee and no seat count — you can self-host it or, where the project offers one, pay a vendor for a managed version instead.

What does kombu do?

Messaging library for Python.

What is kombu written in?

kombu is primarily written in Python. Its source is publicly available at https://github.com/celery/kombu, and it has 3,141 GitHub stars.