Serverless is the default. Use server mode only when you need multi-client or remote access.
Loka can run as an embedded database (open a .sdb file directly, like SQLite) or as a server (HTTP SPARQL endpoint). Both use the same storage format, the same query engine, and the same indexes. The difference is how you access the data.
.sdb file directly — no daemon, no configlocalhost:3030/sparql# Embedded: query a file directly
loka query "SELECT ?s WHERE { ?s a :Person }" --data people.sdb
# Server: start an HTTP endpoint on the same file
loka serve --port 3030 --data people.sdb
# Now accessible at http://localhost:3030/sparql| Use Case | Recommended Mode | Why |
|---|---|---|
| Personal project, scripts, prototyping | Embedded | Zero setup, fastest possible path to querying |
| AI agents (Claude Code, Cursor, etc.) | Embedded | No process management, no port conflicts, deterministic |
| Jupyter notebook exploration | Either | Embedded for local; server if sharing with collaborators |
| Web application backend | Server | Multiple clients need concurrent access via HTTP |
| Multiple processes reading the same data | Server | Embedded mode is single-process; server handles concurrency |
| Remote access from other machines | Server | Embedded mode has no network interface |
| Production deployment | Server | Auth, rate limiting, monitoring, backups |
Embedded mode follows the SQLite philosophy: download one binary, run one command, you have a working database. This is the default because it removes every obstacle between you and your data.
.sdb file is wherever you put it. Copy it, back it up, share it, version-control it.Server mode adds capabilities that embedded mode cannot provide. For anything beyond single-user local access, server mode is the right choice.
/health endpoint exposes index health, tombstone ratios, and pseudo-table coverage for observability.| Embedded | Server | |
|---|---|---|
| Setup complexity | None | Minimal (one command, but you manage a process) |
| Concurrent access | Single process only | Multiple clients |
| Network access | Local only | Remote + local |
| Auth & security | File system permissions | Passcode auth, rate limiting, query timeouts |
| Backups | Copy the file yourself | Automatic periodic backups |
| Data visibility | Plain file — easy to find, but also easy to accidentally delete | Managed by the server process |
| Performance overhead | None (direct access) | HTTP serialization/deserialization per query |
.sdb file format is the same regardless of how you access it. You can prototype in embedded mode, then deploy the same file in server mode without any migration or conversion.
| Database | Embedded | Server | Data Model |
|---|---|---|---|
| Loka | Yes (default) | Yes | RDF-star + vectors |
| SQLite | Yes | No | Relational |
| PostgreSQL | No | Yes | Relational |
| Apache Jena Fuseki | No | Yes | RDF |
| Neo4j | Yes (embedded Java) | Yes | Property graph |
| Qdrant | No | Yes | Vectors |