> For the complete documentation index, see [llms.txt](https://docs.xrpl-commons.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.xrpl-commons.org/core-dev-bootcamp/module03/storage-backends.md).

# Storage Abstraction and Backend Implementations

[← Back to SHAMap and NodeStore: Data Persistence and State Management](/core-dev-bootcamp/module03.md)

***

### Introduction

This chapter explains the NodeStore storage abstraction and available backends in Rippled. You will learn how to choose between RocksDB, NuDB, and testing backends, configure them for optimal performance, and understand the standardized encoding format that ensures backend interoperability. Practical guidance on tuning and migration is also provided to help maintain reliable and efficient ledger storage.

## Quick Reference

### RocksDB (Recommended)

**When to use:**

* General-purpose validators
* Balanced performance and simplicity
* Standard configurations

**Configuration:**

```ini
[node_db]
type = RocksDB
path = /data/rippled.db
cache_size = 256
```

**Performance:**

* Write throughput: 10,000-50,000 objects/sec
* Compression: 50-70% disk space savings
* Good for: Most deployments

### NuDB (High-Performance)

**When to use:**

* High-transaction-volume networks
* Maximum write throughput needed
* Modern SSD storage

**Configuration:**

```ini
[node_db]
type = NuDB
path = /data/nudb
```

**Performance:**

* Write throughput: 50,000-200,000 objects/sec
* Optimized for: Sequential writes
* Good for: Archive nodes, heavily-used validators

### Testing Backends

* **Memory**: In-memory, non-persistent (testing only)
* **Null**: No-op backend (unit tests)

## Encoding Format Reference

The standardized encoding format enables backend independence:

**Structure (from Chapter 6):**

```
Bytes 0-7:   Reserved (set to zero)
Byte 8:      Type (NodeObjectType enumeration)
Bytes 9+:    Serialized data payload
```

This format is handled transparently by the Database layer, but understanding it is important for:

* Backend implementation
* Data corruption diagnosis
* Migration between backends

## Configuration Tuning

### RocksDB Options

```ini
[node_db]
type = RocksDB
path = /var/lib/rippled/db/rocksdb
cache_size = 256        # Cache size in MB
cache_age = 60          # Age limit in seconds

# Performance tuning
compression = true      # Enable compression
block_cache_size = 256  # Block cache in MB
write_buffer_size = 64  # Write buffer in MB
max_open_files = 100
```

### NuDB Options

```ini
[node_db]
type = NuDB
path = /var/lib/rippled/db/nudb

# NuDB specific
key_size = 32           # Key size (always 32 for SHA256)
block_size = 4096       # Block size for writes
```

## Migration Between Backends

To migrate from one backend to another:

```bash
# 1. Stop the server
systemctl stop rippled

# 2. Export from current backend
rippled --export current_db export.json

# 3. Update configuration
# Change [node_db] type in rippled.cfg

# 4. Import to new backend
rippled --import export.json --ledger-db new_db

# 5. Restart server
systemctl start rippled
```

## For Detailed Reference

See the following sections of Chapter 6:

* "Backend Abstraction" - Interface design
* "Supported Backends" - Feature comparison
* "Data Encoding Format" - Serialization details

For implementation details, consult:

* `rippled/src/xrpld/nodestore/Backend.h`
* `rippled/src/xrpld/nodestore/Database.h`
* `rippled/src/xrpld/nodestore/backend/*Factory.cpp`