有些消息代理甚至可使用 XA 或 JTA 参与两阶段提交协议。这和DB在本质相似，尽管消息代理和DB存在实践上很重要的差异：
- DB通常保留数据直至显式删除，而大多消息代理在消息成功递送给消费者时会自动删除消息。这样的消息代理不适合长期数据存储
- 由于它们很快就删除消息，大多数消息代理都认为它们的工作集很小，即队列很短。如代理需缓冲很多消息，比如因为消费者速度慢（如果内存装不下消息，可能会溢出到磁盘），每个消息需要更长处理时间，整体吞吐量可能恶化
- DB通常支持次级索引和各种搜索数据方式，而消息代理通常支持按照某种模式匹配主题，订阅其子集。虽机制不一，但对于客户端选择想要了解的数据的一部分，都是基本方式
- 查询DB时，结果通常基于某时间点数据快照；若另一个客户端随后向数据库写入一些改变了查询结果的内容，则第一个客户端不会发现其先前结果现已过期（除非它重复查询或轮询变更）。而消息代理不支持任意查询，但当数据发生变化时（即新消息可用时），它们会通知客户端
这是关于消息代理的传统观点，它被封装在诸如 JMS 【14】和 AMQP 【15】的标准中，并且被诸如 RabbitMQ、ActiveMQ、HornetQ、Qpid、TIBCO 企业消息服务、IBM MQ、Azure Service Bus 和 Google Cloud Pub/Sub 所实现。
