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.

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.

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

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

Thank you!

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.

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.

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

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!

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] and paste the first 10 lines of startup logs:

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.)

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.

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.

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

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.

Thank you! I am thinking of also making a chrome extension, if people are finding it useful to directly inject that stat next to the company name in LinkedIn jobs, wework remotely, and so on.

My goal is not to get a job but to create a sort of listing that people can use to see how much the company they have applied to has been flagged over time.

In terms of successful interactions glassdoor and such do a much better job of keeping the positive feedback in place.

I also never attribute to malice that which is adequately explained by stupidity (or incompetence. That being said, I've seen more and more reports on nefarious reasons on why they do post jobs they never intend to fill out. I've seen job postings that have been open for years and people never hear back even with a rejection letter. Or even if they do get a rejection letter that says they've just hired somebody or closed the position, the job post is still up and reposted over and over.

Hey HN!

Sick of applying to jobs and never hearing back? Or finding out the listing was just a ghost job? I built the simplest possible platform where the community can submit companies that ghost applicants or post fake job listings. Let’s hold them accountable together!

Let’s share our experiences and help others avoid the ghosting trap. Join the fight to make hiring more transparent and accountable!

Check it out: https://ghostedby.club/