Redis dan Harga dari Ambisi

 (charlesleifer.com)
4 poin oleh GN⁺ 4 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Redis, hingga meninjau PR besar untuk array type pada 2026, telah berubah dari server struktur data sederhana menjadi produk yang mencoba mencakup banyak area
  • Redis awal, sesuai namanya Remote Dictionary Server, cepat mendapat tempat di web stack berkat kamus in-memory yang cepat, himpunan perintah yang sempit, dan protokol yang sederhana
  • Selama 10 tahun terakhir, Redis meluas ke Streams, JSON, search, graph, time-series, Redis-Raft, vector sets, dan lainnya, sehingga orientasinya makin kuat ke arah database
  • Pembengkakan fitur melemahkan kesederhanaan dan konsistensi yang dulu menjadi kekuatan Redis, sekaligus menambah integrasi yang setengah matang di area yang sebenarnya memerlukan alat khusus
  • Valkey, alih-alih mengejar fitur mencolok, berfokus pada kinerja multithread, efisiensi memori, dan keandalan cluster, dengan menyasar basis pengguna Redis ala 2011

Identitas yang Hilang dari Redis

  • Redis telah sampai pada tahap meninjau PR besar untuk penambahan array type pada 2026, dan ini melambangkan perubahannya dari server struktur data sederhana menjadi produk yang ingin mencakup banyak area
  • array type PR dari antirez berangkat dari masalah bahwa Hash, List, dan Stream masing-masing kuat untuk akses acak, append/trim, dan event append-only, tetapi tidak dapat sekaligus menyediakan akses tengah dan visibilitas rentang seperti array
  • Redis sebenarnya sudah punya fitur yang bisa dipakai seperti array, seperti JSON array, time-series, dan sorted-set, tetapi arah untuk menambah tipe baru lagi justru menunjukkan dengan jelas sifat ekspansi fiturnya
  • Masalah intinya adalah kesederhanaan Redis yang dahulu membuatnya sukses, beserta protokol yang jelas, perintah yang sempit dan ortogonal, serta konsistensi konseptualnya, kini mulai melemah

Perubahan Selama 10 Tahun Terakhir

  • Lisensi dan arah perusahaan

    • Redis Inc menghentikan lisensi BSD pada 2024, lalu mundur ke skema lisensi tiga lapis yang memasukkan AGPLv3 sebagai satu-satunya opsi OSI
    • Berkat AGPLv3, Redis Inc masih bisa mengatakan dirinya open source, tetapi lisensi ini sangat berbeda sifatnya dari BSD
    • Perusahaan yang didukung VC di balik Redis awalnya adalah Garantia Data, layanan cloud hosting NoSQL, lalu beralih ke hosting Redis, mengganti nama ke lini merek Redis, dan merekrut antirez untuk memperoleh legitimasi
    • Beberapa tahun kemudian, proses pengalihan merek dagang menjadi landasan bagi perubahan lisensi berikutnya, dan tulisan serta komentar terkait di masa lalu kini terlihat usang dengan cara yang mudah diduga

  • Pembengkakan fitur dan positioning produk

    • Redis memulai dari sejumlah kecil tipe data yang berguna, tetapi seiring waktu merangkul struktur data yang eksotis, sistem stateful kompleks seperti Streams, hingga modul yang pada beberapa versi bersifat semi-proprietary
    • Pada 2026, positioning Redis di landing page telah berubah menjadi “The Real-Time Context Engine for AI Apps”
    • Di landing page, tombol “Try Redis for Free” dan “Get a Demo” tampil berdampingan, dan ini juga terlihat pada screenshot

  • Arah menuju database skala web

    • Fitur seperti Sentinel, Cluster, Redis-Raft, active-active geo-distribution®, Redis Flex®, dan Redis-on-Flash® menunjukkan bahwa Redis telah lama mengarah menjadi “database skala web”

  • Perubahan protokol dan caching sisi klien

    • RESP3 dinilai dekat dengan pola kegagalan second-system yang dijelaskan Brooks, karena di banyak titik ia merusak asumsi dasar model request/response milik RESP2
    • Redis awalnya banyak digunakan sebagai cache, tetapi kini sampai memerlukan protokol baru untuk mendukung caching sisi klien

Mengapa Redis Awal Begitu Pas pada Masanya

  • Latar zaman

    • Di sekitar 2011, di kalangan web developer sedang kuat arus NoSQL, “web scale”, Bigtable, Dynamo, Ruby on Rails, REST, dan JSON
    • Redis sangat cocok dengan suasana ini, dan hampir dalam semalam menjadi alat yang masuk ke banyak stack
    • Pada akhir 2011, pengantar Redis menggambarkan dirinya sebagai advanced key-value store dan data structure server, tanpa memakai kata “database”

  • Remote dictionary yang lebih baik dari Memcached

    • memcached adalah infrastruktur penting yang diam-diam berjalan di banyak web server, dan selain untuk caching juga sering dipakai secara sementara untuk lock, counter, dan rate limit
    • Saat itu Redis diterima sebagai alat yang kurang lebih berarti “memcached but way better”, dan namanya, Remote Dictionary Server, juga menegaskan karakternya sebagai kamus in-memory yang cepat
    • Redis tidak hanya menyediakan byte blob, tetapi juga struktur data yang dipilih dengan baik seperti linked-list, hash-table, set, dan sorted-set, sehingga sangat memperluas kegunaan praktis dan sementara

  • Protokol yang sederhana namun cukup ekspresif

    • Wire protocol Redis cukup sederhana untuk dipahami dan diimplementasikan dalam waktu kurang dari satu jam, tetapi tetap cukup kuat untuk merepresentasikan berbagai tipe data
    • Implementasi library klien sederhana dan rapi, dan protokolnya sendiri dinilai terasa natural
    • Tutorial write your own Redis untuk membuat sendiri protokol Redis dan server sederhananya tetap menjadi tulisan populer yang dibuat sekitar 10 tahun lalu

  • Single-threaded, event-based, in-memory

    • Desain single-threaded Redis menjamin atomicity semua operasi, sangat mengurangi kompleksitas dan membuat penalaran jauh lebih mudah
    • Agar model single-threaded ini bekerja, server harus diimplementasikan dengan non-blocking I/O, dan operasi datanya juga harus sangat cepat
    • Kombinasi ini memungkinkan sebuah key/value store cepat yang bisa melayani banyak klien hanya dengan satu thread

  • Struktur data yang pas untuk aplikasi web

    • String dan expiry cocok untuk cache, list cocok untuk queue, dan hash cocok untuk data terstruktur
    • Kegunaan seperti lock, counter, rate limiting, liveness, monitoring, dan leaderboard juga bisa dibangun dengan mudah hanya dari tipe data bawaan

Ambisi untuk Menjadi Database

  • Adopsi Redis tumbuh cepat dan meraih sukses besar, tetapi pada titik tertentu ambisi proyek ini bergeser ke arah menjadi database
  • Beberapa fitur memang benar-benar berguna, dan BZPOPMIN yang ditambahkan di Redis 5.0 memungkinkan blocking pop saat sorted-set dipakai sebagai priority queue, sehingga meningkatkan kepraktisannya
  • Sebaliknya, fitur seperti ACL terasa tidak seperti Redis, dan secara umum tampak jelas adanya dorongan untuk menjadikan Redis sebagai segalanya bagi semua orang
  • Penambahan fitur Redis selama 10 tahun terakhir sejalan dengan pola mengikuti “tren terbaru” yang dibicarakan developer di Hacker News
    • Karena MongoDB menyimpan JSON, Redis juga harus menjadi document database
    • Karena ElasticSearch menyediakan full-text search, Redis juga harus menjadi search engine
    • Saat graph database mendapat perhatian, Redis juga mencoba menjadi graph database, tetapi kemudian berujung pada RedisGraph EOL
    • Saat Kafka menjadi sorotan, Redis juga ingin menjadi event streaming platform
    • Saat ZooKeeper dan database dengan konsistensi kuat menjadi penting, muncullah Redis-Raft, dan analisis Jepsen dari Aphyr dianggap nyaris wajib dibaca
    • Saat InfluxDB mendapat perhatian, Redis juga ingin menjadi time series database
    • Agar tidak tertinggal dari gelombang AI, Redis juga merasa perlu fitur terkait AI seperti vector sets

Harga dari Ekspansi Fitur

  • Masalah pertama adalah Redis melemahkan sendiri faktor-faktor yang dulu membuatnya menjadi alat penting di hampir semua stack
    • Redis itu sederhana, perintahnya ortogonal dan didefinisikan sempit, protokolnya rapi, dan alatnya konsisten secara konseptual
  • Masalah kedua adalah pengguna yang benar-benar ingin mengintegrasikan full-text search, event stream processing, key/value dengan strong consistency, time-series, atau vector storage, sebenarnya menginginkan alat khusus, bukan modul setengah matang yang mewarisi keterbatasan Redis
  • High availability Redis itu kompleks, persistence-nya memiliki trade-off yang halus, dan beban protokol serta fragmentasi klien juga menjadi hambatan nyata
  • Redis bukan alat untuk menggantikan Postgres, dan sistem seperti ElasticSearch serta RabbitMQ tetap harus berdiri sebagai pilar mereka sendiri
  • Analisis Aphyr atas implementasi awal Redis-Raft menyebut telah menemukan 21 masalah
    • periode tidak tersedia yang panjang pada cluster yang sehat
    • 8 crash
    • 3 stale read
    • 1 aborted read
    • 5 bug yang menyebabkan hilangnya pembaruan yang sudah di-commit
    • 1 infinite loop
    • 2 masalah yang dapat mengirim respons yang rusak secara logis ke klien
    • versi pertama yang diuji, 1b3fbf6, dinilai pada praktiknya tidak layak dipakai
  • Redis sebagai cache dan data structure server serta Redis yang ingin menjadi “Redis the etcd” atau database khusus lainnya pada dasarnya adalah dua proposal yang berbeda, dan jurang inilah masalah utamanya

Pola yang Sama yang Terlihat pada Disque

  • Pada 2015, antirez memperkenalkan Disque, dan saat itu ia mengakui bahwa proyek ini tidak berangkat dari use case nyata, melainkan dirancang dalam “astronaut mode” setelah melihat orang memakai Redis seperti message queue dan melihat message queue lain
  • Proyek yang dibuat tanpa use case nyata, sekadar sebagai tantangan pribadi atau proyek belajar, tetap bisa sangat baik, tetapi apakah proyek itu bisa terus menyelesaikan ekor panjang masalah sulit yang muncul setelah penggunanya bertambah adalah persoalan lain
  • Pengiriman pesan dengan high availability adalah masalah yang memang sulit diselesaikan dengan benar, dan apa pun sisi CAP theorem yang dioptimalkan, trade-off serta persoalan sulit tidak bisa dihindari
  • Pada 2015, message broker yang matang sudah banyak, dan alasan orang memakai Redis sebagai message broker adalah karena mereka sudah menggunakan Redis dan Redis cukup sederhana
  • Yang dibutuhkan bukan message broker baru, dan juga bukan Redis yang berubah menjadi message broker yang lebih rumit
  • Tak lama setelah diumumkan, Disque pada praktiknya menjadi abandonware, dan meski meraih 8K stars di GitHub, proyek itu dibiarkan begitu saja
  • Setelah itu ia ditulis ulang sebagai modul Redis, tetapi proyek itu pun dibiarkan terbengkalai selama 7–8 tahun terakhir

Arah Lain yang Ditunjukkan Valkey

  • Kekuatan yang menggerakkan arah Redis dapat diringkas sebagai ambisi developer untuk memecahkan masalah yang kompleks, ambisi untuk menjadi segalanya bagi semua orang, dan ambisi pemilik Redis untuk memaksimalkan keuntungan sebelum kalah dari AWS dan GCP
  • Ambisi itu sendiri bukan masalah, tetapi menjadi masalah saat membuat Redis kehilangan alasan keberhasilannya
  • Keberadaan dan adopsi Valkey diajukan sebagai penilaian akhir pasar yang lebih luas atas dinamika ini
  • Alih-alih mengejar fitur atau bullet point di tabel perbandingan, Valkey berinvestasi pada pekerjaan yang kurang glamor seperti kinerja multithread, efisiensi memori, keandalan cluster, dan peningkatan throughput
  • Benchmark performa Valkey mengesankan, dan secara langsung menyasar 80% pengguna Redis yang merasa fitur Redis 2011 saja sudah cukup
  • Dalam dunia Valkey, kesimpulannya adalah tidak perlu ada array type baru

Bacaan terkait

1 komentar

 
GN⁺ 4 jam lalu
Komentar Lobste.rs

  • Dari sudut pandang seseorang yang pernah membesarkan open source hingga skala cukup besar, mendirikan perusahaan, mencapai pendapatan ratusan juta dolar, IPO, hingga diakuisisi miliaran dolar, dan dalam prosesnya juga pernah mengubah lisensi hingga keluar dari OSS, positioning Redis sebagai “mesin konteks real-time untuk aplikasi AI” tampak masuk akal dari sisi arah
    Dalam pembelian software ada pengguna langsung dan pengambil keputusan teknis (TDM), dan landing page Redis terlihat seperti situs yang membidik TDM yang memegang anggaran, bukan developer pengguna langsung. Banyak TDM cenderung memilih keputusan yang aman dari risiko pemecatan, seperti pepatah “tak ada yang dipecat karena memilih IBM”, dan jika Gartner atau McKinsey menekankan strategi AI serta pengelolaan konteks, maka “Context Engine untuk aplikasi AI” menjadi alasan pembelian yang bisa dipertahankan
    Di HashiCorp juga pernah ada upaya memisahkan terraform.io untuk praktisi dan hashicorp.com untuk TDM, dan sampai batas tertentu berhasil, meski ada juga keterbatasannya. Ini memang masalah sulit bagi perusahaan OSS yang digerakkan developer
    Tombol “gunakan Redis gratis” dan “minta demo” juga tidak aneh dari sudut pandang TDM. TDM tidak ingin bertanggung jawab atas keputusan teknis dan justru lebih ingin membayar serta membeli software, jadi opsi gratis diturunkan jadi semacam versi uji coba, sementara call-to-action yang menghubungkan ke manusia ditaruh di depan
    Eksekutif Redis Inc. tampaknya menyimpulkan bahwa menarik perhatian TDM lebih penting daripada developer/operator, dan tanpa data internal sulit mengatakan itu benar atau salah, tetapi ini tampaknya bukan strategi yang lahir tanpa niat
    Penambahan fitur terus-menerus juga masuk akal karena biaya memperluas alat yang sudah ada jauh lebih rendah daripada biaya mengadopsi alat baru. Bahkan tanpa motif komersial, bahasa pemrograman pun sering kali berubah dari menjaga identitas inti menjadi penyebut bersama minimum dari semua fitur, dan di perusahaan komersial pola “land and expand” bekerja sangat kuat. Setelah kontrak pertama didapat lewat fitur andalan, departemen pengadaan jauh lebih mudah memproses perluasan kontrak yang sudah ada meski yang dijual hanya fitur tambahan kelas rata-rata, dibanding membuat kontrak baru
    Klaim bahwa “pelanggan serius pasti menginginkan produk yang benar-benar spesialis untuk pencarian khusus/event stream/KV dengan konsistensi kuat/time-series/vector store” juga sangat bisa diperdebatkan. Bahkan jika hanya melihat data perusahaan software publik, pelanggan sering memilih opsi yang lebih buruk karena alasan nonteknis
    Juga sulit memastikan bahwa Valkey adalah putusan akhir pasar. Valkey memang berjalan jauh lebih baik daripada fork rata-rata (https://redmonk.com/sogrady/2026/04/06/valkey-at-two/), tetapi dari luar Redis sebagai perusahaan juga tampak cukup bertahan. Jika melihat perusahaan seperti ElasticSearch atau MongoDB yang mengganti lisensi dan tetap tidak mengalami pukulan besar pada valuasi pasar publik meski muncul fork, kesimpulan lain juga mungkin. Dari dalam bubble developer ini mungkin terlihat berbeda, tetapi jika pendapatan adalah indikator akhir yang paling tertinggal, orang juga bisa bertanya, “apa itu benar-benar penting?”
    Ini bukan untuk membela kepentingan komersial, hanya berbagi perspektif dari sisi tersebut. Mirip seperti ketika menghadapi hasil pertanian yang sama, orang yang berbelanja dan petani memiliki pertanyaan serta tujuan yang sepenuhnya berbeda

    • Penjelasan tentang “mengapa” dari sudut pandang komersial disampaikan dengan baik, dan menambahkan konteks bahwa Redis tidak berada dalam ruang hampa software murni, targetnya bukan para geek OSS, dan para pengambil keputusan punya standar berbeda dari system engineer
      Meski begitu, logika ini terasa mengandaikan bahwa tujuan semua orang adalah uang. Ambisi untuk menghasilkan uang sangat besar dari Redis hanyalah satu jenis ambisi tertentu, dan dari sikap antirez dalam tulisannya, ia tidak terbaca sebagai orang yang terlalu peduli pada uang dalam skala besar
      Sebagai contoh tandingan ada SQLite. Ia tidak berbicara tentang pendapatan jutaan atau akuisisi miliaran dolar, melainkan fokus diam-diam menyediakan sesuatu yang terdefinisi dengan baik. SQLite tidak kehilangan alasan mengapa ia menjadi database embedded paling populer, dan di sisi database besar Postgres juga serupa. Dari dunia seperti ini pun ada cukup banyak contoh tandingan, sama seperti dari dunia uang dan kepentingan komersial
      Untuk Redis, “kita sudah memakai AWS/GCP, jadi pakai saja sesuatu yang mirip Redis dari sana” tampak sebagai hasil alami dari ekspansi horizontal. Jalur yang lebih ala IBM adalah memilih penyedia cloud lalu memakai Redis mereka, dan akhir-akhir ini itu berarti Valkey
      Bahwa orang sering memilih opsi yang lebih buruk bukan bahan perdebatan, melainkan fakta, dan fakta bahwa Redis berkembang dalam mode seperti itu justru merupakan contoh ambisi dan penyimpangan arah yang ingin ditekankan
    • Saya pernah bekerja di Redis Labs, jadi nyaris secara harfiah berada di posisi advokat developer iblis. Saat keluar saya tidak mengeksekusi opsi saham yang sudah vesting, dan karena saya tinggal jauh dari Silicon Valley, saya bisa bicara tanpa terlalu khawatir membakar terlalu banyak jembatan
      Dulu redis.com adalah situs untuk TDM dan redis.io untuk developer, tetapi setelah Redis Labs mengambil alih redis.io yang dimiliki antirez, mereka merusaknya sampai-sampai bahkan tautan unduhan sulit ditemukan, dan sekarang kedua URL itu sama-sama mengarah ke situs untuk TDM. Bahkan sekarang pun tautan unduhan Redis sulit ditemukan; rasanya ingin menyuruh orang mencarinya sendiri saja
      Masalah intinya adalah Redis Labs selalu sangat buruk dalam merekrut kepemimpinan pemasaran. Para CMO dan VP datang, membakar sebanyak mungkin goodwill dalam waktu singkat, lalu enam bulan kemudian pergi menuju “petualangan berikutnya”. Setelah melihat traffic redis.io jauh lebih besar daripada redis.com, mereka tampaknya merusak redis.io dengan harapan orang yang gagal menemukan tautan unduhan akan menekan “try free”; ini terasa seperti contoh klasik hasrat klik jangka pendek
      Menjual fitur tambahan juga membantu diferensiasi melawan pesaing dalam daftar cek fitur. Terutama ketika sulit bersaing lewat harga, dan AWS bisa membundel ElastiCache dengan diskon cloud yang agresif, sementara pesaing terburuk adalah Redis open source yang gratis
      Valkey mendapat dukungan dana jauh lebih besar daripada fork biasa. Misalnya, mantan kepala developer relations Redis Labs sekarang mengerjakan Valkey di AWS
      Namun penilaian bahwa Valkey hanya melakukan “pekerjaan yang tidak mencolok” terasa agak disayangkan. Redis sebenarnya sudah multithread sejak lama; control plane memang masih single-thread, tetapi I/O sudah multithread, jadi pekerjaan Valkey tidak semenovel yang dibayangkan penulis
      Valkey secara terang-terangan adalah operasi agar perusahaan cloud seperti AWS bisa terus menjual Redis tanpa membayar siapa pun. Argumen lain hanyalah alat pemasaran untuk meyakinkan orang agar membiarkan mereka terus melakukan hal yang memang ingin mereka lakukan, dan jika mereka menilai memutus kompatibilitas dengan Redis menguntungkan secara komersial, mereka akan melakukannya. Saya bahkan cukup berani bertaruh bahwa di kedua sisi mungkin sebagian itu sudah terjadi, hanya saja saya belum mengikutinya cukup dekat
      Jika Anda menginginkan fork Redis yang sungguh-sungguh berusaha menjaga kesederhanaan sambil melakukan pekerjaan yang tidak mencolok, ada redict
      Meski begitu, saya rasa masa Redis memang mulai berakhir. Dalam lanskap komersial aneh saat ini, masing-masing fork pincang di titiknya sendiri. Bahkan redict yang paling berbudi sekalipun tampaknya kurang punya minat nyata untuk mendorong Redis maju dengan cara yang sama seperti ketika antirez mendorong proyek aslinya secara diktatorial. Ini bukan berarti software yang “selesai” itu buruk, tetapi saya merasa Redis masih punya wilayah keren yang belum ditemukan, dan saya ragu fork-fork komersial akan menciptakan ekosistem seperti itu. Tentu saja, bisa jadi saya meremehkan nilai Arrays dan aplikasi terkait AI, jadi saya tetap terbuka untuk mendengarkan
      Kalau dipikir-pikir lagi, cukup mengejutkan betapa parahnya Redis Labs mengacaukan semua ini, dan syukurlah sudah cukup lama berlalu sehingga saya kini tidak lagi terlalu marah
    • Rasanya perusahaan-perusahaan memang ingin mengambil sebanyak mungkin tanpa membayar. Mungkin itulah sebabnya Redis, MongoDB, dan HashiCorp pada akhirnya juga mengubah lisensi mereka

  • Di kantor kami sedang membuat sistem antrean kerja yang lebih adil dengan skrip Lua, dan Redis terasa sangat aneh. Model mental saya selalu “sekadar key-value store sederhana”, tetapi lalu saya harus mempelajari segala macam fitur seperti kemampuan menjalankan skrip Lua di dalam global lock
    Tapi dokumentasinya dipasang di situs web yang berkilau dan tidak menjelaskannya dengan jelas. Nilai konfigurasi pun dijelaskan hanya di dalam contoh konfigurasi
    Saya tahu Redis bekerja dengan baik dan semua orang juga bilang begitu, tetapi pengalaman mempelajari fitur-fitur Redis cukup tidak nyaman. Rasanya seperti seseorang membuat program yang sangat bagus, lalu melupakan dokumentasi hebat yang biasanya seharusnya menyertai program bagus
    Keluhan yang aneh memang. Redis tampaknya bekerja luar biasa baik, dan saya suka dokumentasi seperti Postgres yang menjelaskan “semuanya”