Struct StoreConfig 

pub struct StoreConfig {
    pub backend: StoreBackend,
    pub owned_shards: Vec<usize>,
    pub data_dir: Option<String>,
    pub shard_count: usize,
    pub cluster: Option<ClusterConfig>,
    pub node_cache_budget: Option<NodeCacheBudget>,
    pub lock_acquisition_patience_ms: Option<u64>,
    pub lock_acquisition_retry_cadence_ms: Option<u64>,
    /* private fields */
}

Event-store backend configuration from [store].

Fields

backend: StoreBackend

Selected backing store implementation.

owned_shards: Vec<usize>

Static distribution-shard assignment for this node (multi-shard active-active). When empty (the default) the node owns ALL shards — the single-node default, byte-identical to today. When set, the engine boot path scopes recovery and enumeration to exactly these shards. The single-shard memory backend ignores the assignment; it is meaningful only for a sharded backend. No election is performed: assignment is static config.

data_dir: Option<String>

Filesystem data directory for the haematite backend. Required when backend = haematite; ignored by every other backend. The directory is opened if it already holds a haematite database, otherwise created.

shard_count: usize

Number of haematite shards to create on a fresh database. Defaults to 64.

This is an IMMUTABLE virtual-shard count: nodes own shard ranges and routing is BLAKE3(key) % shard_count with no reshard path, so a single-node deployment can later grow into a cluster WITHOUT a data migration — but only up to shard_count nodes, and the value is fixed at create.

The default was briefly 4096 on the premise that lazy shard-actor materialization (haematite >= 0.4.0) made a high count ~free. That premise fails in practice (#187): aion-server’s boot restores packages/routes/namespaces via full-prefix scans, which materialize EVERY shard, and haematite 0.4.0 then fans each commit out to every materialized shard with an unconditional fsync — ~2 fsyncs x 4096 per logical commit — blowing the 5s shard-actor timeout and bricking deploy/start/timers/outbox on a fresh server. Re-raise only after haematite makes commit O(dirty shards) and the scaffold e2es pass at the new default. Set explicitly (config or AION_STORE_SHARD_COUNT) to override. Ignored by every other backend, and ignored when opening an existing haematite database (the on-disk shard count wins).

cluster: Option<ClusterConfig>

Optional distributed-cluster membership for the haematite backend (SS-2).

Absent (the default) selects the SINGLE-NODE haematite path, byte-identical to today: no endpoint is bound, no shard is elected, the store owns everything locally. Present selects the DISTRIBUTED path: the boot path binds a replication endpoint, builds a quorum membership from members + peers, and the engine boot path elects (acquire_shard_and_serve) this node’s owned_shards before recovery. Ignored by every non-haematite backend.

node_cache_budget: Option<NodeCacheBudget>

The byte ceiling the haematite node caches may hold. Required; no default — the haematite boot path refuses to start without it. Ignored by every other backend (only haematite has a node cache), which is why it is required where it is USED rather than at parse time: a memory deployment is not asked to rule on a cache it does not have.

A node is not a fixed-size thing — under byte-aware chunking a leaf reaches the ~96KB class — so a cache bounded only by max_entries carries a standing footprint of entries x (whatever a node weighs), unbounded in bytes by construction. This is the missing bound, and haematite 0.8.2 refuses a DatabaseConfig that does not carry it.

Deserialized through haematite’s own wire shape, so there is exactly one parser for this value estate-wide:

[store]
node_cache_budget = { bytes = 1073741824 }  # 1 GiB
# or, the pre-budget behaviour said out loud:
node_cache_budget = "unlimited"

Absent fails startup with STORE_NODE_CACHE_BUDGET_REQUIRED; a zero byte count is refused by haematite at parse time (a zero ceiling admits nothing, which is “disable the cache” and must be spelled differently).

lock_acquisition_patience_ms: Option<u64>

Maximum time production boot may spend acquiring an existing haematite data-directory writer lock. Required for haematite; no default.

lock_acquisition_retry_cadence_ms: Option<u64>

Cadence between production writer-lock attempts. Required together with lock_acquisition_patience_ms; no default.

Trait Implementations

impl Clone for StoreConfig

fn clone(&self) -> StoreConfig

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for StoreConfig

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Default for StoreConfig

fn default() -> Self

Returns the “default value” for a type.

impl<'de> Deserialize<'de> for StoreConfig

fn deserialize<D>(deserializer: D) -> Result<Self, D::Error>

where D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.