Redis strings can be modified in place with APPEND, SETRANGE and read partially with GETRANGE. How do these commands behave — including what SETRANGE does when you write past the end of the value — and what are the limits of treating a Redis string as a growable buffer?

## Strings are byte arrays, not text Redis strings are binary safe: they store arbitrary bytes, including NULs and image data, and Redis never interprets an encoding. That is why `STRLEN` counts bytes, not characters — `SET k "héllo"` under UTF-8 has length 6, and slicing with GETRANGE can cut a multi-byte character in half. If you slice user-facing text, slice on boundaries you control, or store fixed-width ASCII fields. ## APPEND `APPEND key value` concatenates to the end of the existing value and returns the new total length. If the key does not exist it behaves like a SET, creating it. If the key holds another type you get `WRONGTYPE`. Crucially, APPEND does **not** clear the key's TTL — it modifies the value rather than recreating the key. The implementation over-allocates the backing buffer (roughly doubling up to a cap, then growing in fixed chunks), which makes a series of appends amortised O(1) in the amount appended rather than O(current length) each time. That still leaves two real costs: memory used is larger than the logical length until the value is rewritten, and every append eventually triggers a reallocation-and-copy of the whole value, which for a 100 MB string is a single very expensive command. ## SETRANGE and the zero-padding trap `SETRANGE key offset value` overwrites `len(value)` bytes starting at `offset`, leaving everything else intact, and returns the new length. The behaviour people miss: **if `offset` is greater than the current length, Redis extends the value and fills the gap with zero bytes (`\x00`)**. So on an empty key, `SETRANGE k 1048575 "A"` immediately produces a 1 MiB value. This is exactly how bitmaps grow when you set a high bit offset, and it is also how a naive "use the user id as the offset" scheme accidentally allocates hundreds of megabytes from a single command. Offsets are limited so the resulting value cannot exceed 512 MB; beyond that the command errors. The useful pattern is fixed-width records: reserve N bytes per field and update field 3 with `SETRANGE k (3*N) <newvalue>` without reading or rewriting the rest — one command, no read-modify-write race. ## GETRANGE `GETRANGE key start end` returns the inclusive slice `[start, end]`. Negative indexes count backwards: `-1` is the last byte, so `GETRANGE k 0 -1` is the whole value and `GETRANGE k -100 -1` is the last 100 bytes. Bounds outside the value are clamped and a fully out-of-range request returns an empty string rather than an error. Cost is O(length of the returned slice), which is why fetching a small window out of a large value is cheap while `GETRANGE k 0 -1` on a big value is not. ## The 512 MB ceiling and the practical ceiling The protocol-level maximum for one string value is 512 MB, and the server also caps a single request/reply bulk length (`proto-max-bulk-len`, 512 MB by default). But the number that matters operationally is much lower. Values are transferred whole in the reply, held whole in memory, copied whole on reallocation, and shipped whole to replicas in the write stream; large values also make memory fragmentation and snapshot-time copy-on-write worse. A few hundred kilobytes is already a "big value" in most production deployments, and multi-megabyte strings are a known source of latency spikes because a single command's work is proportional to the value size. ## When to use these commands, and when not to Good fits: - **Bitmap-style data**, where SETRANGE/GETRANGE are the byte-level counterparts of SETBIT/BITCOUNT. - **Fixed-width binary records** updated field-by-field without a read-modify-write cycle. - **Bounded accumulation**, such as appending small delimiter-separated tokens with a cap and a TTL. Bad fits: - **Unbounded logs or event streams built by APPEND.** There is no trimming primitive, readers must slice by offset they have to track themselves, and the value only ever grows. A list or a stream is the right structure. - **Large documents you mutate frequently.** Every write ships the changed range but every read ships the whole value; a hash with fields, or a smaller key per document part, keeps both sides small. ## Atomicity note Each of these is a single command and therefore atomic: two clients appending concurrently both have their bytes retained, in some serialized order, with no lost update. What you cannot do atomically is "read the length, decide, then write" as two commands — the length may change in between. Use APPEND's returned length (it tells you where your bytes ended up) or a Lua script.