xtdb-core/xtdb.api.storage/Storage

Storage

Types

@Serializable

sealed interface Factory

Represents a factory interface for creating storage instances. The default implementation is InMemoryStorageFactory which stores data in memory

InMemoryStorageFactory

@Serializable

@SerialName(value = "!InMemory")

data class InMemoryStorageFactory(var epoch: Int = 0) : Storage.Factory

Default implementation for the storage module when configuring an XTDB node. Stores everything within in-process memory - a non-persistent option for storage.

LocalStorageFactory

@Serializable

@SerialName(value = "!Local")

data class LocalStorageFactory(val path: Path, var epoch: Int = 0) : Storage.Factory

Implementation for the storage module that persists data to the local file system, under the path directory.

RemoteStorageFactory

@Serializable

@SerialName(value = "!Remote")

data class RemoteStorageFactory(val objectStore: ObjectStore.Factory, var epoch: Int = 0) : Storage.Factory

Implementation for the storage module that persists data remotely within a specified objectStore,

Properties

VERSION

const val VERSION: StorageVersion = 6

Functions

applyStorage

fun DatabaseConfig.Builder.applyStorage(storage: Storage.Factory)

inMemory

@JvmStatic

fun inMemory(): Storage.InMemoryStorageFactory

local

@JvmStatic

fun local(path: Path): Storage.LocalStorageFactory

remote

@JvmStatic

fun remote(objectStore: ObjectStore.Factory): Storage.RemoteStorageFactory

storageRoot

@JvmStatic

fun storageRoot(version: StorageVersion, epoch: Int): Path

@JvmStatic

fun storageRoot(version: StorageVersion, epoch: Int, partition: Int, totalPartitions: Int): Path

The totalPartitions == 1 branch produces the same key-space as the pre-multi-partition layout, and must keep doing so — do not unify the two branches. An older version resolves against the unmarked root, so a single-partition database writing under parts/0/ would leave a rollback with nothing to read and a data migration to run at the worst possible moment. Avoiding a re-key of existing stores is the secondary benefit — blob stores have no mv primitive, so that means a full copy-and-delete sweep — but reversibility is the sharper reason. Only at N > 1 does the parts/<partition>/ grouping appear, and partition counts are immutable post-attach, so a store is one shape or the other for its whole lifetime and the two never collide.