Redis ve Hırsın Bedeli

• Redis, 2026’da array type PR’ını değerlendirecek noktaya kadar geldi; bu da basit bir veri yapısı sunucusundan birçok alanı kapsayan bir ürüne dönüştüğünü gösteriyor
• İlk Redis, adına yakışır şekilde Remote Dictionary Server olarak; hızlı bir bellek içi sözlük, dar kapsamlı komutlar ve basit bir protokolle web yığınında hızla yer edindi
• Son 10 yılda Redis; Streams, JSON, search, graph, time-series, Redis-Raft, vector sets gibi özelliklerle genişleyerek giderek daha güçlü bir database yönelimine girdi
• Özelliklerin şişmesi, Redis’in güçlü yanı olan basitlik ve tutarlılığı zayıflattı ve uzman araç gerektiren alanlarda yarım kalmış entegrasyonları artırdı
• Valkey ise gösterişli özellik yarışından çok çok iş parçacıklı performans, bellek verimliliği ve küme güvenilirliğine odaklanarak 2011 tarzı Redis kullanıcı kitlesini hedefliyor

---

Redis’in Kaybettiği Kimlik

• Redis, 2026’da array type eklemek için büyük bir PR’ı değerlendirecek aşamaya geldi; bu da basit bir veri yapısı sunucusundan birçok alanı kapsamak isteyen bir ürüne dönüşmesini simgeliyor
• antirez’in array type PR’ı, Hash, List ve Stream’in sırasıyla rastgele erişim, append/trim ve append-only event senaryolarında güçlü olmasına rağmen, bir dizi gibi hem orta noktadan erişim hem de aralık görünürlüğünü birlikte sunamaması sorunundan yola çıkıyor
• Redis’te zaten JSON dizileri, time-series ve sorted-set gibi dizi benzeri kullanılabilecek özellikler var; buna rağmen yeni bir tür daha ekleme yönelimi, özellik genişlemesinin karakterini açıkça gösteriyor
• Asıl sorun, Redis’in ilk başarısının nedeni olan basitlik, net protokol, dar ve ortogonal komutlar ile kavramsal tutarlılığın zayıflaması

Son 10 Yıldaki Değişim

• Lisans ve şirketin yönü

  • Redis Inc, 2024’te BSD lisansını bıraktı ve ardından AGPLv3’ü tek OSI seçeneği olarak içeren üçlü lisans yapısına geri çekildi
  • AGPLv3 sayesinde Redis Inc kendisini açık kaynak olarak tanımlayabiliyor, ancak bu lisansın doğası BSD’den çok farklı
  • Redis’in arkasındaki VC destekli şirket aslında Garantia Data adlı bir NoSQL bulut barındırma hizmetiydi; daha sonra Redis barındırmaya yönelip adını Redis ekseninde değiştirerek ve antirez’i ekibe katarak meşruiyet kazandı
  • Birkaç yıl sonra ticari markanın devralınma süreci, sonraki lisans değişiminin zeminini hazırladı; o dönemde yazılan ilgili yazılar ve yorumlar bugün beklenebilecek şekilde eskimiş görünüyor

• Özellik şişmesi ve ürün konumlandırması

  • Redis, birkaç kullanışlı veri türüyle başladı; zamanla egzotik veri yapıları, Streams gibi karmaşık stateful sistemler ve sürüme göre yarı tekelci nitelik taşıyan modüllerle genişledi
  • 2026’daki Redis açılış sayfası konumlandırması “The Real-Time Context Engine for AI Apps” olarak değişmiş durumda
  • Açılış sayfasında “Try Redis for Free” ve “Get a Demo” düğmeleri birlikte yer alıyor; bu durum ekran görüntüsünde de görülebiliyor

• Web ölçeğinde database yönelimi

  • Sentinel, Cluster, Redis-Raft, active-active geo-distribution®, Redis Flex®, Redis-on-Flash® gibi özellikler, Redis’in “web ölçeğinde database” olmayı hedeflediğini gösteriyor

• Protokol değişimleri ve istemci tarafı önbellekleme

  • RESP3, RESP2’nin temel varsayımı olan istek/yanıt modelini birçok noktada bozuyor ve Brooks’un sözünü ettiği ikinci sistem başarısızlığına yakın görülüyor
  • Redis eskiden yaygın olarak cache olarak kullanılıyordu; artık istemci tarafı önbellekleme desteği için yeni bir protokole bile ihtiyaç duyuyor

İlk Redis Neden Bu Kadar İyi Uyum Sağladı?

• Dönemin bağlamı

  • 2011 civarında web geliştiricileri arasında NoSQL, “web scale”, Bigtable, Dynamo, Ruby on Rails, REST ve JSON gibi akımlar güçlüydü
  • Redis, bu atmosfere çok iyi uydu ve neredeyse bir gecede birçok yığında yer bulan bir araç haline geldi
  • 2011 sonundaki Redis tanıtımı kendisini advanced key-value store ve data structure server olarak tanımlıyordu; “database” kelimesi geçmiyordu

• Memcached’den daha iyi bir uzak sözlük

  • memcached, pek çok web sunucusunda sessizce çalışan temel altyapı bileşeniydi ve önbelleklemenin yanı sıra kilit, sayaç ve rate limit gibi geçici amaçlarla da sık kullanılıyordu
  • Redis o dönemde kabaca “memcached but way better” olarak algılandı; adı olan Remote Dictionary Server da hızlı bir bellek içi sözlük niteliğini vurguluyordu
  • Redis, byte blob’ların ötesinde linked-list, hash-table, set ve sorted-set gibi iyi seçilmiş veri yapıları sunarak geçici ve pratik kullanım alanlarını ciddi biçimde genişletti

• Basit ama yeterince ifade gücü olan protokol

  • Redis wire protocol, bir saat içinde anlaşılabilecek ve uygulanabilecek kadar basit, ama farklı veri türlerini ifade edebilecek kadar da güçlüydü
  • İstemci kütüphanelerini uygulamak basit ve temizdi; protokolün kendisi de doğal hissettiriyordu
  • Redis protokolünü ve basit bir sunucuyu doğrudan kurmayı anlatan write your own Redis öğreticisi, yaklaşık 10 yıl önce yazılmış popüler bir içerik olarak kaldı

• Tek iş parçacıklı, olay güdümlü, bellek içi

  • Redis’in tek iş parçacıklı tasarımı, tüm işlemlerin atomikliğini garanti ederek karmaşıklığı büyük ölçüde azalttı ve akıl yürütmeyi kolaylaştırdı
  • Tek iş parçacıklı yaklaşımın çalışabilmesi için sunucunun non-blocking I/O ile yazılması ve veri işlemlerinin de çok hızlı olması gerekiyordu
  • Bu birleşim, çok sayıda istemciyi işleyebilen hızlı bir key/value store’un tek bir iş parçacığıyla mümkün olmasını sağladı

• Web uygulamalarına uygun veri yapıları

  • String ve son kullanma süresi cache için, listeler kuyruklar için, hash’ler ise yapılandırılmış veriler için uygundu
  • Kilitler, sayaçlar, rate limiting, liveness, monitoring ve leaderboard gibi kullanım senaryoları da yerleşik veri türleriyle kolayca kurulabiliyordu

Database Olma Hırsı

• Redis’in benimsenmesi hızla arttı ve büyük başarı getirdi, ancak bir noktadan sonra projenin hırsı database olmaya yöneldi
• Bazı özellikler gerçekten faydalıydı; örneğin Redis 5.0’a eklenen BZPOPMIN, sorted-set’lerin priority queue olarak kullanımında blocking pop sağlayarak pratikliği artırdı
• Buna karşılık ACL gibi özellikler Redis’e yabancı göründü ve genel olarak Redis’i herkes için her şey haline getirme arzusu öne çıktı
• Redis’in özellik ekleme yönelimi, son 10 yılda geliştiricilerin Hacker News’te konuştuğu “en son trendleri” takip etmesiyle örtüşüyor
  • MongoDB JSON saklıyorsa Redis de bir document database olmalı anlayışı
  • ElasticSearch full-text search sunuyorsa Redis de bir search engine olmalı anlayışı
  • Graph database’ler öne çıkınca Redis de bir graph database olmaya çalıştı; ardından RedisGraph EOL geldi
  • Kafka öne çıkınca Redis de bir event streaming platform olmaya çalıştı
  • ZooKeeper ve güçlü tutarlılığa sahip database’ler önem kazanınca Redis-Raft ortaya çıktı; Aphyr’in Jepsen analizi ise neredeyse mutlaka okunması gereken bir kaynak sayılıyor
  • InfluxDB öne çıkınca Redis de bir time series database olmaya çalıştı
  • Yapay zeka dalgasının gerisinde kalmamak için vector sets gibi yapay zeka bağlantılı özellikler de gerekli hale geldi

Özellik Genişlemesinin Bedeli

• İlk sorun, Redis’i herkesin yığınında vazgeçilmez bir araç yapan unsurları kendi elleriyle zayıflatması
  • Redis basitti; komutları ortogonal ve dar tanımlıydı, protokolü temizdi ve kavramsal olarak tutarlı bir araçtı
• İkinci sorun ise full-text search, event stream processing, güçlü tutarlılığa sahip key/value, time-series ve vector storage gibi alanları ciddiyetle entegre etmek isteyen kullanıcıların, Redis’in sınırlamalarını devralmış yarım kalmış modüller değil, uzman araçlar istemesi
• Redis’in yüksek erişilebilirliği karmaşık, kalıcılığı ince ödünleşimler barındırıyor; protokol yükü ve istemci parçalanması da gerçek engeller oluşturuyor
• Buradaki görüş, Redis’in Postgres’in yerini alacak bir araç olmadığı ve ElasticSearch ile RabbitMQ gibi sistemlerin kendi temel sütunları olarak kalması gerektiği yönünde
• Aphyr’in ilk Redis-Raft uygulaması incelemesi 21 sorun bulduğunu söylüyor
  • Sağlıklı bir kümede uzun süreli erişilemezlik
  • 8 çökme
  • 3 stale read
  • 1 aborted read
  • Commit edilmiş güncellemelerin kaybına yol açan 5 hata
  • 1 sonsuz döngü
  • İstemcilere mantıksal olarak bozuk yanıt gönderebilen 2 sorun
  • Test edilen ilk sürüm 1b3fbf6, fiilen kullanılamaz düzeyde değerlendirildi
• Hem cache hem veri yapısı sunucusu olan Redis ile “Redis the etcd” ya da başka uzman database’lere öykünen Redis, temelde farklı öneriler ve asıl sorun bu boşlukta yatıyor

Disque’nin Ortaya Koyduğu Aynı Desen

• antirez, 2015’te Disque’yi duyurdu ve o sırada bunun gerçek kullanım senaryolarından değil, Redis’i mesaj kuyruğu gibi kullanan insanları ve başka mesaj kuyruklarını görüp “astronaut mode” ile tasarladığını söyledi
• Gerçek kullanım senaryosu olmadan kişisel meydan okuma ya da öğrenme projesi olarak yapılan işler de harika olabilir; ama kullanıcı sayısı arttıktan sonra ortaya çıkan uzun kuyruklu zor sorunları sürekli çözebilmek ayrı bir mesele
• Yüksek erişilebilirlikli mesaj teslimi gerçekten çözülmesi zor bir problem ve CAP teoreminin hangi tarafını optimize ederseniz edin, ödünleşimlerden ve zor problemlerden kaçmak mümkün değil
• 2015’te zaten olgunlaşmış birçok mesaj aracısı vardı; insanların Redis’i mesaj aracısı olarak kullanmasının nedeni, ellerinde zaten Redis olması ve onun yeterince basit olmasıydı
• Gerekli olan ne yeni bir mesaj aracısıydı ne de Redis’in daha karmaşık bir mesaj aracısına dönüşmesi
• Disque duyurulduktan kısa süre sonra fiilen abandonware haline geldi; GitHub’da 8K yıldız almasına rağmen ortada bırakıldı
• Daha sonra bir Redis modülü olarak yeniden yazıldı, ancak o proje de son 7-8 yıldır terk edilmiş durumda

Valkey’in Gösterdiği Farklı Yön

• Redis’in gidişatını belirleyen güçler; zor problemleri çözme geliştirici hırsı, herkes için her şey olma hırsı ve Redis’in sahiplerinin AWS ile GCP’ye yenilmeden önce mümkün olan en yüksek geliri çıkarma hırsı olarak birleşiyor
• Hırsın kendisi sorun değil; sorun, başarı nedenlerini kaybettirdiğinde ortaya çıkıyor
• Valkey’in varlığı ve benimsenmesi, bu dinamiklere karşı daha geniş pazarın nihai hükmü olarak sunuluyor
• Valkey, özellik yarışı ya da karşılaştırma tablosundaki madde işaretleri yerine; çok iş parçacıklı performans, bellek verimliliği, küme güvenilirliği ve throughput artışı gibi daha az gösterişli alanlara yatırım yapıyor
• Valkey’in performans kıyaslamaları etkileyici ve 2011’de Redis’in sunduklarının kendisine yettiği Redis kullanıcılarının %80’ini doğrudan hedefliyor
• Valkey dünyasında yeni bir array type’a ihtiyaç olmadığı sonucuna varılıyor

[GN⁺]

Lobste.rs görüşleri

• Açık kaynaklı bir projeyi epey büyük ölçeğe büyütmüş, şirket kurmuş, yüz milyonlarca dolar gelir, IPO ve milyarlarca dolarlık satış görmüş, bu süreçte OSS’den uzaklaşan lisans değişikliği de yapmış biri olarak bakınca, Redis’in kendini “AI uygulamaları için gerçek zamanlı bağlam motoru” olarak konumlandırması yön olarak doğru görünüyor.
  Yazılım satın alımında gerçek kullanıcılar ve teknik karar vericiler (TDM) var; Redis’in açılış sayfası da son kullanıcı geliştiricilerden çok bütçe yetkisi olan TDM’lere yönelik bir site gibi görünüyor. Birçok TDM, “IBM’i seçtiği için kimse işten atılmaz” türünden, işten atılmasına yol açmayacak kararları tercih eder; Gartner ya da McKinsey yapay zeka stratejisi ve bağlam yönetimini vurguladığında, “AI uygulamaları için Context Engine” savunulabilir bir satın alma gerekçesi haline gelir.
  HashiCorp’ta da terraform.ioyu uygulayıcılar için, hashicorp.comu ise TDM’ler için ayırmaya çalışmışlardı; bu kısmen işe yaradı ama sınırları da vardı. Geliştirici odaklı OSS şirketleri için bu zor bir problem.
  “Redis’i ücretsiz kullan” ve “Demo al” düğmeleri de TDM bakış açısından garip değil. TDM’ler teknik kararın sorumluluğunu almak istemez, hatta çoğu zaman para ödeyip yazılım satın almak ister; bu yüzden ücretsiz seçeneği deneme düzeyine indirip, insanla bağlantı kuran çağrıyı öne çıkarırlar.
  Redis Inc. yönetimi, geliştirici/operatörlerden çok TDM’lere hitap etmenin daha önemli olduğu sonucuna varmış gibi görünüyor; içeriden veri olmadan bunun doğru mu yanlış mı olduğunu söylemek zor, ama bu kasıtsız seçilmiş bir strateji değil gibi.
  Sürekli yeni özellik eklemelerinin nedeni de, yeni bir araç benimsemenin maliyetinin mevcut aracı genişletmenin maliyetinden çok daha yüksek olması. Ticari motivasyon olmasa bile programlama dilleri çoğu zaman çekirdek kimliklerini korumaktan ziyade tüm özelliklerin en küçük ortak paydası olmaya kayıyor; ticari şirketlerde ise “land and expand” çok güçlü çalışıyor. Temsilî bir özellikle ilk sözleşmeyi aldıktan sonra, ortalama düzeyde ek özellikler ekleyip satmak mümkün; satın alma departmanları da yeni sözleşme yerine mevcut sözleşmeyi genişletmeyi daha kolay işler.
  “Ciddi müşteriler uzman arama / event stream / güçlü tutarlılığa sahip KV / time-series / vektör deposu için gerçek uzman ürünler ister” iddiası da oldukça tartışmalı. Sadece halka açık yazılım şirketlerinin verilerine baksanız bile, müşterilerin teknik olmayan nedenlerle daha kötü seçenekleri sık sık seçtiğini görürsünüz.
  Valkey’nin piyasanın nihai hükmü olduğunu söylemek de kesin değil. Valkey ortalama bir fork’tan çok daha iyi gidiyor (https://redmonk.com/sogrady/2026/04/06/valkey-at-two/), ama Redis şirketi de dışarıdan bakıldığında fena dayanmıyor gibi. ElasticSearch ya da MongoDB gibi, lisans değiştirip fork çıkmasına rağmen halka açık piyasa değerlemesinde büyük darbe almayan şirketlere bakınca farklı sonuçlara da varılabilir. Geliştirici balonunda farklı görünebilir, ama gelir nihai gecikmeli göstergeyse “bu gerçekten o kadar önemli miydi?” diye de sorulabilir.
  Ticari çıkarları savunmaya çalışmıyorum; sadece o taraftan görülen bakışı paylaşıyorum. Aynı tarım ürününe bakarken alışveriş yapanla çiftçinin sorduğu soruların ve hedeflerinin tamamen farklı olması gibi.

  • Ticari bakış açısından “neden” iyi açıklanmış; Redis’in saf bir yazılım vakumunda var olmadığı, hedefinin OSS meraklıları olmadığı ve karar vericilerin sistem mühendislerinden farklı ölçütlere sahip olduğu bağlamı eklenmiş.
    Yine de bu mantık, herkesin hedefinin para olduğunu varsayıyor gibi hissettiriyor. Redis’ten çok büyük para kazanma hırsı sadece belirli bir hırs türü; antirez’in yazıdaki tavrına bakınca da para konusunda çok büyük kaygıları olan biri gibi okunmuyor.
    Karşı örnek olarak SQLite var. Yüz milyonlarca gelir ya da milyarlarca dolarlık satıştan söz etmeden, iyi tanımlanmış bir şeyi sessizce sunmaya odaklanıyor. SQLite, en popüler gömülü veritabanı olmasının nedenini kaybetmedi; büyük veritabanları tarafında Postgres için de benzeri söylenebilir. Para ve ticari çıkarlar dünyası kadar, bu dünyadan da karşı örnekler çıkarılabilir.
    Redis özelinde ise “zaten AWS/GCP kullanıyoruz, o zaman onların Redis benzerini kullanalım” yaklaşımı yatay genişlemenin doğal sonucu gibi görünüyor. Daha IBM tarzı yol, bulut sağlayıcısını seçip onların Redis’ini kullanmak olur; bugünlerde bu da Valkey anlamına geliyor.
    İnsanların daha kötü seçenekleri seçtiği tartışmalı değil, olgusal bir durum; Redis’in o moda doğru genişlemesi de tam olarak vurgulamak istediğim hırs ve sürüklenme örneklerinden biri.
  • Redis Labs’te çalıştım, yani neredeyse kelimenin tam anlamıyla şeytanın geliştirici avukatı konumundaydım. Ayrılırken hak ettiğim opsiyonları kullanmadım ve Silicon Valley’den uzak bir yerde yaşadığım için fazla köprü yakma kaygısı olmadan konuşabiliyorum.
    Eskiden redis.com TDM sitesi, redis.io ise geliştirici sitesi idi; Redis Labs, antirez’in elindeki redis.ioyu aldıktan sonra siteyi, indirme bağlantısını bulmanın bile zor olduğu ölçüde bozdu ve artık iki URL de TDM sitesine gidiyor. Hâlâ Redis indirme bağlantısını kolay bulmak zor; neredeyse “gidip kendiniz arayın” demek istiyorum.
    Temel sorun, Redis Labs’in her zaman pazarlama liderliğini çok kötü seçmiş olması. CMO’lar ve VP’ler gelip kısa sürede mümkün olduğunca sempati tüketip altı ay sonra “bir sonraki macera”ya geçiyordu. redis.io trafiğinin redis.comdan çok daha yüksek olduğunu görüp, indirme bağlantısını bulamayanların “try free”e tıklamasını umarak redis.ioyu mahvetmeleri de bu kısa vadeli tıklama açgözlülüğünün tipik örneği gibi görünüyor.
    Ek özellik satmak, rakiplere karşı kontrol listesi düzeyinde farklılaşmaya da yardımcı oluyor. Özellikle fiyatla rekabet etmenin zor olduğu durumlarda; AWS, ElastiCache’i güçlü bulut indirimleriyle paketleyebiliyordu ve en kötü rakip de ücretsiz açık kaynak Redis’ti.
    Valkey’ye sıradan bir fork’tan çok daha fazla para akıyor. Örneğin Redis Labs’in eski geliştirici ilişkileri yöneticisi şu anda AWS’de Valkey üzerinde çalışıyor.
    Yine de Valkey’nin yalnızca “gösterişsiz işler” yaptığı değerlendirmesi biraz haksız. Redis zaten çok uzun zamandır çok iş parçacıklıydı; denetim düzlemi hâlâ tek iş parçacıklı ama I/O çok iş parçacıklı, dolayısıyla Valkey’nin yaptığı iş yazarın düşündüğü kadar yeni değil.
    Valkey açıkça, AWS gibi bulut şirketlerinin kimseye para ödemeden Redis satmaya devam etmesini sağlayan bir hamle. Diğer söylemler, onların zaten yapmak istediği şeyi yapmaya devam etmesini ikna etmeye yönelik pazarlama araçları sadece; Redis’le uyumluluğu bozmanın ticari olarak avantajlı olduğuna karar verirlerse bunu da yaparlar. Hatta iki tarafta da bunun bir miktar olmuş olabileceğine makul biçimde bahse girerim, ama yeterince yakından takip etmedim.
    Gösterişsiz işleri yaparken sadeliği korumaya çalışan gerçek bir Redis fork’u istiyorsanız, redict var.
    Buna rağmen Redis’in zamanının dolmakta olduğunu düşünüyorum. Bugünün tuhaf ticari manzarasında, her fork bir yerinden aksıyor. En erdemli olan redict bile, antirez’in orijinal projeyi adeta bir diktatör gibi ileri ittiği dönemdeki şekilde Redis’i ileri taşımaya yönelik gerçek ilgiden yoksun. Yazılımın “tamamlanması” kötü bir şey demek istemiyorum, ama Redis’in hâlâ keşfedilmemiş harika alanları olduğunu düşünüyorum ve ticari fork’ların böyle bir ekosistem yaratacağından şüpheliyim. Elbette Arrays ve AI bağlantılı uygulamaların değerini küçümsüyor da olabilirim; o yüzden kulağımı açık tutuyorum.
    Geriye dönüp bakınca Redis Labs’in bütün bunları bu kadar kötü yönetmiş olması şaşırtıcı; yeterince zaman geçtiği için artık buna daha az öfkeli olmam da iyi bir şey.
  • Şirketler para ödemeden mümkün olduğunca çok şey almak istiyor gibi görünüyor. O yüzden Redis, MongoDB, HashiCorp da sonunda lisans değiştirdi diye düşünüyorum.

• İş yerinde Lua script’leriyle daha adil bir iş kuyruğu sistemi kuruyoruz ve Redis bana çok tuhaf geliyor. Zihnimdeki model hep “basit bir key-value store” idi, ama global lock içinde Lua script çalıştırma gibi türlü türlü özellikler öğreniyorum.
  Ama dokümantasyon parlak bir web sitesinde duruyor ve bunları açıkça anlatmıyor. Ayarlar bile sadece örnek yapılandırma içinde açıklanmış gibi.
  Redis’in iyi çalıştığını biliyorum ve herkes de öyle söylüyor, ama Redis özelliklerini öğrenme deneyimi epey rahatsız edici. Sanki biri gerçekten çok iyi bir program yapmış ama iyi bir programın normalde sahip olması gereken mükemmel dokümantasyonu unutmuş gibi.
  Garip bir şikâyet belki. Redis aşırı iyi çalışıyor gibi görünüyor; ben de Postgres dokümantasyonu gibi “her şeyi” anlatan belgeleri seviyorum.

  • TDM odaklılığı daha az olan bir ürünün dokümantasyonunun daha anlaşılır olup olmadığını merak ediyorum: https://valkey.io/topics/programmability/
    Birçok açık kaynak proje de dokümantasyonunun zayıf olduğunu gayet iyi biliyor, o yüzden bu deneyde tek değişken sivri saçlı patronlar değil gibi.
  • Redis’in eskiden her tür dokümanı vardı ve neyse ki Wayback Machine ile Redis Labs’in verdiği zararı geri almak mümkün. Belki aradığınızı burada bulabilirsiniz: https://web.archive.org/web/20190725152042/…
    redict’in dokümantasyonu da iyi görünüyor: https://redict.io/docs/scripting/