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 kristiyan@betterdb.com 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.

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.

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 BETTERDB_LICENSE_KEY=your@email.com \
      betterdb/monitor:latest

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 kristiyan@betterdb.com with:

A bit about yourself and why this is interesting to you Run BetterDB with BETTERDB_LICENSE_KEY=your@email.address

docker pull betterdb/monitor docker run -d \ --name betterdb \ -p 3001:3001 \ -e DB_HOST=your-valkey-host \ -e DB_PORT=6379 \ -e BETTERDB_LICENSE_KEY=your@email.address \ 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/

Callypso | Full-Stack Developer | Remote (EMEA) | Full-time

Join an early-stage, venture-backed startup that solves a real-world problem in the B2B SaaS space. If you enjoy a flat leadership structure in companies where you can contribute to ideas, new technologies, and suggested improvements without going through several levels of managers, this role might be for you. If you like transparency and open communication in a company, if you like focusing on solving problems, instead of attending a million meetings, and if you can appreciate the benefits of being one of the very first recruits in a new startup, then we could be a great fit together!

Stack: ReactJS, NodeJS, MySQL

Salary: $50, 000 - $65, 000 Unlimited paid time off Stock options to boot.

For more info contact kristiyan@callypso.co

Hiya

Janus Workspace Desktop is a desktop application for Linux, Windows and Mac that takes on a different approach to browsing. It allows you to open as many windows as you like in every tab and navigate easily between them.

All windows opened within Janus Workspace share the same session. Meaning you can log in with a certain account once and use the same login in Janus. If you want a separate session, sort of a persistent Incognito you can open such windows as well. It is really useful for monitoring several ad campaigns for different profiles. It supports a huge amount of regular browser functionalities and shortcuts -> https://janusworkspace.com/#features You can find Janus Twitter account at https://twitter.com/JanusWorkspace and here is a simple usage example https://www.youtube.com/watch?v=OSucYy58TgQ

If you want more lightweight and limited version of it you can check out the chrome extension version of it - https://chrome.google.com/webstore/detail/janus-workspace-ne... One user account works for all Janus versions.

If you want to try it out - I have added a special user for Hacker News - username is HackerNews and password is hackernews.

No usage statistics are kept in the application. The only user data that is being kept in it is your registration info. All login details that you use in it are out of Janus's reach. Google Analytics statistic is anonymous and can be stopped from the settings menu.

The code completion in JAVA is probably the only way to write java. It is bit too bloated for my taste with all classes and subclasses that handle almost the same thing (speaking mainly from Android perspective)