Đào vào con số 185 byte cho mỗi khoá chứa 100 byte dữ liệu, và tìm ra ba cách ghi cùng một chuỗi cho ba lượng bộ nhớ khác nhau. Phụ trội cố định ~64 byte mỗi khoá; một khoá 8 byte dữ liệu tốn 72 byte, gấp 9 lần. Ranh giới 44 byte đổi embstr sang raw. Và dựng chuỗi bằng APPEND chiếm gần gấp đôi vì Redis cấp phát tăng gấp bội. FLUSHALL cũng không trả RAM về hệ điều hành.
Đo bốn kiểu tập hợp của Redis và tìm ra ba vách đá bộ nhớ rơi ở đúng một phần tử. Gom nhiều giá trị vào một Hash/Set rẻ hơn nhiều khoá riêng 2,3–2,8 lần vì phụ trội 64 byte mỗi khoá biến mất. Nhưng vượt ngưỡng listpack/intset là bộ nhớ mỗi phần tử nhảy 2,3–18,6 lần chỉ vì một phần tử. Và LINDEX có hình chữ V: chậm nhất ở giữa list, không phải ở cuối.
Redis đổi cách mã hoá tập hợp khi nó vượt ngưỡng, nhưng KHÔNG BAO GIỜ đổi ngược. Đo thật: một Hash từng có 513 trường rồi xoá còn 199 vẫn tốn 16.256 byte, gấp 8,8 lần một Hash tạo mới đúng 199 trường (1.840 byte). Đây là rò rỉ bộ nhớ âm thầm nhất trong Redis — phình trong đợt cao điểm rồi giữ chi phí lúc lớn nhất vĩnh viễn. Và một giá trị vượt 64 byte đẩy cả Hash sang mã hoá đắt.
Hai kiểu dữ liệu ít dùng nhất của Redis cũng là hai kiểu tiết kiệm nhất. Đo cả bộ nhớ lẫn sai số: HyperLogLog đếm một triệu phần tử khác nhau trong 14.384 byte cố định (nhỏ hơn Set 3.364 lần) với sai số dưới 0,5%, và PFADD nhanh hơn SADD vì nó băm rồi vứt, không cấp phát. Bitmap nhỏ hơn Set 35 lần nhưng có bẫy: bộ nhớ phụ thuộc chỉ số bit lớn nhất, không phụ thuộc số bit đã đặt.
List làm hàng đợi được và nhiều hệ thống dùng nó. Đo xem Stream cho thêm gì: nó gọn hơn List 24% dù mang thêm id, và khác biệt thật là khi tiến trình chết — bản tin ở lại danh sách chờ tới khi có ai XACK, còn List thì mất dấu. Nhưng danh sách chờ là cái bẫy: quên XACK làm bộ nhớ phình 19,7 lần, và XTRIM không cứu được vì chỗ tốn nằm ở pending, không ở stream. Giám sát XPENDING, không chỉ XLEN.
Đặt TTL là thao tác phổ biến nhất trong Redis sau GET và SET. Đo ba thứ ít ai kiểm: Redis dọn 100.000 khoá hết hạn trong dưới một giây (nhanh hơn lời đồn), SET xoá TTL nhưng APPEND/INCRBY thì không — vì lệnh thay thế cả khoá thì mất hạn còn lệnh sửa tại chỗ thì giữ — và mỗi TTL tốn thêm 34,4 byte (+19%). Quên KEEPTTL là nguồn của một lớp lỗi khoá bất tử không lỗi, không cảnh báo.