Product maturity and supported deployment scope
Current position
Spedo is a single-node, in-memory data engine in preview. It supports a
documented subset of RESP and is intended for evaluation, development, and
carefully qualified single-node workloads. It is not a drop-in replacement for
every Redis deployment, and it must not be presented as a highly available
database.
The snapshot/WAL reliability and crash recovery architecture is detailed in the official operator guide: persistence-and-recovery.md.
Before adopting a feature, validate the exact commands, data semantics, and
failure behaviour required by the application. The source of truth for the
release version is Cargo.toml; deployment defaults are defined by the active
Compose profile and src/main.rs.
Maturity register
Deployment rules
- Use one Spedo node as the source of truth for a workload; place any required
redundancy, backup, and failover policy in the surrounding infrastructure.
- Bind RESP, metrics, and the admin interface privately. Configure
SPEDO_USERS or SPEDO_REQUIREPASS before allowing remote connections.
- Treat metrics, the admin UI,
SAVE,SAVE WAIT,PERSIST.STATUS, and other control-plane operations as
privileged. Do not publish them through an Internet-facing load balancer.
- Do not use tiered storage or replication to meet an RPO/RTO, availability, or
persistence commitment.
Exit criteria for a stronger claim
Replication may be called HA only after initial synchronization, incremental
mutation transfer, resynchronization, promotion/fencing, and network-partition
tests are implemented and published. Tiered storage may be called durable only
after atomic writes, restart recovery, delete/tombstone handling, disk-full,
and corruption tests are published. Until then, the statuses above remain the
public product contract.