---
title: "Data model"
description: "Overview of the Aerospike schemaless data model: namespaces, records, sets, bins, and physical storage options."
---

# Data model

> For the complete documentation index see: [llms.txt](https://aerospike.com/docs/llms.txt)
> 
> All documentation pages available in markdown.

This page describes the components of the Aerospike data model and the relationships among them.

## Components of the Aerospike schemaless data model

The Aerospike database does not require a traditional RDBMS schema. Rather, the data model is determined through your use of the system. For example, if you wanted to add a new data type to a record, you would write that data type into the record without having to first update any schema.

 ![Conceptual components of Aerospike data model](https://aerospike.com/docs/_astro/namespace_object_relationships.rFILPxXD_Z10VY4d.png)

Figure 1: Conceptual components of Aerospike data model

| Component | Description |
| --- | --- |
| physical storage | You can choose the specific type of storage you want for each namespace: NVMe Flash, DRAM, or Intel Optane Persistent Memory (PMem). Different namespaces in the same cluster can use distinct types of storage. The physical storage medium is also called the _storage engine_. |
| namespace | Similar to a _tablespace_ in an RDBMS, a namespace is a collection of records that share one specific storage engine, with common policies such as replication factor, encryption and more. A database can contain multiple namespaces. |
| record | A record is an object similar to a _row_ in an RDBMS. It is a contiguous storage unit for all the data uniquely identified by a single key. |
| set | Records can be optionally grouped into sets. Sets are similar to _tables_ in an RDBMS, but without an explicit schema. |
| bin | A record is subdivided into bins, which are similar to _columns_ in an RDBMS. Each bin has its own [data type](https://aerospike.com/docs/develop/data-types/blob), and those do not need to agree between records. Secondary indexes can optionally be declared on bins. |

### Physical storage

Varieties of physical storage are discussed in [Hybrid storage](https://aerospike.com/docs/database/8.0.0/learn/architecture/hybrid-storage).

### Namespaces

_Namespaces_ are top-level data containers. The way you collect data in namespaces relates to how the data is stored and managed. A namespace contains records, indexes, and policies. Policies dictate namespace behavior, including:

-   How data is physically stored.
-   How many replicas exist for a record.
-   When records expire.

For more information, see [Configuring namespaces](https://aerospike.com/docs/database/8.0.0/manage/namespace).

A database can specify multiple namespaces, each with different policies to fit your application. You can consider namespaces physical containers that bind data to a storage device.

A database can exist with multiple namespaces, _ns1_, _ns2_, and _ns3_, each with its own storage engine.

-   _ns1_ stores records on Flash/SSD.
-   _ns2_ stores records in DRAM (in-memory).
-   _ns3_ stores records in PMem.

 ![Namespaces with different storage engines](https://aerospike.com/docs/_astro/namespaces_and_storage_types.BfJUPTvo_1ebogB.png)

Figure 2: Namespaces with different storage engines

### Sets

In namespaces, records can belong to an optional logical container called a _set_. Sets allow applications to logically group records in collections. Sets inherit the policies defined by their namespace. You can define additional policies or operations specific to the set. For example, secondary indexes can be specified for a particular set, or a scan operation can be done on a specific set.

Records in the namespace do not have to be in a set, and instead just belong to the namespace. Figure 3 shows two sets, _people_ and _places_, that belong to the _ns1_ namespace, which also contains records not in a set.

 ![Namespace with two sets](https://aerospike.com/docs/_astro/model_set_small.C5cH9EtR_Z1eNCp5.png)

Figure 3: Namespace with two sets

### Records

A record is the basic unit of storage in the database. Records can belong to a namespace or to a set within the namespace. A single record is uniquely identified by a key. Records are composed of:

| Component | Description |
| --- | --- |
| key | The unique identifier of the record. Records can also be accessed by the digest, a unique object identifier created by the client hashing the key. |
| metadata | Contains version information (generation count), the record’s expiration (time-to-live or TTL), and last update time (LUT). |
| bins | Bins store the record data. The data type of the bin is set by the value of the data it contains. Multiple bins (and data types) can be stored in a single record. |

#### Keys and digests

Using the client, the application performs operations on records stored in the database, by providing the key (or digest) of the record, and one or more operations (in an atomic transaction).

#### Metadata

Each record contains the following metadata:

-   A generation count tracks a record modification cycle, its “lineage”. The generation count is returned to the application on reads, which can use it to ensure that the data to be written has not been modified since the last read, using a check-and-set (CAS) pattern.
-   Time-to-live (TTL) specifies an optional expiration time for the record. As of Aerospike database version 4.9.0, expirations are disabled by default. If a TTL is used, it will reset every time the record is written. For server version 3.10.1 and above, the client can set a policy to not modify the TTL when updating the record.
-   last-update-time (LUT) specifies the timestamp of when the record was updated. This metadata is internal to the database and not directly returned to the client.

#### Bins and data types

The record data is stored in bins. Bins consist of a name and a value. Bins do not specify the data type, rather the data type is defined by the value contained in the bin. This dynamic data typing provides flexibility in the data model. For example, a record can contain the bin _id_ with the string value _bob_. The value of the bin can always change to a different string value, but it can also change to values of a different data type, such as integer.

There is no schema, so each record can have its own varied set of bins. You can add and remove bins at will.

Bin values can be any one of the [native supported data type](https://aerospike.com/docs/develop/data-types/blob).

For details about upper bounds for bins, see [Upper sizing bounds and naming](https://aerospike.com/docs/database/reference/limitations).