IdeaWell

Project ideas from Hacker News discussions.

Show HN: KiviDB, a faster Redis-compatible memory database and vector cache

Original Article

Hacker News Discussion

📝 Discussion Summary (Click to expand)

1. Heavy reliance on AI for development and testing
Several participants noted the project’s use of AI tools for generating test cases, refactoring code, and writing documentation.

  • “Has there been heavy usage of AI in building this?” – saurilabs
  • “there's a .claude/ in the gitignore” – green-salt
  • “Yes correct … Yes, for building test cases, for code refactoring, and commenting, because it writes cleaner code… The benchmarks I ran were what dragonfly advertises, so scripts for those were written with AI.” – murtazayusuf
  • “I used AI a lot, but I was the one making the design decisions based on the tests that claude picked from my history of troubleshooting sessions…” – murtazayusuf

2. Focus on benchmark methodology, performance numbers, and reproducibility
Commenters asked for more detailed performance metrics (p99 latency, load‑generation concerns) and expressed interest in reproducing or extending the benchmarks.

  • “Pipelined throughput that high usually means the loadgen is the thing you're measuring. Past ~5M ops/sec we needed 3 separate memtier hosts to keep the client off the critical path. Any p99 numbers alongside it?” – falconBrisk47
  • “Just adding my benchmarking repo, that contains terraform code and scripts using which I performed the benchmarks… helpful for re-evaluating and verifying the numbers published on our website.” – murtazayusuf
  • “Could you add Valkey to the benchmark? Curious about different key-types too, like list and hash. Also, big values (2KB) and small values (<256B)” – edoceo
  • “How did overall memory footprint look during ingestion vs Redis? Have any tradeoff graphs as the dataset gets larger and with mixed workloads?” – kingcauchy

3. Interest in comparisons with other datastores and project sustainability
Many remarks centered on how KiviDB stacks up against alternatives (kvrocks, Valkey, MS Garnet) and whether the project might move toward an open‑source foundation.

  • “How does this compare and benchmark with https://github.com/apache/kvrocks” – syepes
  • “I haven’t tested against it, that will be next, i will run the benchmarks on the same method and publish the results…” – murtazayusuf
  • “Kvrocks is on disk, not in memory.” – sligbad
  • “Kvrocks is both iirc, since it can cache the rocksdb data in memory.” – ChocolateGod
  • “And MS Garnet.” – esafak
  • “Nice. I am curious if you would seek to maintain this with some kind of a foundation(apache) based funding or keep it internal to your work?” – ghm2180

🚀 Project Ideas

KVBenchHub: Reproducible Benchmark-as-a-Service for In-Memory KV Stores

Summary

  • A hosted platform that runs standardized benchmark suites across multiple KV stores (Redis, Valkey, Dragonfly, KiviDB, Kvrocks, Garnet) on isolated hardware.
  • Provides automated workload generation (GET/SET, pipelining, list/hash ops, varied value sizes) and collects throughput, latency percentiles, and memory‑per‑key metrics.
  • Core value proposition: eliminates the “I can’t independently verify these numbers” friction by offering verifiable, repeatable benchmark runs with tamper‑proof result logs.

Details

Key Value
Target Audience DB engineers, performance researchers, open‑source maintainers who need credible performance comparisons
Core Feature One‑click benchmark execution with configurable workloads, hardware pinning (NUMA, CPU affinity), and automatic result aggregation & visualization
Tech Stack Frontend: React + TypeScript; Backend: Go microservices; Worker: Docker‑based test harness using memtier/randomized workloads; Storage: PostgreSQL + MinIO for logs; CI: GitHub Actions
Difficulty Medium
Monetization Revenue-ready: subscription tiers (free tier for public runs, paid for private jobs & SLA)

Notes

  • Commenters expressed the need for independent verification: “I haven’t been able to find someone who can independently verify these” (murtazayusuf) and “Was dead because it's BS or wrong or…?” (edoceo). KVBenchHub directly addresses this by providing auditable runs.
  • Users asked for broader data types and larger values: “Could you add Valkey… list and hash… big values (2KB)” (edoceo). The platform’s workload library can be extended to cover those scenarios without changes to user code.
  • A public leaderboard with verifiable badges would spark discussion on HN about trade‑offs (memory vs speed) and encourage contributions to the harness.

Memtier‑Plus: Extensible CLI Benchharness for Modern KV Stores

Summary

  • An open‑source command‑line tool that builds on memtier_benchmark but adds support for list/hash operations, multi‑value sizes, NUMA/CPU pinning, and per‑key memory reporting via integration with each store’s stats API.
  • Enables users to reproduce the exact conditions cited in the discussion (pipeline 16, 100B/1KB/2KB values, separate load‑gen hosts) on any Linux box.
  • Core value proposition: gives engineers a single, configurable binary to run rigorous, apples‑to‑apples benchmarks without stitching together scripts.

Details

Key Value
Target Audience Performance‑focused developers, DB contributors, SREs validating optimizations
Core Feature Extensible workload definition (YAML) supporting GET/SET, MSET/MGET, LPUSH/LRANGE, HSET/HGETALL; optional memory‑overhead collection; automatic load‑gen host distribution
Tech Stack Core: Rust (for low‑latency networking); CLI: Clap; Plugins: dynamic loading via WASM or FFI for store‑specific stats; Build: Cargo + cross‑compile
Difficulty Medium
Monetization Hobby

Notes

  • falconBrisk47 noted needing “3 separate memtier hosts to keep the client off the critical path”; Memtier‑Plus can auto‑spawn multiple worker processes and bind them to distinct cores/NUMA nodes.
  • murtazayusuf mentioned adding “lists and hashes” and “2 KB values” to the harness; Memtier‑Plus includes these out of the box, satisfying the request.
  • The tool would be frequently referenced in HN threads when users share benchmark results, making it a practical utility that garners community contributions.

KVConsistencyKit: Automated Consistency‑Guarantee Validator for In‑Memory Stores

Summary

  • A test suite that subjects a KV store to workloads designed to verify consistency models (read‑your‑writes, monotonic reads, write‑follows‑reads, causal consistency) especially relevant for in‑memory setups where durability may be relaxed.
  • Generates concise reports highlighting violations and latency impact, helping teams decide if a store meets their application’s consistency needs.
  • Core value proposition: shifts the conversation from pure speed (“31× faster than Redis”) to a balanced view of speed vs correctness, addressing ignoramous’ emphasis on durability guarantees.

Details

Key Value
Target Audience Architects and engineers evaluating KV stores for applications requiring specific consistency guarantees
Core Feature Parametric transaction scripts (using a simple DSL) that execute concurrent client sessions, capture histories, and check for anomaly patterns
Tech Stack Language: Python (pytest + hypothesis) for scenario generation; Clients: asyncio + store‑specific drivers; Reporting: HTML/JSON; Optional: eBPF probes for latency overhead
Difficulty High
Monetization Hobby

Notes

  • ignoramous argued “durability guarantees … trump speed” for in‑memory setups; KVConsistencyKit gives a concrete way to measure those guarantees.
  • Users often debate trade‑offs (e.g., shared‑nothing vs fine‑grained locks) – the kit can empirically show how lock granularity affects anomaly rates, providing fodder for HN discussions.
  • By publishing consistency scores alongside throughput numbers, projects like KiviDB can demonstrate they haven’t sacrificed correctness for performance, answering skeptics who question “BS” claims.

Read Later