Instance Versions

This section compares Distributed Message Service (DMS) for RocketMQ versions and the instance types and architectures supported by each version.

Instance Types and Architectures

**Table 1** Instance types and architectures
Version	Type	Architecture
4.8.0	Professional	Cluster
5.x	Basic	Single-node
	Basic	Cluster
	Professional (In OBT)	Single-node
	Professional (In OBT)	Cluster

Any fault with a single-node instance may affect service SLA and make services unavailable. However, single-node instances are cost-effective so they are suitable for testing.

V5.x Advantages

Compared to v4.8.0, v5.x has the following advantages:

Advanced architecture
V5.x comes with stateless proxies so proxy access is no longer a problem. V5.x provides POP consumption, which can reduce consumption accumulation.
Easy development
SDKs in multiple languages that support gRPC protocol are available. APIs are simple and friendly.
Flexible cost
Smaller flavors are available. Elastic scale-up helps reduce costs. Flexible TPS is available in the professional edition. This feature can handle occasional and small traffic bursts.
Better compatibility
V5.x is compatible with RocketMQ v4.8.0 SDKs, allowing for seamless upgrade.

Comparing Basic and Professional Editions

Table 2 lists the differences between them.

**Table 2** Differences between basic and professional editions
Dimension	Basic	Professional
Intended user	Entry-level users who are sensitive to costs	Professional, enterprise users who require high stability and performance
Positioning	Open-source compatibility; basic RocketMQ functions	Enterprise-grade features such as service high availability (HA), data security, and channel encryption
Function	Message sending and receiving Normal, ordered, transactional, and scheduled messages Message tracing SSL ACL	Message sending and receiving Normal, ordered, transactional, and scheduled messages Message tracing SSL ACL Flexible TPS
Availability	Multi-AZ	Multi-AZ
Resource deployment	Resource sharing Underlying physical resources are in shared deployment. TPS can be achieved for corresponding flavors, but may be unstable with extreme loads.	Exclusive resource Underlying physical resources are exclusively deployed for stable performance, reliability, and availability.

Comparing Single-node and Cluster Instances

**Table 3** Differences between single-node and cluster instances
Dimension	Single-node	Cluster
Environment	Development, which has no requirement on performance and reliability	Production, which requires HA and no SPOF
Architecture	HA is supported by ECS, but cannot be ensured if ECS faults occur.	Distributed HA supports failover.
SLA	None	Reference SLA
Limitation	The storage space can be changed. The flavor cannot be changed. Versions cannot changed.	The storage space and flavor can be changed. Versions cannot changed.