Load Balancing: Brokers, TEs and SMs


How is a workload distributed to a NuoDB database? How can this be configured for reliability and performance?



NuoDB operates at three levels. Brokers receive client connections and assign them to Transaction Engines (TEs). TEs then process user queries, accessing Storage Managers (SMs) as necessary.

The lowest level is the relationship between TEs and SMs. This is handled automatically by the database.

The level above that is the relationship between the brokers and TEs. This can be configured as documented at


The default is the ChainableModBalancer, which allows the client to repeatedly route SQL connections to the same TE as long as the set of TEs serving the database remains constant.

The highest level is how clients connect to brokers. Clients generally allow multiple brokers to be specified. For instance, the NuoDB JDBC driver allows multiple brokers to be specified in the connection string like


As brokers are not performance-intense, this is generally done for reliability. As only one broker is required for the database to be accessible, if multiple are specified the broker is rarely a point of failure (generally the TEs will lose majority before all n brokers become inaccessible).

A typical concern when creating the connection string is how to avoid hard-coding broker addresses in the application code, and there are several ways of doing this.

  1. If host names are used in the connection string, a DNS, Route53 or lookup service such as consul can be used to map broker host names to physical addresses
  2. A dependency service such as Spring or Guice can be used to configure the connection string from a properties file on disk
  3. The connection string can be configured by a directory service such as JNDI


Have more questions? Submit a request