KuttiDB.
GitHub Get started
SMALL SERVER. BIG APP ENERGY.

Less to run.
More to build.

Your cache, background jobs, and event streams.
Together in one small C server.

For the SaaS you're building, and the infrastructure
you'd rather keep simple.

Start building See it survive a crash
Open sourceSelf-hostedCurrently in beta
ONE BINARY. THREE EVERYDAY SUPERPOWERS.01 / 04
A little less
on your plate.
KuttiDB's smiling toast mascot
app.py
INSTALL CLIENT
python3 -m pip install --pre kuttidb
from kuttidb import KuttiDBClient

with KuttiDBClient(port=7379) as db:
    db.put("report:42", b"ready", ttl=60)
    status = db.get("report:42")
    print(status)

# b'ready'
A value when you need it. An expiry when you don't.

Install the Python client and connect to a server on port 7379.

Small by design.
Yours to run.
01server binary
Cat the core
Apache 2.0open-source license
macOS + Linuxarm64 & x86_64
01 / A SMALLER STACK

Three essentials.
One place to put them.

The everyday building blocks of a SaaS,
with one server to configure and operate.

01.A / CACHE

Keep hot data close.

Store a value. Give it a TTL. Keep frequently used data handy, with bounded memory and eviction.

report:42readyTTL 60s
Explore the cache
01.B / QUEUES

Give work a home.

Hand a job to a worker. Acknowledge it when it's done. Retry unfinished work and route failures to a dead-letter queue.

reports3 readyACK + retry
Explore the queues
01.C / STREAMS

Keep the story.

Append events to a partitioned log. Save your place with offsets and replay the history within your retention window.

report.readyoffset 42replayable
Explore the streams
Speaks your language.
02 / THE PROOF IS IN THE RESTART

Pull the plug.
Pick up the work.

Cache a status. Process a job. Append an event.
Then crash the process and see what survives.

  1. 01
    Run a real workload

    One report worker. All three engines.

  2. 02
    Kill the process

    A job is still waiting for an ACK.

  3. 03
    Restart. Recover. Replay.

    Reopen the same data directory.

Inspect the real demo source
kuttidb / recovery-demoRECORDED RUN
$ python3 saas_demo.py
Recorded local run · about 9 seconds
Process-crash recovery on the same healthy disk. Cache uses --durability always. This demo does not test disk or machine loss.

    

    
03 / BETTER TOGETHER
Saved it.
Queued it.
Committed together.
When your cache and queue share an engine, the handoff can be one durable operation.
Read the commit contract 
ONE OPERATIONdb.put_and_enqueue(…)
After recovery, both sides exist.
Or neither does.
Cache persistence + durable target queues required.
TAKE THE WORKFLOW FURTHER
Finish this job.
Commit what's next.
Atomic job completion commits durable state, the input ACK, and an optional next message together — with a receipt you can retry while it is retained. Deduplication covers the commit; processing itself remains at-least-once.
Explore job completion Opt-in with --job-completion and a durable queue.

    
04 / EVERYTHING IN VIEW
One small server.
A proper control room.
A self-hosted console for all three engines.
Inspect keys, browse jobs, and tail streams
 through the authenticated Management API.
Meet the console 
KUTTIDB / CONSOLE
ACTUAL PRODUCT SCREENSHOT
KuttiDB console overview showing keyspace, queue and stream summaries, recent jobs, and persistence status
RUN IT NOW
No clone. No build.
npx @kuttidb/management-ui
Node 20+ · Opens at http://127.0.0.1:8080 and connects to your Management API.
View on npm ↗
On your server. In your browser. Under your control.Console source ↗


    

      
IN THE OPEN / PERFORMANCE & PROJECT ACTIVITY
Small footprint.
Numbers you can look into.
Measured workloads. Public project activity.
Every figure comes with its context.

      
THE BENCHMARKS1 SHARED vCPU
Cache write502,332operations / second
Queue publish142,346messages / second
Stream append117,061records / second
Three trials, medians. Batches of 256. Cache: 1-second durability window. Queue & stream: fsync-covered writes. One server; no replication.
Explore results & methodology ↗

      
KUTTIDB IN THE WILD
—installer runs
all time, including repeat runs
— npm— PyPI— crates.io
SDK downloads: npm & PyPI last 30 days; crates.io trailing month. These are activity counts, not unique users.
Explore project stats ↗

      
Loading live public stats…How measurement works ↗

    

    
SMALL BY DESIGN. CLEAR ABOUT THE EDGES.
A single server.
On purpose.
For small and midsize SaaS teams who want
 useful building blocks without a sprawling stack.
Read the tradeoffs 
Where does KuttiDB fit?
Applications running on one server that need caching, background jobs, and replayable events. Local clients can use shared memory; remote clients use KuttiDB's native protocol.
What should I know before deploying?
KuttiDB is beta software with no replication yet. Durable delivery is at-least-once. Cache entries can be evicted by policy. Evaluate these boundaries against your workload.
Is it a drop-in replacement?
KuttiDB uses its own protocol and clients. Migrating from Redis, RabbitMQ, or Kafka requires application changes. It is designed around a smaller, single-server footprint.
Can I keep everything on my own server?
Yes. KuttiDB is self-hosted and Apache-2.0 licensed. The management console is also self-hosted and runs separately against the authenticated Management API.

    
05 / YOUR NEXT FEW LINES
Less infrastructure.
More possibility.
One command to take a bite.
No account. Your machine. Your data.
Getting started guide ↗Browse releases ↗
TRY IT FIRST
Run the recovery demo.
curl -fsSL https://kuttidb.com/demo.sh | bash
macOS or Linux · Python 3.10+ · curl
Temporary demo data. Cleans up after itself.
MAKE YOURSELF AT HOME
Install KuttiDB.
curl -fsSL https://kuttidb.com/install.sh | bash
Checksum-verified releases for macOS and Linux.
Read the installer ↗