A preview runtime on one node, with explicit limits
Spedo is built for hot, rebuildable and qualified workloads on a single node. It prioritizes local speed, simple deployment, and documented recovery boundaries without claiming distributed HA, cluster failover, or multi-region database replication.
Core RESP
173 documented and tested commands on one node
Crash Persistence & WAL
SPDO2 atomic snapshots + Write-Ahead Log for KV, Hashes, Lists, Sets, Queues & Vectors
Availability
No replicated data plane, promotion, quorum, or automatic failover
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.
Core in-memory KV, Hashes, Lists, Sets, Sorted Sets, Streams, and native Spedo extensions are covered by 173 documented/tested commands. Check the exact command reference before relying on niche Redis modules.
SPDO2 checkpoints serialize full engine state with CRC32 checksums and generation rollback. With SPEDO_WAL_FSYNC=always, mutations (KV, Hashes, Lists, Sets, Queues, Vectors) are appended and flushed to stable storage before RESP ACK.
SAVE WAIT waits for a committed checkpoint and PERSIST.STATUS exposes checkpoint, WAL, and recovery state. Automated crash-recovery verification results are published in PsyKoTest.
Vectors, search, queues, CDC, scripting, reactive state, JSON, and client optimizations have feature-specific contracts. They require workload and failure qualification before critical use.
Bind RESP, metrics, the admin interface, and persistence controls privately. Configure authentication before remote exposure and keep Internet-facing protection in surrounding infrastructure.
Performance results are tied to published conditions. Reproduce them on the intended host and distinguish direct-server results from local client-cache measurements.
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.” |
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
- Single node: Spedo operates as an ultra-fast standalone engine without distributed Raft cluster sharding.
- Universal persistence: checkpoints and WAL cover 100% of data structures (KV, Hashes, Sets, Lists, Queues, Vectors).
- Configured volume:
SPEDO_WAL_FSYNC=alwaysis meaningful when a durable local volume (SSD/NVMe) and correct filesystem configuration are supplied. - ColdArchive offload: automated transparent memory paging to disk/NVMe under memory pressure with zero-loss rehydration.
- Private control plane: never expose the admin interface, metrics, or persistence controls through a public load balancer; configure authentication before remote RESP access.
Who builds Spedo: Real engineers, not AI hallucination
In an era of generative wrappers and disposable demos, low-level data infrastructure requires authentic systems engineering, rigorous memory discipline, and verifiable human accountability.
Dany Cohen
Systems engineer and veteran SysAdmin with 25+ years architecting high-throughput infrastructure, Linux production operations, and low-latency data platforms primarily in Python and Rust. Driven by mechanical sympathy, zero-copy memory discipline, and eliminating pointless network hops.
Why you can trust the binary and container
We know developers are rightly cautious about running unknown software on production clusters. Here are the explicit security boundaries and verifiable guarantees of Spedo:
Spedo contains zero phone-home beacons, zero remote analytics, and zero external network calls. It operates fully air-gapped on standard VPCs, listening strictly on designated local TCP ports.
All application client code (Python SDK spedo on PyPI, React SDK @spedo/react on npm) is 100% open source. You can audit every line of serialization and caching logic in your process.
The official Docker Hub image (torxx666/spedo) runs under a non-root system user (spedo:spedo, UID 10001) on a minimal Debian slim base image with zero unnecessary utilities.
Every performance claim, matrix benchmark, and 24-hour chaos test suite (Project YK26) is published with complete reproduction scripts, test harnesses, and downloadable raw JSON artifacts.