Comments URL: https://news.ycombinator.com/item?id=47931785

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47888756

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47884000

Points: 1

# Comments: 1

Shipped v0.1.0 yesterday, v0.2.0 today with cluster mode. Streaming support coming next.

Existing options locked you into one tier (LangChain = LLM only, LangGraph = state only) or one framework. This solves both.

npm: https://www.npmjs.com/package/@betterdb/agent-cache Docs: https://docs.betterdb.com/packages/agent-cache.html Examples: https://valkeyforai.com/cookbooks/betterdb/ GitHub: https://github.com/BetterDB-inc/monitor/tree/master/packages...

Happy to answer questions.

Comments URL: https://news.ycombinator.com/item?id=47792122

Points: 18

# Comments: 5

Comments URL: https://news.ycombinator.com/item?id=47662866

Points: 40

# Comments: 5

Comments URL: https://news.ycombinator.com/item?id=47623672

Points: 1

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=47603123

Points: 5

# Comments: 1

Redis 7.4 broke data file compatibility with Valkey. RIOT, the only widely-used open migration tool, was archived last October with no open replacement. And the clouds - AWS, GCP, Redis Cloud - have no incentive to make leaving easy. If you want to move between providers, switch protocols, or get off managed infrastructure entirely, you're on your own.

BetterDB ships a three-phase workflow to fix that:

Analysis - scans your keyspace and flags blocking incompatibilities before anything moves. Green/amber/red verdict.

Execution - RedisShake for same-protocol speed, or command-based for cross-version and cross-protocol migrations where binary transfer fails.

Validation - key count comparison, sample spot-check, and performance baseline comparison against pre-migration snapshots.

Any direction. Any provider. Standalone or cluster.

docker run -p 3000:3000 betterdb/monitor

Website: https://betterdb.com Repo: https://github.com/BetterDB-inc/monitor Docs: https://docs.betterdb.com

Comments URL: https://news.ycombinator.com/item?id=47601577

Points: 15

# Comments: 6

Comments URL: https://news.ycombinator.com/item?id=47522004

Points: 3

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=47504489

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47501798

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47483431

Points: 18

# Comments: 1

I’ve been experimenting with building an “improved” version of Redis using Rust as a personal project over the last few months in what started as a “what if” and has become something I’ve found myself more and more interested in. After the HN post last week I decided to see if there’s interest in such a more serious project that, despite having a bunch of AI-generated code. still aspires to someday be a quality tool. I definitely don’t claim to have created this thing all by myself, but I’ve put a lot of time guiding the implementation and testing.

Creating databases in the age of AI is still hard so I’ve been leaning on a bunch of testing from my experience in distributed systems design over the years to try and prove its correctness: “trust me bro” doesn’t work over network boundaries of course. I don’t claim that the code is good or idiomatic and only have a beginners knowledge of rust from working on another personal project a few years back, so any “adults” with working Rust experience are welcome to provide feedback and direction.

It currently supports all of the current Redis 8.0 functionality, including search, vectors, json, probabilistic structures, etc. as well as cluster mode, replication and persistence. I want to make it really easy to operate so I’ve added a host of things like open telemetry, Prometheus, dtrace support, http debug pages, a cli tool, etc.

I have thousands of tests in place not including various black box concurrency testing frameworks like turmoil and Jepsen.

Things I’m currently working to add: Zero downtime upgrades auto cluster rebalancing Auto data migration proxy Performance improvements like io_uring support

Let me know what you think!

(PS) in the process I tried implementing a coz-style profiler for tokio (current crate has been abandoned) as a side quest to figure out where to best spend time optimizing which has been a fun part of this as well.

Comments URL: https://news.ycombinator.com/item?id=47454669

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47452347

Points: 1

# Comments: 0

I've been working for the past two weeks on BetterKV, a Redis-compatible key-value store written in Rust, built from scratch with multithreading at its core.

Redis is single-threaded by design. That's historically fine, but on modern multi-core hardware it leaves a lot on the table. BetterKV was born from that frustration.

*What it is right now:* - 200+ Redis commands supported and growing - Drop-in Redis protocol compatibility, mostly existing Redis clients work out of the box - 10–30x throughput improvement over Redis in our benchmarks (run localy for now) - Most of the Redis toolchain is supported or being actively built

*What it isn't (being honest):* - Not production ready - Two weeks old — expect rough edges and bugs - Source available, not OSS licensed yet

The goal isn't to replace Redis tomorrow. It's to prove that a Redis-compatible store doesn't have to be bottlenecked by a single thread, and to build toward something genuinely production-grade in the open.

If you've ever hit Redis CPU saturation on a beefy server and felt the pain, this is for you.

GitHub: https://github.com/1jmdev/BetterKV Site: https://betterkv.com

Would love benchmark reproductions, issues, harsh feedback, and contributors. It's moving fast.

Comments URL: https://news.ycombinator.com/item?id=47424600

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47391982

Points: 59

# Comments: 30

I spun up a Redis instance and told my Cursor agent:

You're the leader in a multi-agent environment. Here's a Redis connection string you'll use for coordination. Generate a prompt describing how to communicate: how a new worker announces itself, where to get tasks, how to report status, how to resolve blockers. I'll pass this to other workers and won't speak to them after. Split tasks into subtasks and delegate

It generated a prompt which served as a coordination protocol, and I passed it as-is to 3 more agents with that as their system prompt. Then I gave the leader a task: build an app where users upload images and search them semantically: backend, frontend, tests, and a setup doc.

It accomplished the task. The leader delegated work, reviewed output, asked for fixes, and reported back to me. Not perfect, but the coordination held. The issues I saw felt like my task prompting, not the leader-worker setup itself.

The key insight: the prompt IS the communication protocol. You give each agent Redis tools and a prompt that describes the rules: how to announce yourself, where to pick up tasks, how to report back. If you want to change how it works, you only update the prompt which seems to me much easier than to (vibe)code.

Redis turns out to be a decent fit for this:

- useful data structures out of the box: key-value, sets, streams, pub/sub

- built-in auth

- easy to scale the number of agents

- most agents can already connect via redis-cli

- multiple agents can work in parallel without extra setup

The main downsides:

- state is lost if it crashes

- limited observability

- the system prompt needs to be carefully validated

For provisioning I used a side project of mine, Dev2Cloud (https://dev2.cloud) which can get you a Redis instance in seconds. I'm happy to share some API keys.

Has anyone done something similar? Curious what coordination approaches people have tried.

Comments URL: https://news.ycombinator.com/item?id=47370751

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47367499

Points: 2

# Comments: 0

I'm working on small SaaS projects and keep running into the same issue: background jobs require a lot of infrastructure. Even for simple things like delayed tasks or scheduled jobs I end up running Redis, queue workers, cron, retries, monitoring, etc. For bigger systems this makes sense, but for small apps it feels like too much.

I'm thinking about building a small service that would let you send a job via API and get an HTTP callback when it's time to run, without running your own queue or workers. Basically: no Redis, no workers, no cron, no queue server

Would something like this actually be useful, or am I trying to solve a problem that isn't really there?

Comments URL: https://news.ycombinator.com/item?id=47320768

Points: 2

# Comments: 15

Supported Redis commands:

strings: GET, SET, DEL, EXISTS, INCR, INCRBY, DECR, DECRBY, MGET, MSET

expiry: EXPIRE, EXPIREAT, TTL, PTTL, PERSIST

hashes: HGET, HSET, HDEL, HGETALL, HEXISTS, HKEYS, HVALS

lists: LPUSH, RPUSH, LPOP, RPOP, LRANGE, LLEN

sets: SADD, SREM, SMEMBERS, SISMEMBER, SCARD

utility: PING, DBSIZE, FLUSHDB, KEYS

SET options: NX, XX, GET, EX, PX, EXAT, PXAT, KEEPTTL

EXPIRE / EXPIREAT options: NX, XX, GT, LT

LPOP / RPOP options: count

Repository / deployment instructions: https://github.com/zion-off/meowdis

How it works:

1) there’s a compute layer (this can be anything) and a storage layer (a cloudflare durable object instance) 2) you send redis commands to the compute layer using either a) rest b) or upstash sdks (see upstash docs) 3) compute layer translates redis commands to sqlite queries 4) storage layer executes them in a transaction 5)results are returned back to you

post script disclaimer -- this started out as a side project where i was trying to work around fun constriants i made up (serverless, free, etc.). if you try it out and run into problems, bug reports are welcome !!

Comments URL: https://news.ycombinator.com/item?id=47312949

Points: 2

# Comments: 0