Archives

How Nexora embeds Lua 5.4 as a scripting and REPL layer — the UserData bridge that turns GraphStore methods into Lua calls, the sandbox that keeps scripts from escaping to the OS, and the REPL's expression auto-eval trick.

How Nexora's WAL intercepts every page write, what a WAL frame looks like on disk, how recovery scans the sidecar file after a crash, and how checkpoint-on-close moves data back to the main file.

How Nexora maps a logical page number to a physical page ID in O(1), what a directory page looks like on disk, and how the index grows when the database exceeds a single directory page.

How Nexora caches pages in memory to avoid redundant disk reads, what the clock eviction algorithm does, and how dirty pages are written back on close.

How Nexora deduplicates label strings, maps label IDs to string data in O(1), and stores variable-length strings in a two-ended buffer with overflow chaining.

A deep dive into how Nexora stores edges on disk — the 64-byte record, the bitmask slot allocator, two simultaneous adjacency lists, and the full cost of deleting an edge.

A deep dive into how Nexora stores, looks up, inserts, and deletes nodes. Fixed-size records, identity-bound slots, O(1) direct addressing via the page index, and why deleted nodes leave permanent holes.

Every database is ultimately a file. This post walks through how Nexora lays out nodes, edges, and properties on disk — fixed-size pages, a root-pointer manifest, intrusive linked lists for adjacency, and a packed pointer encoding that fits a page address and slot index into a single u64.

Before diving into how Nexora works, this post covers the why and what graph databases are, where relational databases fall short, and why graphs are a natural fit for highly connected data.