A few weeks ago, I ran into a frustrating problem. Every time I needed a fast standalone Key-Value cache for my pet projects or microservices, I had to deploy a full Redis instance. Setting up Redis, managing its memory overhead, and dealing with external configurations felt too bloated for small-to-medium tasks.
I just wanted a standalone, native, and extremely lightweight client-server KV database built entirely in modern C#.
So, I decided to build it myself.
That’s how SabaMemDB was born. It’s an open-source, client-server In-Memory Key-Value database focused on performance, zero-allocation discipline, and simplicity.
🛠️ What it does (Features)
Here is what I’ve managed to implement so far:
- ⚡ In-Memory Speed & Zero-Allocation — Super fast data access optimized for performance-critical .NET applications with a focus on low memory footprint.
- ⚛ Atomic Operations — Supports atomic incrementing and decrementing for numeric values out of the box.
- 🐳 Docker-Ready — Ships with a ready-to-use Docker image in the GitHub Registry. No complex installation needed.
- 📦 Client-Server Architecture — Lightweight server instance + standalone client NuGet package.
💻 Quick Code Example
Here is how simple it is to use the client library:
using SabaMemDb.Client
var client = new SMDBClient("localhost:8080", "123");
await client.Set("user:101:score", 100);
await client.Incr("user:101:score", 5);
var score = await client.Get("user:101:score");
Console.WriteLine($"Current score: {score}"); // 105
🤝 The next step: Looking for first contributors!
Right now, I am a solo maintainer working on this in my free time. The core server engine and basic client are fully functional, but there are so many cool features we can add together (like persistent storage snapshots, CLI tools, or advanced data types).
Whether you are a seasoned .NET performance geek or looking to make your very first open-source contribution, you are highly welcome!
To make your start as smooth as possible, I’ve already created a few good first issue tickets on GitHub. They range from simple documentation improvements to minor feature requests and cleaning up open tasks.
- 📂 GitHub Repository: https://github.com/sabaka-chabaka/SabaMemDB
I will personally review every Pull Request, answer all questions in issues, and help you get onboarded.
I’d love to hear your thoughts! Does the .NET ecosystem need more native client-server KV stores, or is Redis always your default choice? Let me know in the comments. And if you like the project, a ⭐ on GitHub would mean the world to me!
Top comments (2)
On the "does .NET need another KV store" question: the first thing many .NET devs will ask when they land on the repo is how this compares to Garnet, Microsoft's Redis-compatible C# store. Being the deliberately simpler, non-RESP alternative is a defensible position — but I'd put that comparison in the README yourself before someone else defines it for you.
Technical question: what's the concurrency model on the server — single-threaded protocol loop like classic Redis, or sharded across threads? For a zero-allocation in-memory store that decision drives most of the performance characteristics, and it's the kind of thing a potential contributor wants to understand before picking a first issue.
On persistence snapshots being on the roadmap: worth deciding early whether a snapshot is copy-on-write or stalls writes during serialization. For cache-style workloads a stall is usually fine, but the moment someone treats it as a primary store, fsync semantics start to matter — cheaper to draw that boundary now than retrofit it later.
Solo-maintainer note: the good-first-issue tickets with personal review are exactly how my one contribution to OSS happened, so +1 on that approach.
Hello! Thanks for feedback!
This project using multi-thread architecture
I think snapshots will work every 30 minutes