Today, June 22, 2026 (wait it's past midnight I mean yesterday), I finally published my first crate to crates.io after over a month of hard work on this tiny idea that just might work: What if you had an in-memory graph database written in Rust, but without enduring the pain of an Arc<Mutex<Box<Rc<RefCell<Weak<RwLock<Cow<Node<T>>>>>>>>>? What if there was no query language? What if there was only one dependency in cargo.toml, and it wasn't serde? And so, I sat down and got to work.
Initial Design
First things first, I had to actually get the idea down before wasting hours fighting the borrow checker. And so I drafted the idea in Python first. It was rushed to completion in a few days as a proof of concept, the major primitive being the Box, acting as a node with graph-level methods being on the same object as static methods or class methods (associated functions). There was also a global box container hiding global state and an Arrow, a thin though bidirectional-enabling edge represented as a tuple (label, reverse_label) with 4 types: child, parent, pointing, and incoming.
A Box was defined by its ID (a UUIDv4), its data (an arbitrary object that would almost certainly fail the JSON serialization that I added with zero checks or custom serialization methods last minute), and four internal lists for children, parents, pointing, and incoming nodes. While a lot would change from this design, I knew leaving the Arrow as explicitly not a first-class-citizen would be helpful, subverting the typical graph database expectation for simplicity. I included many helper methods, allowing one to search any of the arrows with an arbitrary function returning a bool, or find/get data and connect nodes through any of the Arrows conveniently abstracted into a method per operation per arrow.
Of course, while convenient, this was nowhere near production-ready in even the loosest sense of the term, so once I slapped on a super quick README and published to GitHub, I created a new Rust project on a brand new branch, leaving the messiness of Python's dynamic typing and lack of compile-time guarantees behind.
The New Design
I started with a relatively limited knowledge of Rust for a relatively limited project, hoping to just do a simple port while cleaning up the code to remove global state among other things, though I should have known how these things always go at this point. While there was an increase in complexity, I was able to confine it to four useful primitives:
- The
Graph, which now became the center of the design now that it was explicitly created without any no global state (meaning nodes on the Graph did not know about the graph so their function was relatively limited compared to the graph). - The Node (renamed from Box for obvious reasons), doing anything node-specific not involving the rest of the graph except for the UUIDs directly linked to the node that it does know about, including node creation, setting data, and iterating through neighbors, though both the former and latter gained abstractions in the
Graphfor convenience. - The
Arrow, now capable of custom labels and represented by two&'static strs, with the previous arrow types transformed into constants for simplicity. This was originally an enum before custom arrows became such an important part of the design, but was restructured after much careful deliberating on the design of the database implementation, in a stark contrast to the Python implementation. - The
Value, an enum restricting data to easily serializable types, originally housing a custom type with a blanket impl to enable full dynamic typing withFromandInto, but obviously that would have been a nightmare later down the road so it was scrapped. Values also host the core of the serialization and deserialization logic, which I decided to hand-roll with O(n) time complexity. More on that later.
The Graph owns nodes, while the Node owns arrows as part of its linked field, which is simply a HashMap. No frills, O(1) insert and getting, that's all you need. The Node has a Value as its data and therefore owns the Values.
Due to the graph's ownership of nodes, there could be some conflicts with borrowing the graph mutably and the nodes immutably, so the interface is ID-centric so that this is never an issue as long as only IDs are carried around. This is a slight performance trade-off and may be revisited in later versions, but for v0.2.0 it's well worth it and makes the API beautifully ergonomic.
Development Purgatory
At this point, I started to work for hours upon hours upon hours each day on Deebee, eating up my life just to figure out the API. Admittedly, my focus was not great at times and procrastination can never be completely avoided (of course), but I continued to work hard, as the project dragged on with me thinking of better ways to structure the code, running my ideas and finished sections through AI to catch logic errors. I won't get into the fine details, but you can see my previous post on my writing of the serializer. I found that a lot of my earlier design decisions I had to revert or change, such as removing the Arrow argument from traversal (although I will add back an arrow-specific version in a future release) to get the find-type methods working all with a similar syntax.
Meanwhile, before sleeping, I routinely read a bit of the Rust Book, having started this project at Chapter 10 and ending it after having finished Chapter 15. The project and the reading combined greatly boosted my Rust skills in such a short time, and made me feel like I was doing something great with my life. This motivated me to keep going, although I began to contemplate each feature too long as if v0.2.0 had to be perfect. I wouldn't call this development hell per se, but it did extend out the project, kind of like a development purgatory. Eventually, all that was left until I could reach development heaven and release was the dreaded deserializer (to convert exported JSON into a Graph, the most complex part of which being converting the Values themselves) that I knew was going to be hard so I kept delaying further and further until there was nothing left to do. I don't know why I decided to hand-roll the serializer and deserializer, but I did.
The Deserializer
Although it took a while, the logic wasn't too bad all in all. Beforehand, I had drafted a small plan to loop through every character of the value to deserialize, but first the data was matched based on the type it must be; e.g., values with quotes on both ends were matched with a match guard to be converted to Value::Text, or brackets became Value::List.
For text, all that needed to be done was to unescape any special characters (like \n and that kind of stuff), which I was able to do relatively easily with a while let, giving me control over the flow of the loop (skipping and getting the data of items using next()), unlike a simple for loop. This allowed me to look into the future after finding backslashes while keeping it completely O(n).
Lists and Maps had their characters matched against brackets, braces, and quotes, each with a counter that counted the number of these characters the current character was nested in, so only splitting the collections at commas that were not nested in anything. Quotes checked for parity to determine whether to close or open, while the other two simply opened on an open bracket/brace and closed on a closed bracket/brace. Although it was late night when I wrote this logic and I was exhausted, I found the code to be quite elegant.
Since this code was so versatile, I could also reuse it for the top-level deserialization outside of Value. After that was done, all I needed to do was to make sure my codebase, which had ballooned in size after the deserializer logic was done, had no logic errors (which I used AI to check for like a true 2026 programmer), write tests (which I again used AI for*), push, navigate merge conflict issues on an empty stomach, and publish my first crate to crates.io!
However, I believe my live development logs tell the story better than I can with any amount of prose.
9:14 PM: I’m at the last and hardest part of the deserializer: Parsing nested arrays (vectors, lists, whatever you wanna call them) and JSON objects (dictionaries, hashmaps, whatever you wanna call them).
10:36 PM: I just lost a lot of time because I had to eat and actually do some socializing, but we’ll see if I can still get it done.
11:17 PM: Oh, that was easier than I thought. Array parsing done. Once I do the JSON object parsing, which is just reusing the same code with a slight difference, I’ll only have to write the actual to_json function on the Graph, and then ask AI to generate some tests for me. Once they all pass, I can commit, push, and publish!
12:11 AM: Value deserialization is finished and finally hopefully there are no bugs. It is too late. Tests are delayed. I have not implemented from_str but I think it is worth implementing before sleeping. Then I will publish to GitHub. That will be it.
12:16 AM: I have zero brainpower left. Deebee is delayed one more day. Coming Monday, I promise.
12:54 PM: After my worst sleep in probably a month (I started trying to sleep at 1:40 and fell asleep at 3:10 and then woke back up at 4:45 and then woke back up at 8:00 and then woke back up at 10:30 and this time couldn’t fall back asleep despite being super tired [trust me, I tried for 40 minutes to fall back asleep]), I’m back and have already thought of a simple method to wrap up the deserializer. O(n) perfection coming!
2:21 PM: I’ve been coding nonstop, and the deserializer is not perfectly efficient, but I have plans. Assuming all the tests work and all, I can publish. Results coming soon!
2:49 PM: A bit of a hiccup (I discovered there is a tiny memory leak with deserialization, please don’t tell anybody), and it’s about time for tests and finishing up the README!
3:19 PM: Tests now pass, everything is done, pushed to GitHub
3:32 PM: Was a little confusing to merge the Git branches but now that’s done and it’s published to crates.io/crates/deebee!
*I know, I know, but it's a hobby project and besides, it seriously did help me catch a deserialization error and I'm not vibe-coding the database itself.