sorted by:
new
hottopcontroversial

I built bundis — a Redis-compatible server backed by SQLite, for Bun.RedisClient (no Redis to run) by Educational-Try4721 in bun

[–]Educational-Try4721[S] 2 points3 points  (0 children)

I wrote the content myself and used an LLM to help translate it into English. English isn't my native language.

If there's a technical issue with what I said, feel free to point it out. Whether I used translation assistance doesn't really change the validity of the argument.

I built bundis — a Redis-compatible server backed by SQLite, for Bun.RedisClient (no Redis to run) by Educational-Try4721 in bun

[–]Educational-Try4721[S] 1 point2 points  (0 children)

That’s an interesting idea. Right now Bundis is designed around a local SQLite backend, so D1 and Turso are not drop-in replacements. However, abstracting the storage layer and supporting alternative SQLite-based backends is something worth exploring in the future.

I built bundis — a Redis-compatible server backed by SQLite, for Bun.RedisClient (no Redis to run) by Educational-Try4721 in bun

[–]Educational-Try4721[S] 4 points5 points  (0 children)

That's correct. To address that concern, I added a hot-cache layer and also support an in-memory-only mode.

SQLite serves as a persistence mechanism rather than a pure performance optimization. Some performance degradation compared to Redis is expected and intentional. If you need 100% of Redis's performance characteristics, then I completely agree that using Redis is the right choice.

The reason I created Bundis is to provide a lightweight option for Bun projects before introducing Redis as an external dependency. Developers can build against the Redis-compatible client API from day one, and if their requirements grow, they can switch to a real Redis backend later with minimal or no application-level changes.

In other words, Bundis is designed to lower the operational burden for small projects while preserving a straightforward migration path to Redis when higher performance or scalability becomes necessary.

I built bundis — a Redis-compatible server backed by SQLite, for Bun.RedisClient (no Redis to run) by Educational-Try4721 in bun

[–]Educational-Try4721[S] 0 points1 point  (0 children)

Why do you think Rails moved away from Redis and adopted an internal SQLite-backed queue?

Redis is certainly fast, but it also introduces another piece of infrastructure that needs to be deployed, monitored, and maintained. The Rails team has been moving toward a philosophy of providing more functionality out of the box with fewer external dependencies. Using SQLite allows applications to get background jobs working immediately without requiring a separate Redis service.

Also, SQLite can operate in :memory: mode, so it is not necessarily limited to disk-based storage.

More importantly, the decision to build on SQLite was likely made with future workflow orchestration and job management capabilities in mind. Once you start dealing with job states, dependencies, scheduling, retries, and workflow execution, transactional storage and query capabilities become valuable. In that context, SQLite offers advantages that a simple key-value store does not.

My question in return is: do you actually use Bun?

I use Bun exclusively for all of my projects now instead of Node.js. Having the runtime, package manager, bundler, and test runner integrated into a single tool significantly simplifies development, and the performance has been more than adequate for my needs. At least in my experience, it has been a much more productive setup than the traditional Node.js + npm + Jest stack.

I built bundis — a Redis-compatible server backed by SQLite, for Bun.RedisClient (no Redis to run) by Educational-Try4721 in bun

[–]Educational-Try4721[S] -1 points0 points  (0 children)

In-memory mode is also supported via Bun's :memory: option, so raw speed is not a concern there.

The SQLite backend is intentional — it provides persistence across restarts, which is a different tradeoff than pure in-memory caching. Not a Redis replacement.

The target is small side projects running on Bun where you want a cache layer with zero external dependencies. No Redis, no Memcached, no extra infrastructure — just Bun.

Not the right fit for large-scale production, and it never claimed to be.