This page defines terms that you will encounter throughout the documentation.
Database terms
Term | Definition |
---|---|
consistency | The requirement that a transaction must change affected data only in allowed ways. CockroachDB uses "consistency" in both the sense of ACID semantics and the CAP theorem, albeit less formally than either definition. |
isolation | The degree to which a transaction may be affected by other transactions running at the same time. CockroachDB provides the SERIALIZABLE isolation level, which is the highest possible and guarantees that every committed transaction has the same result as if each transaction were run one at a time. |
consensus | The process of reaching agreement on whether a transaction is committed or aborted. CockroachDB uses the Raft consensus protocol. In CockroachDB, when a range receives a write, a quorum of nodes containing replicas of the range acknowledge the write. This means your data is safely stored and a majority of nodes agree on the database's current state, even if some of the nodes are offline. When a write does not achieve consensus, forward progress halts to maintain consistency within the cluster. |
replication | The process of creating and distributing copies of data, as well as ensuring that those copies remain consistent. CockroachDB requires all writes to propagate to a quorum of copies of the data before being considered committed. This ensures the consistency of your data. |
transaction | A set of operations performed on a database that satisfy the requirements of ACID semantics. This is a crucial feature for a consistent system to ensure developers can trust the data in their database. For more information about how transactions work in CockroachDB, see Transaction Layer. |
multi-active availability | A consensus-based notion of high availability that lets each node in the cluster handle reads and writes for a subset of the stored data (on a per-range basis). This is in contrast to active-passive replication, in which the active node receives 100% of request traffic, and active-active replication, in which all nodes accept requests but typically cannot guarantee that reads are both up-to-date and fast. |
CockroachDB architecture terms
Term | Definition |
---|---|
cluster | A group of interconnected storage nodes that collaboratively organize transactions, fault tolerance, and data rebalancing. |
node | An individual instance of CockroachDB. One or more nodes form a cluster. |
range | CockroachDB stores all user data (tables, indexes, etc.) and almost all system data in a sorted map of key-value pairs. This keyspace is divided into contiguous chunks called ranges, such that every key is found in one range. From a SQL perspective, a table and its secondary indexes initially map to a single range, where each key-value pair in the range represents a single row in the table (also called the primary index because the table is sorted by the primary key) or a single row in a secondary index. As soon as the size of a range reaches 512 MiB (the default), it is split into two ranges. This process continues for these new ranges as the table and its indexes continue growing. |
replica | A copy of a range stored on a node. By default, there are three replicas of each range on different nodes. |
leaseholder | The replica that holds the "range lease." This replica receives and coordinates all read and write requests for the range. For most types of tables and queries, the leaseholder is the only replica that can serve consistent reads (reads that return "the latest" data). |
Raft protocol | The consensus protocol employed in CockroachDB that ensures that your data is safely stored on multiple nodes and that those nodes agree on the current state even if some of them are temporarily disconnected. |
Raft leader | For each range, the replica that is the "leader" for write requests. The leader uses the Raft protocol to ensure that a majority of replicas (the leader and enough followers) agree, based on their Raft logs, before committing the write. The Raft leader is almost always the same replica as the leaseholder. |
Raft log | A time-ordered log of writes to a range that its replicas have agreed on. This log exists on-disk with each replica and is the range's source of truth for consistent replication. |
For more information on CockroachDB architecture, see Architecture Overview.
CockroachDB deployment terms
Term | Definition |
---|---|
single tenant | A type of CockroachDB deployment where a single customer uses the database cluster. |
multi-tenant | A type of CockroachDB deployment where multiple customers share a single storage cluster. Each customer sees a virtual CockroachDB cluster. Data in each virtual cluster is isolated and is invisible to other customers. |
region | A logical identification of how nodes and data are clustered around geographical locations. A cluster region is the set of locations where cluster nodes are running. A database region is the subset of cluster regions database data should be restricted to. |
availability zone | A part of a data center that is considered to form a unit with regards to failures and fault tolerance. There can be multiple nodes in a single availability zone, however Cockroach Labs recommends that you to place different replicas of your data in different availability zones. |
CockroachDB Self-Hosted | A full featured, self-managed CockroachDB deployment. |
CockroachDB Cloud terms
Organization
In CockroachDB Cloud, an organization corresponds to an authorization hierarchy rooted linked to a billing account. The admins of the organization can add or invite other users to it.
To learn more, refer to Overview of the CockroachDB Cloud authorization model.
User
A CockroachDB Cloud user can belong to one or more organizations.
Organization users are granted permissions to perform organization and cluster administration functions through one or more roles: Organization user roles.
The concept of Organization user is distinct from SQL user/role in any given cluster.
Learn more: Overview of the CockroachDB Cloud authorization model.
Service Account
A service account is a type of identity similar to an Organization user, but is intended to be used for automation.
Service accounts authenticate with API keys to the CockroachDB Cloud API, rather than to the CockroachDB Cloud Console UI.
Service accounts operate under a unified authorization model with organization users, and can be assigned all of the same organization roles as users.
However, 'legacy service accounts' that were created before the updated authorization model was enabled for your cloud organization may have permissions assigned under the legacy model (like ADMIN, CREATE, EDIT, READ, DELETE). The legacy model for service accounts is now deprecated. It is recommended to update such service accounts with updated organization roles.
To learn more, refer to Manage Service Accounts.
CockroachDB Basic cluster
A CockroachDB Cloud cluster with minimal operational features deployed in shared network and compute infrastructure.
CockroachDB Standard cluster
A CockroachDB Cloud cluster with full operational features and provisioned capacity, deployed in shared network and compute infrastructure.
CockroachDB Advanced cluster
A CockroachDB Cloud cluster with full operational capacity deployed in a cloud provider's network and compute infrastructure dedicated to each customer. In addition to infrastructure isolation, Advanced clusters can be customized with advanced security features for PCI DSS and HIPAA compliance at an additional cost.
Request Unit (RU)
All cluster activity, including SQL queries, bulk operations, and background jobs, is measured in Request Units, or RUs. An RU is an abstracted metric that represents the compute and I/O resources used by a database operation. In addition to queries that you run, background activity, such as automatic statistics to optimize your queries or running a changefeed to an external sink, also consumes RUs. You can review how many request units your cluster has used on the Cluster Overview page.
Resource limits
The maximum amount of storage and RUs a CockroachDB Basic cluster can use in a particular billing period. The amount you are billed is based on the actual resources the cluster used during that billing period.
Storage
Disk space for permanently storing data over time. All data in CockroachDB Basic and Standard is automatically replicated three times and distributed across Availability Zones to survive outages. Storage is measured in units of GiB-months, which is the amount of data stored multiplied by how long it was stored. Storing 10 GiB for a month and storing 1 GiB for 10 months are both 10 GiB-months. The storage you see in the Cluster Overview page is the amount of data before considering the replication multiplier.