Your friendly neighborhood database.
One small, fast process on io_uring covers the three shapes of data a backend needs: key-value, JSON documents and slim relational tables. Everything speaks REST, down to the single record. No driver stack, no proprietary protocol.
$ sudo apt install ./luradb_*.deb
$ sudo systemctl start luradb
$ curl http://127.0.0.1:3000/health
{"shards":[…],"status":"ok","version":"0.5.1", …}
$ curl -i -X PUT \
http://127.0.0.1:3000/store-api/kv/default/keys/hello \
-H "Authorization: Bearer $KEY" -d 'world'
HTTP/1.1 200 OK
content-length: 0$KEY is the admin API key in /etc/luradb/luradb.toml.
Three engines, one domain, one API
A domain is the unit you create, protect and back up. Inside it, each engine keeps the shape of data it is good at, and a relational row can point at a key or a document in the same domain.
- RELSlim relational
Tables, indexes, views, left joins. /sql and row endpoints, CSV import with inferred types.
- JSONJSON documents
Versioned documents with ETag, secondary indexes, search queries, NDJSON bulk load.
- KVKey-value
TTL, prefix listings, bulk delete, a resumable watch stream over SSE, conditional writes.
Where to start
Getting started
From the package to the first stored key, document and table.
Operating
Run it under systemd or Docker, size it to the host, keep it safe.
Using
Three data shapes, one REST API, and an MCP server for assistants.
Where LuraDB lives
Nine places where one small process does the job. The tags say which engines carry it.
A backend that ships with your service: one package, one unit, a REST API it talks to directly.
Sessions and tokens with a TTL expire on their own. No Redis on the side.
Give AI agents a real store over MCP: keys for state, documents for context, tables for facts.
Services watch a key and switch the moment it changes. No redeploy, no polling.
Fixed fields in a table, the messy attributes in JSON, linked in one row.
Each tenant gets its own domain, its own API keys, its own permissions.
Catch every incoming payload as it is. Index it, search it later.
A real, persistent store for CI runs, installers and playbooks. Seeded, used, gone.
Sidecar over a Unix socket, installed in one step, under systemd, logging to journald.
The state store behind an installer, the backend of a small web app, a sidecar over a Unix socket, a home lab service.
Domains are spread over data shards; point reads run on the connection thread, longer reads on a reader pool.
No analytical engine, no distributed cluster, no data-warehouse ambition. Features earn their place by making the small case better.