Each delivery queue can be in-RAM or backed by persistent storage. Both types of queues will buffer messages if the subscriber is not available. Additionally, the latter case is called a Guaranteed Delivery (GD) queue because its contents will be available even if all Zato servers go down which is not the case with in-RAM queues.
In-RAM queues are limited by the amount of RAM available for Zato servers. GD queues store their data in an SQL database and are limited by the disk space assigned to the database. In other words, neither in-RAM nor GD queues have any intrinsic length limits other than what the underlying hardware is limited to.
GD queues will withstand a full restart of all Zato servers in a given environment because all of their data is kept in an SQL database. Conversely, in-RAM queues have no persistent storage so restarting servers will mean all their messages will be lost.
Subscriptions may be explicitly created by administrators or, if allowed to, applications may subscribe through dedicated API calls.
Zato uses an SQL database for persistent storage of guaranteed delivery queues. This is the same database that the platform's other tables are kept in. Standard SQL tools and facilities may be used to backup and move publish/subscribe data if needed.