> For the complete documentation index, see [llms.txt](https://stephen-tsoi.gitbook.io/stephen-tsoi-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://stephen-tsoi.gitbook.io/stephen-tsoi-docs/messaging-technology/messaging-bus-comparison-series/comparison-3-persistent-vs.-non-persistent-connection.md). # Comparison #3: Persistent vs. Non Persistent Connection Welcome to the third edition of the **Messaging Bus Comparison Series**. Over the past few months, I've been researching and comparing some of the most widely adopted messaging platforms used in modern enterprises, cloud-native systems, and event-driven architectures. The goal is to produce a practical and vendor-neutral reference for architects, developers, and platform engineers. Before finalizing the content, I'd like to validate the research with the community and incorporate real-world practitioner feedback. ### Persistent vs Non-Persistent Messaging One of the most important reliability considerations in messaging systems is the choice between **Persistent** and **Non-Persistent** messaging. The decision directly impacts durability, recovery behavior, throughput, latency, and operational complexity. ### Persistent Messaging In a Persistent Messaging model: * Messages are stored durably before acknowledgement. * Messages can survive broker restarts and infrastructure failures. * Higher reliability is achieved through disk persistence and replication. * Typically introduces additional storage and processing overhead. Common use cases: ✅ Financial Transactions\ ✅ Order Processing\ ✅ Audit & Compliance Events\ ✅ Critical System Integration\ ✅ Guaranteed Message Delivery ### Non-Persistent Messaging In a Non-Persistent Messaging model: * Messages are typically stored only in memory. * Messages may be lost if the broker or infrastructure fails. * Lower latency and higher throughput can be achieved. * Optimized for scenarios where occasional message loss is acceptable. Common use cases: ✅ Real-Time Monitoring\ ✅ Market Data Distribution\ ✅ IoT Telemetry\ ✅ Live Dashboards\ ✅ Transient Notifications ### Comparison Table
ProductPersistent MessageNon-persistent Message
ActiveMQYes (controlled by publisher)Yes (controlled by publisher)
AWS SQS QueueYesNo
Azure Queue StorageYesNo
Azure Service BusYesNo
EMQXYesYes
IBM MQYesYes
KafkaYes (Topic/Queue)No
RabbitMQ
Solace PubSub+Yes (Queue)Yes (Topic)
Tibco EMSYesYes
### Community Review Requested I'd greatly appreciate your feedback: * Are any entries inaccurate or outdated? * Are there important considerations missing from the comparison? * Have you observed different behaviors in real-world implementations? * Are there platform-specific exceptions or caveats worth highlighting? * Which messaging products do you think are represented incorrectly? ### Contribute to the Research If you've worked with any of the following: \#Kafka #RabbitMQ #Solace #IBMMQ #ActiveMQ #EMQX #AWSSQS #AzureServiceBus #AzureQueueStorage #TIBCOEMS I'd be especially interested in your real-world experience. ### Research Progress 🟩 Completed: 3 / 17 ✅ #1 Push vs Pull ✅ #2 Point-to-Point vs Pub/Sub ✅ #3 Persistent vs Non-Persistent Connection Upcoming: ⏭️ #4 Persistent vs Non-Persistent Delivery ⏭️ #5 Temp Queue ⏭️ #6 Non-Persistent vs Direct Message Thank you in advance for helping improve the accuracy and usefulness of this research series. I'll summarize key feedback and corrections in future editions.
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://stephen-tsoi.gitbook.io/stephen-tsoi-docs/messaging-technology/messaging-bus-comparison-series/comparison-3-persistent-vs.-non-persistent-connection.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.