Valkey Turns One: Community fork of Redis

Original Article ↗ Hacker News Discussion ↗

Packaging, Distros, and CI

  • Some want Valkey in default distro repos to avoid adding custom keys/repos in CI (e.g., GitHub Actions).
  • Others note Valkey already exists in many distros (Debian, Ubuntu, Fedora, Arch, RHEL 10, etc.), though often in “universe”/community repos that may not be enabled or fully maintained.
  • Debate:
    • One side prefers distro-maintained packages for stability and security backports, especially for core daemons.
    • The other side argues fast‑moving projects are better served via vendor PPAs/custom repos to avoid being stuck supporting ancient LTS versions.
  • GitHub Actions’ limited base images (older Ubuntu LTS) are seen as its problem; suggestion: use custom Docker images if you need newer Valkey.

Reliability and Managed Services

  • One user reports serious outages with AWS’s managed Valkey: connections accepted but commands never executed, restarts hung, and AWS couldn’t diagnose it; replacing with Redis fixed the issue.
  • Others suspect an AWS operational/network issue rather than Valkey itself, citing similar opaque failures with RDS.
  • Managed cache pricing is disputed: some claim ~10x EC2 cost, others see ~1.4–1.7x overhead.

Corporate Backing and Ecosystem

  • Question raised why Valkey hasn’t had an OpenTofu‑scale “moment.”
  • Explanations: Terraform’s value was more tightly bound to its provider/module ecosystem and registry policies, so license changes felt more threatening.
  • Multiple commenters clarify Valkey is in fact heavily backed (AWS, Google Cloud, Oracle, others) and under the Linux Foundation.

Licensing, Trust, and Forks (Redis vs Valkey)

  • Strong, divided views on Redis’s license changes:
    • Some argue permissive licensing enabled hyperscalers to profit while original authors didn’t, and recommend “fair source”/anti‑cloud clauses.
    • Others see relicensing and CLAs as a “rug pull” on users and contributors, undermining trust and effectively privatizing community work.
  • Redis’s move to add AGPL is seen by many as “too little, too late”; Valkey (BSD) is now the default choice, especially for large cloud users who avoid AGPL.
  • Some argue AGPL is the right long‑term answer to stop free-riding; others emphasize that its incompatibility with major clouds practically guarantees Valkey’s continued momentum.
  • Several note Redis still uses a CLA, so another license change remains possible; this is a key reason some won’t “trust Redis again.”

Technical Evolution and I/O Threading

  • The original Redis author joins to correct the article’s framing: I/O threading was added to Redis in 2020 by him, already respecting the “shared‑nothing” philosophy.
  • He explains the design: parallelize slow read/write syscalls when there is no contention, then immediately return to single‑threaded execution; Valkey later improved this and deserves credit.
  • He disagrees with claims that early I/O threads “did not offer drastic improvement,” pointing to existing benchmarks and calling such marketing/“journalism” misleading.
  • He notes:
    • I/O threading mainly matters at hyperscaler‑level loads; many large real‑world Redis deployments never needed it because CPU wasn’t the bottleneck.
    • His stance on threads is pragmatic, not ideological: they are also used for modules and new vector-set queries, where the data structures have high constant factors and threading pays off.

Valkey vs Redis Going Forward

  • Some believe most end‑users don’t care about the politics and will keep using “Redis” by name; others insist that serious companies do formal license reviews and are actively moving to Valkey.
  • Distro behavior is seen as pivotal: in some cases redis packages already install Valkey under the hood, echoing the MariaDB/MySQL precedent.
  • The idea of re-merging Redis and Valkey is brought up; replies say it’s unrealistic given:
    • Redis did not return to a permissive license (AGPL plus proprietary options instead).
    • Valkey now has strong independent backing and a rapidly growing contributor base.

Clients and Tooling

  • Users on GCP complain about poor official Redis cluster+TLS client support in C, relying on an unofficial hiredis‑cluster.
  • Response: Valkey provides libvalkey, a maintained fork that unifies hiredis and hiredis‑cluster and targets exactly this use case.