Comparison of Windows Azure Storage Queues and Service Bus Queues

Update[01/17/2012]: MSDN now has a comprehensive list. Click Here

Note: Comparison list is slightly outdated with the new release of Windows Azure SDK 1.5 and as the products evolve.

Feature	Windows Azure Storage Queues	Service Bus Queues	Comments
Programming Models
Raw REST/HTTP	Yes	Yes
.NET API	Yes(Windows Azure Managed Library)	Yes(AppFabric SDK)
Windows Communication Foundation (WCF) binding	No	Yes
Windows Workflow Foundation (WF) integration	No	Yes
Protocols
Runtime	REST over HTTP	REST over HTTPBi-directional TCP	The Service Bus managed API leverages the bi-directional TCP protocol for improved performance over REST/HTTP.
Management	REST over HTTP	REST over HTTP
Messaging Fundamentals
Ordering Guarantees	No	First-In-First-Out (FIFO)	Note: guaranteed FIFO requires the use of sessions.
Message processing guarantees	At-Least-Once (ALO)	At Least-Once (ALO)Exactly-Once (EO)	The Service Bus generally supports the ALO guarantee; however EO can be supported by using SessionState to store application state and using transactions to atomically receive messages and update the SessionState. The AppFabric workflow uses this technique to provide EO processing guarantees.
Peek Lock	YesVisibility timeout: default=30s; max=2h	YesLock timeout: default=30s; max=5m	Windows Azure queues offer a visibility timeout to be set on each receive operation, while Service Bus lock timeouts are set per entity.
Duplicate Detection	No	Yes, send-side duplicate detection	The Service Bus will remove duplicate messages sent to a queue/topic (based on MessageId).
Transactions	No	Partial	The Service Bus supports local transactions involving a single entity (and its children). Transactions can also include updates to SessionState.
Receive Behavior	Non-blocking, i.e., return immediately if no messages	REST/HTTP: long poll based on user-provided timeout.NET API: 3 options: blocking, blocking with timeout, non-blocking.
Batch Receive	Yes(explicit)	Yes. Either (a) Implicitly using prefetch, or (b) explicitly using transactions.
Batch Send	No	Yes (using transactions)
Receive and Delete	No	Yes	Ability to reduce operation count (and associated cost) in exchange for lowered delivery assurance.
Advanced Features
Dead lettering	No	Yes	Windows Azure queues offer a ‘dequeue count’ on each message, so applications can choose to delete troublesome messages themselves.
Session Support	No	Yes	Ability to have logical subgroups within a queue or topic.
Session State	No	Yes	Ability to store arbitrary metadata with sessions. Required for integration with Workflow.
Message Deferral	No	Yes	Ability for a receiver to defer a message until they are prepared to process it. Required for integration with Workflow.
Scheduled Delivery	No	Yes	Allows a message to be scheduled for delivery at some future time.
Security
Authentication	Windows Azure credentials	ACS roles	ACS allows for three distinct roles: admin, sender and receiver. Windows Azure has a single role with total access, and no ability for delegation.
Management Features
Get Message Count	Approximate	No	Service Bus queues offer no operational insight at this point, but plan to in the future.
Clear Queue	Yes	No	Convenience functions to clear queue efficiently.
Peek / Browse	Yes	No	Windows Azure queues offer the ability to peek a message without locking it, which can be used to implement browse functionality.
Arbitrary Metadata	Yes	No	Windows Azure queues allow an arbitrary set of <key, value> pairs on queue metadata.
Quotas/Limits
Maximum message size	8KB	256KB
Maximum queue size	Unlimited	5GB	Specified at queue creation, with specific values of 1,2,3,4 or 5 GB.
Maximum number of entities per service namespace	n/a	10,000