Acronym for the database transaction properties of atomicity, consistency, isolation, and durability.

admin domain

One or more Admin Processes (APs) that are used to manage one or more databases. All databases in a domain are managed using the same APs. See also Admin Process (AP).

Admin Process (AP)

The process that manages database TE and SM process lifecycle and is a member of a single Admin domain. The AP also tracks the state of all database processes in the distributed system, replicates state information to other APs in the admin domain and provides client load balancing to Transaction Engines. An admin domain must contain at least one AP. Any additional APs join the domain by securely connecting (peering) into the domain by means of another AP. See also NuoDB Admin.

admin server

The server associated with an admin process (AP). See also Admin Process (AP).


The directory on a SM that is used to store a copy of the entire database or part of the database (if storage groups are used) on disk. The archive directory contains individual atom files. See also atom and Storage Manager (SM).

archive synchronization

When an SM joins a running database, or when a storage group is added to it, that SM must perform archive synchronization in order to ensure that its archive is up-to-date and consistent with the running database. During archive synchronization, the SM requests a copy of each out-of-date atom in its archive from another running SM.


The internal object structure representing all data and metadata in a NuoDB database. Atoms are self-coordinating objects that represent specific types of information (such as data, indexes, or schemas). Atoms are stored in memory on both TEs and SMs or serialized over the network and stored to disk by SMs. See also Storage Manager (SM).


A database transaction property that requires that either all processing done in a transaction is completed successfully or none of the processing in the transaction is done. In other words, if a transaction is unable to complete all its processing then the database state is returned to what it was before the transaction started.


An engine process handling concurrent access to an Atom. The chairman is the first TE in the node list unless there are no TEs in the node list, then it is the first SM in the node list. The node list is the list of SMs and TEs caching the atom. The node list is typically in the temporal order in which the engines cached the Atom.

cold restart

For a given database, all processes are shut down before the database is restarted.

Community Edition (CE)

The Community Edition of NuoDB is a fully functional version of NuoDB whose license is limited to three TEs and one SM. The Community Edition is free of charge and allows you to self- evaluate NuoDB through a series of quick-start guides and/or build and run your applications on your own laptop, desktop, or in the cloud.


A database transaction property that ensures that the database is in a valid state after a transaction. For example, consider a transaction that moves money from account A to account B. The total of both accounts must be the same before the transaction and after the transaction.

continuous availability

The ability of a NuoDB database to continue working if one or more hosts shut down. Active transactions on failed hosts are aborted, and errors are reported to clients. Active transactions on surviving hosts are not disrupted.

continuous data protection

Saving and storing database snapshots provides continuous data protection because each snapshot provides a virtual copy of the entire database. A snapshot shows what the database looks like at that point in time.


A NuoDB database is a variable number of transaction engine processes and storage manager processes running on a variable number of hosts. Each process can be referred to as a node. A database is a set of nodes. A database can be served by any number of transaction engines and storage managers. Each transaction engine and each storage manager serves one database. For example, a database could run on Amazon and on machines at the customer site, each with separate administration of the physical machines.

database administrator

A Database Administrator (DBA) is responsible for creating and managing database schemas, creating and managing indexes, monitoring database performance by using the Automation Console and NuoDB system tables, resolving performance issues by adjusting application behavior, adjusting indexes, or working with the domain administrator to deploy additional resources for a database.

database object

In a database, any defined object that is used to store or reference data. Some examples of database objects include tables, views, sequences, and indexes.

distributed database

A distributed database is a database that is composed of multiple processes which can be deployed across multiple shared-nothing servers within a single or across multiple locations.


A collection of machines or cloud instances that have been provisioned to work together to support NuoDB databases. A domain can contain many databases and each database can run on one or more hosts.

domain (NuoDB)

A set of peers.

domain (SQL)

A standard user-defined field type in SQL. For example, define a domain named MONEY as NUMERIC(15,2). You can then define fields as being of type MONEY.

domain administrator

A user responsible for provisioning a set of hosts where NuoDB runs and monitoring the overall health of the domain.

domain configuration

The domain configuration provides domain configuration information that is stored consistently on each NuoDB Admin process (AP) in the domain by means of a Raft log.


A database transaction property that ensures that changes made during a transaction are persistent and can be re-created in case of a system failure. NuoDB ensures durability by means of the storage manager processes, the archive directory, and the journal directory.

Enterprise Edition (EE)

The Enterprise Edition of NuoDB is a licensed version of NuoDB with no restrictions. For information on an edition of NuoDB that can be used for evaluation, refer to information on the Community Edition.

hot copy

A mechanism for copying a database’s archive and journal from one of the database’s running storage managers (SM). The advantage of a hot copy is that it is an online procedure. Your database remains running and available during the hot copy operation. See also Storage Manager (SM).


The journal is NuoDB’s write ahead log, which is used by databases to recover data in case of a SM failure. It stores all transactions that change the state of any atom. These changes are subsequently applied to the archive and then purged from the journal.


The leader admin process (AP) is elected by the Raft Consensus Algorithm to determine the AP majority. The leader AP performs the liveliness checks for the domain and determines if another AP is no longer responding. All safe operations require acknowledgements from an AP majority. See also Admin Process (AP).

load balancing

The act of distributing workload among multiple processes. In NuoDB, the AP manages load balancing of SQL connections to transaction engines (TEs). See also Transaction Engine (TE).

management tier

The architectural tier managed using NuoDB Admin.

storage password

The user must configure a storage password in order to enable Transparent Data Encryption in a database. This password must be given to NuoDB Admin before the database can be started, and it must be given to NuoDB Archive in order to check an archive or restore a backup set.


The membership is the list of admin processes (APs) that have been provisioned and are part of the NuoDB domain. This list is stored on disk and its content is agreed on by consensus. It is important to note that an AP can be shut down but remain in the durable membership while it is unconnected.

Multi Host

A NuoDB template that can be selected when creating a database. The default behavior is that it starts two storage managers and as many transaction engines as possible. Each host will have at most one SM and one TE so this template can be used for any number of hosts. A process is restarted on a new host if a host goes offline and another host is available.

Multi Version Concurrency Control (MVCC)

Multi-Version Concurrency (MVCC) is a form of concurrency control that uses multiple versions of records to provide a consistent view of the data to each transaction and to prevent concurrent transactions from overwriting each other’s changes. Under MVCC, readers do not block writers, and vice-versa.


Ability for one NuoDB domain to host more than one database.

No Dials administration

"No Dials" is a term that implies, even for a complicated system, that there is sufficient automation and intelligence in the system to reduce operational overhead.

NuoDB Admin

The NuoDB Admin layer used to manage domain and database configuration. See also Admin Process (AP).

NuoDB Archive

NuoDB Archive (nuoarchive) is a command line utility that can do the following: (1) Clean, validate, and (if needed) repair archives (nuoarchive check). (2) Restore an archive from a hot copy backup set (nuoarchive restore).

NuoDB Command

NuoDB Command (nuocmd) is a command line tool that enables you to control, monitor, and analyze a NuoDB domain.

NuoDB Durable Distributed Cache (DDC)

Architecture that scales dynamically, has no single point of failure and delivers ACID transaction properties.

NuoDB Loader

A command line tool for importing and exporting data.

NuoDB Migrator

A command line Java program that helps database administrators migrate schemas and existing data to a NuoDB database. It interfaces with a source database over a JDBC compliant driver and is designed to support all major RDBMSs. It also interfaces with the NuoDB target database using the NuoDB JDBC driver. NuoDB Migrator can be used as a NuoDB backup/restore utility where both the source and target databases are NuoDB.


NuoDB SQL (nuosql) is a command line tool for exploring NuoDB databases. It enables you to execute SQL statements interactively, run batch scripts, access database metadata information, and perform DBA functions.


A domain must contain at least one admin process (AP). Any additional APs join the domain by securely connecting (peering) into the domain by means of another AP. The admin processes communicate with each other to make sure they are still accessible and available. Peering is configured using the nuoadmin.conf file on each host. On each host, the value of the peering property value used is the hostname and port of the host machine running the initial AP.

pseudo system table

Pseudo system tables contain data that is generated by NuoDB processes every time you query it. This data does not exist in this form in persistent storage but is presented as a SQL table. For example, SYSTEM.QUERYSTATS and SYSTEM.NODES are pseudo system tables. A pseudo system table is not a database table object. You cannot create one nor can you use DML to operate on one. You can only select from and read the data in a pseudo system table. Not to be confused with temporary table.


In a domain, a quorum is the minimum number of admin processes (APs) that must acknowledge a change to the durable domain configuration for that change to be made. Usually this is a simple majority. Many operations in the management tier require acknowledgement from a majority of APs in the domain in order to ensure safety (never returning an incorrect result) in case of failure.

raft log

A raft log file is created when a NuoDB Admin process (AP) is started. This file contains domain and database lifecycle state information.

redundancy zone

Redundancy zones are physically separated Data Centers that are in close proximity (low latency) to each other, within a region. A virtual network is provided to allow an IP subnet to span redundancy zones. To create a fault-tolerant database system, it is common to deploy one or more of each NUODB process type (AP, TE or SM) within each redundancy zone. Similar functionality is also available in containerized deployments of NuoDB using AWS Availability Zones or Kubernetes Fault Zones.

reserved keywords

Keywords reserved by the NuoDB SQL (nuosql) dialect. For details of keywords, see SQL Reference


Never returning an incorrect result.

scale-out performance

In contrast to scale-up performance, which increases performance capacity by adding resources to a single server, scale out increases performance capacity by adding new independent servers or VMs.

Service Level Agreement (SLA)

A contract between two or more parties that defines services to be delivered. NuoDB templates are an example of an SLA.

Single Host

A NuoDB template that can be selected when creating a database. The default behavior is that it starts one storage manager (SM) and one transaction engine (TE) on a host that you specify. These processes are fixed to that host and are not moved if that host goes offline.

storage group

A storage group represents a logical storage unit that can be managed by one or more storage managers in a database. Full tables or table partitions can be assigned to a storage group.

Storage Manager (SM)

The database process responsible for persisting data for a given database to disk. SMs can maintain a full copy or one or more partitions of the data. SMs process SQL data change or insert requests from Transaction Engines (TEs) which send asynchronous messages to the appropriate other SMs to commit data to disk and to maintain copies of data in memory. A minimally viable deployment of NuoDB must have at least one SM running. Further, each SM is associated with exactly one database. However, a database can have more than one SM.

storage tier

This is the architectural tier where data is stored and managed through objects called atoms. Storage managers are part of the storage tier in NuoDB’s architecture. See also Storage Manager (SM).

system tables

In every NuoDB database, system tables are persistent tables that are stored in the SYSTEM schema. System tables contain important data shared across all processes in the NuoDB domain and available to all connections to the database. This includes information about database objects such as tables, indexes, schemas, triggers, users, roles, and privileges.

temporary table

A database object that resides in memory for only the current connection. You can define a temporary table with a CREATE TABLE statement and you can operate on it with DML. A temporary table can be dropped during a session. Not to be confused with pseudo system table.

tie-breaker TE

Used to help maintain admin process (AP) quorum. It is possible to set up one or more transaction engines so that they no longer service SQL clients but exist solely to make up a quorum. See also quorum, and Transaction Engine (TE).

Transaction Engine (TE)

TEs provide your application with access to a specific NuoDB database. Client connections are established on a specific TE after being load balanced by the Admin Process (AP). TEs execute client application SQL requests, serving as an in-memory data cache, and coordinate transaction execution with other TEs and Storage Managers (SMs). TE processes can be added or removed dynamically without impacting application access to the database. A minimally viable deployment of NuoDB must have at least one TE running. A TE only ever manages data associated with a single database. However, a database can have more than one TE.

transaction tier

The architecture tier where transactions are managed to preserve database atomicity, consistency, and isolation. Transaction engines are part of the transaction tier in NuoDB’s architecture. See also Transaction Engine (TE).

Transparent Data Encryption (TDE)

Enabling TDE for a database ensures that all user data is encrypted before being written to disk. This includes user data in the archive, as well as data in the journal and in spill-to-disk files.