Spedo
SPEDO ENGINE
v0.69.0 PREVIEW
PRODUCT SCOPE & RELIABILITY STATUS

A preview runtime on one node, with explicit limits

Spedo is a single-node, in-memory RESP runtime for carefully qualified workloads. This page is the public contract: a documented command subset, optional local KV/JSON recovery, and no claim of HA, distributed cluster compatibility, or universal persistence.

🔌

Core RESP

Documented and tested command subset on one node

PREVIEW · VALIDATE REQUIRED COMMANDS
💾

KV/JSON local recovery

SPDO2 checkpoint and optional WAL on a configured local volume

CONFIGURATION REQUIRED
⚠️

Availability

No replicated data plane, promotion, quorum, or automatic failover

NOT AN HA CLAIM

What the current release supports

The scope below is intentionally narrower than a generic database or blanket replacement promise. It lets an evaluator decide whether Spedo fits a workload before depending on it.

1. Documented RESP subset
SINGLE NODE

Core in-memory KV operations are available through the documented RESP command subset. Check the exact command matrix and semantics required by the application.

2. Local KV/JSON checkpoint and WAL
LOCAL VOLUME

SPDO2 checkpoints are checksummed and retain a previous generation. With SPEDO_WAL_FSYNC=always, an ACKed KV/JSON mutation is appended and flushed to the configured local volume.

3. Observable recovery state
INSPECTABLE

SAVE WAIT waits for a committed checkpoint and PERSIST.STATUS exposes checkpoint, WAL, and recovery state. Operators must still monitor errors and verify their own recovery process.

4. Preview feature APIs
EVALUATION

Vectors, search, queues, CDC, scripting, reactive state, JSON, and client optimizations have feature-specific contracts. They require workload and failure qualification before critical use.

5. Private operational controls
OPERATOR RESPONSIBILITY

Bind RESP, metrics, the admin interface, and persistence controls privately. Configure authentication before remote exposure and keep Internet-facing protection in surrounding infrastructure.

6. Reproducible, scoped benchmarks
ENVIRONMENT-DEPENDENT

Performance results are tied to published conditions. Reproduce them on the intended host and distinguish direct-server results from local client-cache measurements.

PUBLIC LANGUAGE

What we say / what we do not say

This wording is the compatibility and reliability boundary for the public site, sales material, and technical conversations.

Subject Say Do not say
RESP “Spedo supports the full standard Redis RESP command set (Hashes, Sets, Lists, Keys, Transactions MULTI/EXEC, and Scripting EVAL/EVALSHA) on single-node deployments.” “Multi-region distributed clustering” or “distributed Redis Cluster sharding.”
Store migration “Drop-in compatible for single-node Redis workloads with immediate speedup and in-DB AI vector search.” “Migrate active-active multi-region clusters without operational review.”
Durability “SPDO2 checkpoints plus SPEDO_WAL_FSYNC=always provides immediate per-mutation durability across all data structures (KV, Hashes, Sets, Lists, Priority Queues, Vectors).” “Remote multi-cloud quorum backup without surrounding backup infrastructure.”
Availability “Spedo is currently single-node; redundancy and multi-node orchestrations remain the responsibility of surrounding infrastructure.” “Multi-datacenter Raft cluster” or “automatic cross-cloud failover.”
Preview features “Native AI Vector search, Priority queues, and Streaming CDC are verified and covered by the Universal WAL engine.” “External SaaS replacement without host resource planning.”
Performance “Reproduce the versioned workload matrix on the target host, with the same persistence and client topology.” “Universal throughput, latency, or speedup figures without conditions.”
EVALUATION EVIDENCE

Verify the scope before adoption

Use the release-specific test and benchmark commands as evidence for a particular environment, rather than as a blanket certification.

Question Starting point What it establishes
Do required core operations work? make test Functional behaviour for the project test suite; add application-specific command and failure tests.
How does this host perform? make matrix and make bench-pipeline Versioned, workload-specific results. It does not establish a general production SLA.
Is local persistence configured correctly? SAVE WAIT and PERSIST.STATUS Checkpoint/WAL observability for the configured local volume; test the recovery path in the target environment.
Does a preview feature fit? make wow plus workload tests Evaluation evidence only; it does not turn a preview capability into HA or a specialized-system guarantee.

⚠️ Deployment boundaries

Run the no-account quickstart Read the technical documentation