kaliades

BetterDB (https://betterdb.com) (https://github.com/BetterDB-inc) | Founding Engineer | Remote | Full-time BetterDB is building the tooling ecosystem for Valkey, the high-performance Redis fork backed by AWS, Google, and Oracle. We're starting with observability — historical persistence, pattern analysis, anomaly detection, and Prometheus export — so you can debug what happened at 3am when you wake up at 9am.

Stack: TypeScript, NestJS + Fastify, React, Valkey, PostgreSQL, Docker, Kubernetes, Terraform, AWS.

We ship OSS self-hosted and have a live cloud SaaS: https://betterdb.com/login In the last two months we've averaged more than one release per week across multiple products and channels. That's what "moves fast" looks like in practice. We recently started moving more and more into the LLM cache space via both observability and actual libraries.

We hired our first engineer in March and are looking to expand the team — no pressure on timeline, we'd rather find the right person.

Just email [email protected] with a bit about yourself and why this is interesting to you. I reply to everyone. It might take a day or two given volume, but you'll hear back.

kaliades

3 mesi fadiscuss

[dead]

kaliades

3 mesi fadiscuss

[dead]

kaliades

3 mesi fadiscuss

Exact match, word for word. agent-cache takes everything that defines an LLM request - which model you're calling (gpt-4o, Claude, etc.), the full conversation history (system prompt + user messages + assistant responses), sampling parameters like temperature, and any tool/function definitions the model has access to - serializes it all into a canonical JSON string with sorted keys, and hashes it with SHA-256. That hash is the cache key in Valkey. Same inputs down to the last character = cache hit, anything different = miss.

If you want the 'basically the same question' behavior, that's our other package - @betterdb/semantic-cache. It embeds the prompt as a vector and does similarity search, so 'What is the capital of France?' and 'Capital city of France?' both hit. The trade-off is it needs valkey-search for the vector index, while agent-cache works on completely vanilla Valkey with no modules.

In practice, agent-cache hits its cache less often than semantic-cache would, but when it does hit, you know the result is correct - there's no chance of returning a response for a question that was similar but not actually the same.

kaliades

3 mesi fadiscuss

It caches AI agent operations in Valkey (or Redis) so you don't repeat expensive work.

Three tiers: if your agent calls gpt-4o with the same prompt twice, the second call returns from Valkey in under 1ms instead of hitting the API. Same for tool calls - if your agent calls get_weather("Sofia") twice with the same arguments, the cached result comes back instantly. And session state (what step the agent is on, user intent, LangGraph checkpoints) persists across requests with per-field TTL.

The main difference from existing options is that LangChain's cache only handles LLM responses, LangGraph's checkpoint-redis only handles state (and requires Redis 8 + modules), and none of them ship OpenTelemetry or Prometheus instrumentation at the cache layer. This puts all three tiers behind one Valkey connection with observability built in.

kaliades

3 mesi fadiscuss

I completely understand your point and have had similar feelings when I've applied to previous companies.

There are 2 points I can make to try and make it make sense (a lot of makes...)

1 - The moment a job post goes live, there are hundreds of applicants. It is an absolute spam. Several have been honest enough to admit they used an AI automation to apply everywhere. This aims to both filter some of the spammers, and also legitimately give people the option to see what they'd work on. Everyone running our product with an email as a license key is assumed a job applicant, and removed from all statistics.

2 - The last time we hired was in February. The moment the role was filled, I left a comment for transparency - https://news.ycombinator.com/item?id=47075520 We are now looking to expand a bit more, so I posted again. I know that the filtering might be frustrating, but try to be on the other side too.

And also, since I am the hiring, interviewing, and everything else person, I don't ghost. It's not much, but it is honest work as the old meme went

kaliades

3 mesi fadiscuss

The simplest approach is the best in 90%+ of the cases!

kaliades

3 mesi fadiscuss

Thank you!

kaliades

3 mesi fadiscuss

That's exactly the bet we're making. The Redis/Valkey ecosystem has enough sprawl - a tool that does one thing well and stays out of the way is what we'd want to use ourselves.

kaliades

3 mesi fadiscuss

BetterDB (https://betterdb.com) (https://github.com/BetterDB-inc) | Founding Engineer | Remote | Full-time

BetterDB is building the tooling ecosystem for Valkey, the high-performance Redis fork backed by AWS, Google, and Oracle. We're starting with observability — historical persistence, pattern analysis, anomaly detection, and Prometheus export — so you can debug what happened at 3am when you wake up at 9am.

Stack: TypeScript, NestJS + Fastify, React, Valkey, PostgreSQL, Docker, Kubernetes, Terraform, AWS.

We ship OSS self-hosted and have a live cloud SaaS: https://betterdb.com/login In the last two months we've averaged more than one release per week across multiple products and channels. That's what "moves fast" looks like in practice.

We hired our first engineer last month and are looking to expand the team — no pressure on timeline, we'd rather find the right person.

To apply, first run BetterDB and use your email as the license key for npm/docker, for cloud just register with the same email you are applying. Pick whichever is easiest:

  Cloud (no setup): https://betterdb.com/login

  Via npm (includes a built-in installer):
    npx @betterdb/monitor

  Via Docker:
    docker run -d \
      --name betterdb-monitor \
      -p 3001:3001 \
      -e DB_HOST=your-valkey-host \
      -e DB_PORT=6379 \
      -e [email protected] \
      betterdb/monitor:latest

Then email [email protected] with a bit about yourself and why this is interesting to you.

I reply to everyone. It might take a day or two given volume, but you'll hear back.

kaliades

4 mesi fadiscuss

Thank you, I'll keep that in mind! That's one thing I like in OSS projects, people share their pain points freely.

Also, that's why I organize things into projects inside Claude (not code) for keeping things separated and organized

kaliades

5 mesi fadiscuss

Update: we've filled this role. Thanks to everyone who applied — and especially to those who actually ran the product. We'll be hiring again soon!

kaliades

5 mesi fadiscuss

BetterDB (https://betterdb.com) (https://github.com/BetterDB-inc) | Founding Engineer | Remote | Full-time

BetterDB is building the tooling ecosystem for Valkey, the high-performance Redis fork backed by AWS, Google, and Oracle. We're starting with observability — historical persistence, pattern analysis, anomaly detection, and Prometheus export — so you can debug what happened at 3am when you wake up at 9am.

Stack: TypeScript, NestJS + Fastify, React, Valkey, PostgreSQL, Docker, Kubernetes, Terraform, AWS.

We ship OSS self-hosted and are launching a cloud SaaS.

We're building in public — open-source core, open roadmap, and transparent about what we're learning along the way. Looking for a senior/founding engineer as first hire. You'll shape the product and architecture alongside the founder (ex-Redis, backed by Open Core Ventures). To apply, email [email protected] with:

A bit about yourself and why this is interesting to you Run BetterDB with [email protected]

docker pull betterdb/monitor docker run -d \ --name betterdb \ -p 3001:3001 \ -e DB_HOST=your-valkey-host \ -e DB_PORT=6379 \ -e [email protected] \ betterdb/monitor:latest

(Yes, this filters out bots. And you get to see what you'd be working on.)

kaliades

6 mesi fadiscuss

They're still wire-compatible for core commands, so most existing code works with both. The main differences so far: - New features diverging: Valkey added COMMANDLOG for query analysis, per-slot cluster metrics. Redis just shipped Vector Sets for similarity search. - As antirez mentioned, this gap will keep widening For now you can use either interchangeably for most workloads, but that window is closing.

kaliades

6 mesi fadiscuss

I remember Vector Sets - I helped Rowan with the vector-sets-browser. Exciting to see you back working on Redis. Would love to hear more about the new data type when you can share. And yes, it is normal for different projects to take on different paths. All the more reason for specific tooling for both as well. I am trying to keep everything Redis compatible as much as possible too.

kaliades

6 mesi fadiscuss

Comment:

Since the fork, Valkey and Redis have been diverging, especially with the latest releases - new features like COMMANDLOG, per-slot metrics, and different optimization paths. Existing Redis extensions might connect to Valkey, but there's nothing built specifically for it. I started the first Valkey-focused VS Code extension (search "valkey" in the marketplace - only result). Features: multi-connection management, key browser, CRUD for common data types (string, hash, list, set, sorted set), and an integrated CLI. MIT licensed, contributions welcome: https://github.com/BetterDB-inc/vscode

kaliades

6 mesi fadiscuss

Thanks! Those are exactly the right questions.

1. Cardinality: We don't do per-key metrics — that's a guaranteed way to blow up Prometheus. All pattern metrics are aggregated at the command pattern level (e.g., HGETALL user:* not HGETALL user:12345). The pattern extraction normalizes keys so you see the shape of your queries, not the individual keys. For cluster slot metrics, we automatically cap at top 100 slots by key count — otherwise you'd get 16,384 slots × 4 metrics = 65k series just from slot stats. The metrics that can grow are client connections by name/user, but those scale with unique client names, not keys. If it becomes an issue, standard Prometheus relabel_configs can aggregate or drop those labels.

2. Baseline window: We use a rolling circular buffer of 300 samples (5 minutes at 1-second polling). Minimum 30 samples to warm up before detection kicks in. To reduce noise from bursty workloads, we require 3 consecutive samples above threshold before firing, plus a 60-second cooldown between alerts for the same metric. This helps with the "batch job at 2am" scenario — a single spike won't trigger, but sustained deviation will. That said, you're right that periodic patterns (daily batch jobs, cache warming after deploy) aren't explicitly modeled yet. It's on the roadmap — likely as configurable "expected variance windows" or integration with deployment events. Would love to hear what approach would work best for your use case.

I think the licensing issues are long gone (it was all the way in 2024), so most people have moved on, but monitoring and observability are something that people have said are missing over and over.

Submissions

Show HN: BetterDB, MIT Valkey-native context layer for AI agents

[untitled]

[untitled]

Show HN: An agent that tunes its own cache

[untitled]

[untitled]

Show HN: Agent cache for Valkey, now in Python with bundled LiteLLM pricing

Show HN: Agent-cache – Multi-tier LLM/tool/session caching for Valkey and Redis

BetterDB – open-source Redis/Valkey migration across clouds and self-hosted

Show HN: Valkey-native semantic cache with OTel and Prometheus built in

Show HN: Let AI agents debug your Valkey/Redis

Show HN: Valkey-powered semantic memory for Claude Code sessions

Show HN: BetterDB Cloud – monitor Valkey/Redis in VPCs with a lightweight agent

Show HN: BetterDB – Valkey/Redis monitoring that persists what servers forget

Show HN: First Valkey-specific VS Code extension (open source Redis fork)

Show HN: BetterDB – OSS Valkey/Redis monitoring with historical data

comments