Deployment Planning
The first step is defining your deployment topology. The optimal topology depends on your workload profile, performance objectives, and storage requirements. RegattaDB supports a wide range of deployment configurations, allowing the system to be tailored to your specific requirements. General deployment guidelines:- Management Modules
- SM - Deploy a single SM module for every RegattaDB system
- SNA - Deploy one agent on every node that hosts at least one Operational Module
- Operational Modules
- GDD, DCM, Sequencer - Deploy one instance of each module per RegattaDB system
- RDB - Deploy at least one RDB module per RegattaDB system
Single Node
A single-node deployment consists of a single server hosting all RegattaDB modules:
Multi-Node – Classic
The most common multi-node deployment uses the following topology:- One node hosts all RegattaDB modules, as in a single-node deployment.
- All additional nodes host both the RDB and SNA modules.
.png?fit=max&auto=format&n=VuokPZuqXze_5IUL&q=85&s=2be8f9820e0ee34dd1421e5fb3be6693)
For guidance on sizing and configuring your RegattaDB deployment, refer to Best Practices or contact Regatta Support for assistance.
Provision the Deployment Nodes
Next, provision the nodes that will host your RegattaDB deployment, ensuring that each node meets the minimum hardware, storage, networking, and software prerequisites. The exact hardware requirements depend on your deployment topology and workload characteristics. For guidance on sizing your deployment, refer to Best Practices or contact Regatta Support for assistance.Download the RegattaDB Software
Next, download the RegattaDB software package. RegattaDB is distributed as a set of RPM packages, each corresponding to a specific module or utility. Copy the required RPM packages to the nodes on which they will be installed according to your planned deployment topology. The following example shows the contents of a RegattaDB software package.Deployment Software
Each of the RPM packages below corresponds to one of the six RegattaDB modules.EULA Acceptance
Before deploying RegattaDB, you must read and accept the Regatta End User License Agreement (EULA). Acceptance of the EULA is integrated into the RPM installation process and is required before the installation can be completed.- Interactive installations (for example, using
yum installordnf install) - You will be prompted to review and accept the EULA during installation - Automated installations - Set the environment variable
ACCEPT_EULA=1to indicate acceptance of the EULA and suppress the interactive prompt.
Install the RPM Packages
Install the required RegattaDB RPM packages usingyum or dnf:
ACCEPT_EULA=1 environment variable:
/opt/regatta/<major.minor>. For convenience, you can use the /opt/regatta/current symbolic link to reference the current installation. The examples below show the installation directories for the SM and RDB modules.
SM:
Additional RegattaDB RPM Packages
In addition to the RegattaDB software modules, the RegattaDB self-hosted package includes several utilities that simplify deployment, administration, backup, and troubleshooting. The following RPM packages are included:- Regatta Deployment Tool (RDT) - An automated deployment tool for provisioning and configuring RegattaDB clusters. For detailed instructions, refer to the Regatta Deployment Tool (RDT) guide.
- Regatta Debug Tool - A Docker-based utility for connecting to running RegattaDB clusters to perform live diagnostics, troubleshooting, and debugging.
- Regatta Bench - A benchmarking utility for executing preconfigured workloads against a RegattaDB cluster to evaluate performance and validate deployments.
Client Software
The self-hosted deployment package also includes the RegattaDB client components. For installation and usage instructions, refer to Drivers & Clients. The following RPM packages are included:- Regatta Client Library
- Regatta CLI
- Regatta Connect - A collection of drivers, ORMs, and connectors for integrating RegattaDB with external applications, frameworks, and data platforms.
Storage Devices
RegattaDB is designed to work directly with raw block storage devices to minimize filesystem overhead and achieve the highest possible storage performance. Direct access to raw devices allows RegattaDB to optimize data layout and I/O patterns specifically for database workloads.Storage Requirements
Each RDB module must be assigned at least one storage device that is not used as the operating system boot device. RegattaDB supports virtually any raw block storage device, including:- Local NVMe devices (recommended for best performance)
- Local SSD devices
- SAN-attached block storage (Fibre Channel, iSCSI, etc.)
- Cloud block storage volumes (for example, Amazon EBS, Azure Managed Disks, or Google Persistent Disk)
- Shared block storage presented to the operating system as a raw block device
Using Filesystem-Backed Storage
Although direct raw block devices are recommended, RegattaDB can also use file-backed storage devices when raw devices are not available. In this configuration, a regular file located on a mounted filesystem is presented to RegattaDB as a storage device. For example, the following command creates a sparse 1 TB file on an existing filesystem:Persistent Module State
Each RegattaDB module maintains a small amount of persistent state under its repository directory:Storage Permissions
The deployment user must have read and write access to all storage devices used by RegattaDB. For raw block devices, assign ownership to the deployment user and group before deployment:Deployment User
RegattaDB requires a deployment user with the appropriate ownership and permissions for the installation directories, shared memory, log directories, and storage devices. The deployment owns the following resources:- Regatta installation directory -
/opt/regatta- created during RPM installation - Shared memory directory -
/dev/shm/Regatta- created automatically by RegattaDB at runtime - Log directory -
/var/log/regatta- created during RPM installation - Storage devices allocated for RegattaDB
regatta. If you wish to use a different deployment user, follow these steps:
Installing with a Custom Deployment User
To install RegattaDB with a custom deployment user and/or group, set theREGATTA_USER and REGATTA_GROUP environment variables when installing the RPM package. Each RPM creates the OS user/group if it doesn’t already exist, and applies ownership of its installed files to it.
REGATTA_USER and REGATTA_GROUP must:
- Not be empty
- Not be
root - Start with a letter or underscore, and contain only letters, digits,
.,_, or-
regatta.
Example
Given the following RPM packages:
myuser/mygroup:
myuser/mygroup don’t already exist on the system, they are created automatically as a system account (no login shell, no home directory).
IP Assignment
Assign IP addresses to each node in the RegattaDB cluster. Prepare a list of:- Internal IP addresses used for communication between RegattaDB modules.
- External IP addresses used by client applications to access RegattaDB (if applicable).
Note: RegattaDB clients automatically use the external IP address when one is configured for a node. Otherwise, they fall back to the node’s internal IP address.
- A Communications Port, used for communication between RegattaDB modules.
- A Service Port used for internal service operations.
Firewall Setup
Configure the firewall on each node to allow traffic on the required RegattaDB IPs and ports. At a minimum, ensure that:- The communications and service ports are accessible between all RegattaDB nodes.
- Client applications can access the required external endpoints, as defined by your deployment.

