What's shipping.

Scaling network connections with a dedicated OS thread per client creates heavy memory and context-switching overhead under load. AsanagiDB 2.0.0 rebuilds the graph server on a libxev event-loop reactor: one loop thread multiplexes every connection into a bounded worker pool, retiring AsanagiDB's legacy thread-per-connection model and its 256-connection ceiling.

Each platform gets the right I/O backend underneath: epoll on Linux, kqueue on macOS. Windows has no event-loop primitive suited to this, so it runs a blocking Winsock path instead — but that path goes through the exact same framing, dispatch, auth, and worker-pool code as the other two, so every wire protocol and every feature behaves identically on all three.

On the Linux/epoll build we've verified 4,000–6,000 concurrent connections and roughly 72,000 open/close cycles with flat memory and no file-descriptor leaks. macOS/kqueue is in daily use; the Windows blocking path is functionally verified — 200 concurrent connections, flat handle count across churn — but hasn't been load-tested at scale.

What's new in 2.0.0:

• TLS 1.3 — native server-authenticated encryption on the TCP listener via --tls-cert / --tls-key.
• Backpressure, not drops — a bounded execution pool returns a clean Gremlin 597 "too busy" when the queue is full, instead of dropping the socket.
• WebSocket SASL PLAIN — end-to-end authentication over WebSockets.
• Cross-platform asna REPL — the interactive Gremlin console now builds on Windows and cross-compiles for every platform.
• Reliability — fixes the write-load socket drops (write: broken pipe) and the client reconnect stampede that followed.

Three wire protocols run on the reactor: WebSocket (GraphSON / GraphBinary), ASNA binary, and JSON-line.

Install with Homebrew — brew tap asanasoft/tap && brew install asanagidb — or download for macOS, Linux, and Windows from the downloads section →. Read the full changelog →.

— Alfred

We're building AsanagiIDX — a self-hosted MLS listing platform on top of the AsanagiDB graph engine. It is not yet available for download; this is a preview of what it does and how it is priced.

Most IDX products are hosted: your listings sit on a vendor's servers and your website embeds their widget. AsanagiIDX runs on your own server instead. It pulls your feed from MLS Grid's RESO Web API on a schedule, maps each listing, agent, office, and open house into AsanagiDB as connected records, downloads listing photos into an object store you control, and serves a REST search API your pages call directly. You host it, and the data and MLS credentials stay with you.

What it includes:

• Incremental RESO sync — rate-limited background ingestion with an upstream-failure circuit breaker.
• Graph-native schema — listings, listing agents, offices, and open houses linked as records and edges, indexed for structured search.
• Media you own — an async downloader and garbage collector that store photos in an S3-compatible or local object store.
• One license — a single named license that includes the AsanagiDB entitlement it needs; bound to one MLS feed.

Pricing is final and listed on the AsanagiIDX product page →. For an early build for your brokerage, email [email protected].

— Alfred

Most "graph-powered AI memory" today is a vector search index with a graph label on it. AsanagiDB is a real property graph instead — actual Gremlin traversal, relationships stored as first-class edges rather than similarity scores. Here's how I got here, and what's ready today.

This idea has been with me a long time. Back in 2016, while working at Manulife/John Hancock, I discovered Gremlin, the Tinkerpop project, and Bitsy — a small, open-source, embeddable graph engine that fit what I was building perfectly. But what I actually wanted didn't exist: a graph engine as a server, simple enough for a lone developer or a small team to just run — no costly licenses, no installation ceremony. Something as approachable as MySQL used to be, before it wasn't free anymore. Graph databases have real, broad applications, but the friction and cost put them out of reach for exactly the people who'd benefit most.

That gap sat with me for years, and the push to finally close it wasn't a tool — it was a conviction: if AI is going to be genuinely useful over the long run, models need to actually learn from working with people, and with each other, not just retrieve on demand. That takes real infrastructure, not a workaround. I decided not to follow the crowd and create yet another JVM-based product. I wanted something lean, fast, and simple. Zig and LMDB turned out to be the right foundation for it. Ok, the development wasn't simple — it was excruciating — but I knew I could make the goal real, so I did.

That's the origin. Here's the point: if an AI agent is going to have genuine long-term memory, I wanted it to be a real graph of what it knows and how those things connect — not a lookup table borrowing a graph's name. That idea is now a working product suite, not just a design doc:

• AsanagiDB Server — the graph engine itself.
• Admin CLI (asanagidb-admin) — manage and script your database from the terminal.
• MCP Server — drop AsanagiDB straight into Claude, or anything else that speaks MCP, as genuine persistent memory.
• Admin UI — a native graph browser and Gremlin console, no Electron.

Four pieces, one coherent system, all available today: asanagi.ai

(The name, if you're wondering: "Asanagi" means "morning calm" — the goal was always to cut the friction out of using these tools, not add to it.)

This is a pre-v1.0.0 release — deliberately so. I'd rather ship early and let real use shape what 1.0 becomes than sit on it until it's "finished." The core is stable and I run it myself daily, but expect the APIs and on-disk format to keep evolving for a while yet. If you try it now, you're trying it early — that's an invitation, not a disclaimer.

Next up: AsanagiLIS, a local inference server that uses AsanagiDB as an AI's actual long-term memory, and AsanagiDB 2.0 after that. If you want to know the moment either ships:

Subscribe for release announcements

— Alfred