// Be One With Your Software
Introducing asanaDB
A TinkerPop3-compliant graph database that runs anywhere a binary can. No JVM. No heap tuning. No ceremony.
01. Philosophy
We believe software should be correct and simple, but never simplistic.
Infrastructure that stays out of your way means you think about your problem, not your tooling. That's the goal. Every design decision in all asanaSoft products follows from it.
02. The Case
Ditch
the JVM.
Neo4j shipped its first release in 2007. The JVM was the right call then. Graph databases have outgrown it.
Neo4j Community
- RequiresJava 17+
- Min heap512 MB
- Recommended4 GB+
- Cold start8 – 15 s
- GC pausesunpredictable
- Binary size~450 MB
JanusGraph
- RequiresJava 11+
- BackendCassandra / HBase
- IndexElasticsearch / Solr
- Setup time45 min minimum
- Processes3 JVMs to start
- Binary size>1 GB w/ deps
v0.19.0
- Requiresnothing
- Idle memory~50 MB
- Recommendedwhatever you have
- Cold start< 50 ms
- GC pausesnone. no GC.
- Binary size~5 MB
Enterprise-class graph queries
on a Raspberry Pi.
LMDB is a memory-mapped B-tree used inside OpenLDAP, the Tor Browser, and Apple Mail. It doesn't buffer — it lets the OS page cache do what the OS page cache is already great at. Reads are cache hits. There's no buffer pool to tune. There's no heap to size.
Zig compiles to native machine code with no runtime. No garbage collector means no latency spikes during traversals. What you measure in benchmarks is what you get in production.
// Verified on Raspberry Pi 4 (4GB RAM)
< 2 ms
won't start (OOM)
// Full benchmarks vs Neo4j + JanusGraph — coming soon
03. Products
Four tools. One Purpose: Reduce Friction.
Store your data. Access your data. Our tools are streamlined, transparent, and designed to evolve with users' growing needs. Our roadmaps are carefully planned. New features will be added because they're needed. Not because they're "neat" (though, that wouldn't hurt either! ☺️).
Core Engine
asanadb
The graph engine. Listens for Gremlin queries over WebSocket or HTTP. Stores data in LMDB — your data directory is the entire database. Back it up with cp -r.
- → Gremlin 3.x query engine
- → WebSocket + HTTP transports
- → ACID transactions (LMDB)
- → Fleet config for multi-instance
Memory Layer
asanadb-mcp
The Model Context Protocol server. Your AI agent's persistent brain. Exposes a vocabulary of memory tools so models can read, write, and traverse their own knowledge graph.
- → Works with Claude, Gemini, any MCP client
- → Graph-structured context (not flat files)
- → memory_save / search / context / relate
- → Same binary, different subcommand
Command Line
asanadb-admin cli
Database operations from the terminal. Export to GraphSON, import from any supported format, manage licenses. Pipe it, script it, automate it.
- → asanadb graphson-export — full graph export
- → asanadb graphson-import — GraphSON NDJSON
- → asanadb csv-import / apoc-import / dataset-import
- → asanadb activate — license management
Visual Console
asanadb-admin ui
Browse, query, and manage your graph visually. Live-rendered graph topology, vertex/edge inspector, Gremlin query console. Native on macOS, Windows, and Linux.
- → Live graph visualization
- → Interactive Gremlin console
- → Import / export UI
- → macOS / Windows / Linux native
04. AI Memory
Your model has amnesia.
Until now.
Every conversation starts fresh. Every context window expires. Every insight you built together evaporates when the session ends. You're not collaborating with an AI — you're briefing a new contractor every morning.
asanaDB-MCP gives your model something it has never had before: long-term memory — a persistent knowledge graph that survives context resets, spans sessions, and keeps relationships between facts, not just the facts themselves.
And short-term memory — when a new conversation starts, your model is already warmed up. It knows what you were working on, what decisions were made, and what's still open. No briefing. No recap. The conversation picks up exactly where it left off.
No markdown files. No flat JSON dumps. A graph, where every memory has edges to related memories.
// Without asanaDB-MCP
User: "Hey, where were we?"
Model: "I don't have context from previous sessions.
Could you catch me up?"
// With asanaDB-MCP — new session, zero briefing
User: "Hey, where were we?"
Model: "You were finalizing the logo mockups.
Design approval is still pending — that's the
blocker on the white paper too. Want me to draft
a follow-up to the client?"
GraphRAG. Redefined.
No corpus. No extraction.
No lossy pipeline.
GraphRAG usually means retrofitting a graph onto text that already exists — an extraction pipeline reads documents, infers entities and relationships, and reconstructs structure the source never had explicitly. That's a workaround for data that started as prose. When the agent writing the memory has direct graph access, the workaround has nothing to fix: the relationship becomes an edge the moment it's known, not a sentence a pipeline parses back out later. Same retrieval-augmented pattern — query the graph, ground the answer — without the step that loses fidelity.
Typical GraphRAG
- Text corpus has to exist first.
- An extraction pipeline infers entities and relationships — lossy by construction.
- The graph is a retrieval index, rebuilt periodically as the corpus changes.
- The model is invoked at fixed pipeline steps, not writing the graph itself.
asanaDB
- The agent has direct graph access.
- Relationships are edges, authored at write time — no extraction step to lose fidelity to.
- The graph is the memory, not an index over something else.
- The model reads and writes the graph directly, every session.
The memory vocabulary.
Write a node with body, type, and edges to related concepts.
Fuzzy-match across all node names. Fast enough for real-time use.
Load a node and its neighborhood — the full relational picture.
Draw a typed edge between two existing nodes.
Surface the nodes accessed most recently and frequently. Session continuity.
Write multiple nodes in one round trip. Efficient for bulk context saves.
Connect in three lines.
// claude_desktop_config.json
{
"mcpServers": {
"asanadb": {
"command": "/usr/local/bin/asanadb",
"args": ["mcp"],
"env": {
"ASANADB_NAME": "memory"
}
}
}
}Works with Claude, Gemini, and any agent that speaks the Model Context Protocol. Same config format across all clients.
05. Migration
Already on Gremlin?
Ten minutes.
asanaDB is a drop-in replacement for any Gremlin Server deployment. Your queries port unchanged. Your tooling ports unchanged. You point your application at a different address.
sustained over 12M records
peak throughput
Same machine, same data: 4× Neo4j Desktop's import† on a MacBook Pro M3 18GB.
* LDBC Social Network Benchmark, 11,984,610 records, 0 errors. MacBook Pro M3 18GB RAM. WAL enabled. 4 live indexes: firstName, lastName, browserUsed, title. GraphSON / APOC not yet benchmarked. Methodology available on request.
† neo4j-admin offline bulk import on the same MacBook Pro M3 18GB: ~1.17M nodes/sec for the node pass. Not comparable: database must be offline, no indexes during load, index rebuild time not included. AsanaDB ran with WAL on, 4 live indexes, and zero downtime.
Zero ceremony
Neo4j — what you write before a single row is read
# 22 header files, one per CSV: # header_person.csv :ID(Person)|firstName|lastName|...|:LABEL # header_comment_hasCreator_person.csv :START_ID(Comment)|:END_ID(Person) # header_forum_hasTag_tag.csv :START_ID(Forum)|:END_ID(Tag) # ... 19 more
AsanaDB — the entire import
asanadb dataset-import \ --data-dir ./ldbc_data \ --db mydb
Label inferred from filename (person_0_0.csv → Person). Relationship type inferred from edge filename pattern. No annotation files.
Import your existing data in whatever format you have it:
- CSV Plain vertex/edge CSV files — any schema
- GraphSON TinkerPop standard — export from Neo4j or JanusGraph, import directly
- APOC Neo4j APOC export format — migrate in one step
- LDBC Full LDBC Social Network Benchmark dataset directories via dataset-import — bulk load with WAL enabled and live indices
// Your existing Gremlin. No changes.
// Traverse — unchanged
g.V().has('name', 'Alice')
.out('knows')
.values('name')
// Pattern match — unchanged
g.V().hasLabel('Person')
.where(out('knows').count().is(gt(5)))
.valueMap('name', 'age')
// Single-file import (csv / graphson / apoc)
asanadb graphson-import --file export.json --db mydb
asanadb apoc-import --file apoc_export.json --db mydb
// Bulk dataset import (LDBC / amazon / dblp)
asanadb dataset-import --dataset ldbc --data-dir ./ldbc_dataNOTE: asanaDB targets Gremlin 3.x traversal semantics. OLAP-style steps (PageRank, etc.) are not yet supported.
06. Tiers
Choose your scale.
Every tier ships as a perpetual license by default — pay once, own your binary, own your data forever. Prefer to spread the cost instead? Flip the switch below for monthly billing.
Beta pricing — subject to change at v1.0.0.
Community
Free
perpetual license
- ✓ asanadb server
- ✓ asanadb-mcp (local)
- ✓ 512 MB graph (~250K nodes)
- ✓ Gremlin query engine
- ✓ Admin CLI + imports
- — Remote MCP (tcp://)
- — Authentication
- — Fleet config
Developer
$149
perpetual license
- ✓ Everything in Community
- ✓ 2 GB graph (~1M nodes)
- ✓ Remote MCP (tcp://)
- ✓ SASL authentication
- — Fleet config
- — TLS
Pro
$499
perpetual license
- ✓ Everything in Developer
- ✓ 64 GB graph (this is not a limit)
- ✓ Fleet config / multi-instance
- ✓ TLS
- ✓ Priority support
07. Visual Console
Your graph.
Alive on screen.
asanaDB Admin is a native desktop app — not Electron, not a browser tab. It speaks directly to your asanaDB server over the same ASNA protocol the MCP layer uses. No middleware, no translation layer.
Physics-simulated graph canvas, live Gremlin console, vertex and edge inspector, multi-database switching, and a dedicated Memory view for your AI agent's knowledge graph — all in one window.
Console showing user interaction and node introspection from a query that returned the first twenty "post" nodes out of 1 million, that have associative edges.
08. Document Store
Have Documents?
Will Travel.
asanaDB goes where no graph database has gone before. Drop in a JSON document and it decomposes automatically — nested objects become child vertices, arrays become ordered edges, scalars become indexed properties. No schema. No migration. No ceremony. And, um, no Mongo?
Retrieve it and the graph reassembles into your original document, complete with all nested structures intact. We call it Compository — the same engine that stores it knows how to put it back together.
Because documents live in the graph, you can query
across them with Gremlin. Find all Employee vertices inside a collection of Person documents. Filter by nested field. Traverse relationships
between documents. asanaDB is both your document store
and your graph database — at the same time.
Coming attraction: Because Compository understands your document's shape, it can map that shape to a typed model class. An asanaDB-backed ORM is a natural next step — write objects, query graphs, get objects back. All without leaving the database.
09. High Availability
Zero single points
of failure.
Production databases don't get maintenance windows. asanaDB replicates in real time over a simple TCP connection. When the primary goes silent, the standby promotes automatically — no operator intervention, no quorum vote, no ZooKeeper, no Raft consensus overhead.
Replication is built on the same WAL that makes crash recovery instant. The standby is always caught up. Failover is measured in seconds, not minutes.
One binary. One YAML config. Two instances. That's the entire HA story.
// normal operation
PRIMARY
:8182
● ACTIVE
WAL stream
──────▶
STANDBY
:8183
○ REPLICA
▲ clients connect here
// primary unreachable — auto-failover
PRIMARY
:8182
✗ OFFLINE
~15 seconds
── ✗ ──▶
STANDBY
:8183
● PROMOTED
▲ clients connect here
~15s
Failover time
Primary silence detected; standby promotes.
sub-ms
Replication lag
WAL shipped continuously, not on a timer.
1 field
Setup complexity
Set role: leader or follower in fleet.yaml.