Data Model

Today, Tellstone stores a single value type: a byte string, addressed by a byte-string key. There are no lists, sets, sorted sets, or hashes yet — those are tracked as Phase 2 work (see Introduction).

Keys and values

Both the native binary protocol and the RESP2 listener work with the same underlying (key, value, ttl) triple:

• Key — arbitrary bytes, typically a UTF-8 string in practice. Keys can be up to 4096 bytes in length.
• Value — arbitrary bytes. Tellstone doesn’t interpret or validate the contents; encoding (JSON, msgpack, protobuf, plain text) is entirely up to your application. Values can be up to the maximum message size limit (default 16MiB).
• TTL — optional, set in milliseconds on the native protocol (ttlMs=0 means no expiry) or via EX seconds / PX milliseconds on RESP. TTLs are implemented using a timing wheel for O(1) eviction.

Expiry

A key with a TTL is evicted by the timing wheel described in Architecture, and is also treated as absent by lazy eviction on read even if the active sweep hasn’t reached it yet — so reads never observe a logically-expired value. This ensures data consistency while maintaining high performance.

If you need richer types today

Because Tellstone doesn’t yet have native lists/sets/hashes, common patterns are:

• Encode a small structured value as JSON or msgpack and store it as one value under one key.
• Use key naming conventions (e.g. queue:orders:123) to emulate grouping, and read the full set of related keys back with your own application logic — there is no server-side SCAN/pattern-match yet.
• Implement application-level data structures by combining multiple key/value pairs.

Next: the command reference

See the command reference for the exact commands available on each protocol today. For more information on how to work with the data model, see Architecture to understand how the protocols and storage engine fit together.