Skip to content
Tellstone

Introduction

Tellstone is an ultra-high-performance, cloud-native in-memory key/value store written entirely in Go. It speaks two protocols over TCP — a compact custom binary protocol and a Redis-compatible (RESP2) protocol — on top of a sharded, low-contention storage engine with optional TTL eviction, at-rest encryption, and per-shard WAL persistence for crash recovery.

+------------------------------------------------+
|                Your K8s Cluster                |
|                                                |
|  [App Pod] --( binary :9988 / RESP :6379 )---->|
|                                                |
|  +------------------------------------------+  |
|  |              TELLSTONE CORE              |  |
|  |  N sharded in-memory buckets (GOMAXPROCS)|  |
|  |  timing-wheel TTL eviction               |  |
|  |  per-shard WAL persistence               |  |
|  +------------------------------------------+  |
+------------------------------------------------+

Why Tellstone?

Section titled “Why Tellstone?”

Many managed databases (PostgreSQL, MySQL, …) become bottlenecks under high-frequency workloads. Tellstone is an efficient in-memory database, not just a cache — it is often deployed as a lean accelerator in front of those row stores, and the roadmap grows it into a full in-memory data platform, including vector search for AI workloads. Today:

  • Zero-copy binary protocol — direct binary messages avoid text parsing or Protobuf overhead for maximum performance.
  • Redis-compatible — an optional RESP2 listener lets you drive Tellstone with redis-cli, redis-benchmark, memtier_benchmark, and existing Redis client libraries for seamless integration.
  • Sharded, low-contention engine — N shards (default GOMAXPROCS, configurable) indexed by key hash, each guarded by its own RWMutex, for near-linear scaling across cores.
  • Configurable TTL eviction — an active timing wheel evicts expired keys in O(1); lazy eviction on read backs it up for efficient key management.
  • Optional at-rest encryption — ChaCha20-Poly1305, off by default, for secure data storage when needed.
  • Per-shard WAL persistence — an append-only write-ahead log per shard for crash recovery. Disabled by default; enable with --enable-persistence.
  • Metrics & tracing — a built-in Prometheus exporter and optional OpenTelemetry tracing for comprehensive observability.

What’s here today vs. on the roadmap

Section titled “What’s here today vs. on the roadmap”

Tellstone’s core engine and persistence (Phase 1) are done: the sharded store, both protocols, TTL eviction, encryption, observability, and per-shard WAL for crash recovery. The current focus is Phase 2 — Security & Transport. Clustering, replication, and the broader command set sit in later phases — see the roadmap for the full picture, and the clustering page for status today.

Phase 1 — Core Engine & Persistence (done): sharded in-memory engine with TTL eviction, binary TCP protocol, Redis-compatible RESP listener (PING/GET/SET/DEL), per-shard WAL persistence, at-rest encryption, Prometheus metrics, and OpenTelemetry tracing.

Phase 2 — Security & Transport (current): TLS 1.3 / mTLS with automatic certificate rotation, RESP STARTTLS, role-based access control, OAuth/OIDC, audit logging (see Audit Logging), and encryption key management (see At-Rest Encryption) are done. In progress: API keys.

Phase 3 — Data Durability & Recovery (planned): WAL compaction, full database snapshots, and backup integration.

Phase 4 — Intelligence Layer (planned): vector search designed into the shared-nothing architecture — fixed-dimension embeddings, HNSW and IVF indexes, and VSEARCH queries for AI workloads.

Phase 5 — Ecosystem & Operations (planned): official client SDKs, a broader RESP command set (RESP3, INCR, EXPIRE, MULTI/EXEC), cluster mode with replication, and write-through adapters.

Phase 6 — Observability & Developer Experience (planned): built-in dashboard, query layer, and operational tooling.

Where to go next

Section titled “Where to go next”