- New plan sizes, including a smaller plan called Sassy Squirrel and a larger plan called Raging Rhino
- A new option to use 5-node clusters
- All plans are now priced by the number of nodes in the cluster
Sassy Squirrel and Raging Rhino
The Sassy Squirrel is our smallest single-tenant plan. It is designed to work as a dedicated test environment where users can add vhosts, change RabbitMQ plugins, use integrations, read logs, etc. just like on the bigger plans while remaining small, efficient, and cheap. Note that Sassy Squirrel is not designed to be used for production workloads as the memory is limited.
The Raging Rhino is our new, largest, 1-node plan. It is primarily designed for specific use cases where a large single environment is called for. For example, customers that are facing rapid growth and want to keep some headroom. Or customers that have a need for a very large amount of connections, or extremely high throughput scenarios.
With the introduction of quorum queues in RabbitMQ 3.8, it started to make sense to offer a cluster size larger than 3 nodes. The new 5-node cluster size is available starting from the Roaring Rabbit plan and up.
You can read more about Quorum Queues in our blog post: "The reasons you should switch to quorum queues".
Consistent virtual machine types
Our plans now use the same underlying virtual machine type and size for all nodes on a given plan. This makes capacity planning a lot easier, as users can now count on the same amount of resources being available on each node in a cluster. To the confusion of many users, this was not the case before; previously, users would get the most CPU cores and memory on the 1-node plan, roughly half on the 2-node plan, and much less on the 3-node plan. This also means that the price for a 3-node plan will be three times the price for a 1-node plan going forward.
Example: What was the old 3-node Roaring Rabbit is now 3-node Big Bunny. The price is the same (or two dollars cheaper per month, to be exact).
Sunsetting Old plans
We are removing the creation of 2-node plans for new customers, as they are not recommended from either a performance perspective or from an availability standpoint. Several features in RabbitMQ 3.8 also require a quorum (1, 3, 5, etc.) nodes.