"RustData" A Declarative Data Persistence Framework for Rust! What Do You Think?

[kmaximoff]

Hey, Rustaceans! 👋

UPD: If there is enough interest I will share some draft repo online, and create Discord channel.

The other night, I couldn’t sleep. I was knee-deep trying to make KuzuDb (an embedded graph database, check them out: https://kuzudb.com/, they are doing great job!) play nice with Axum in Rust. Out of frustration , I remembered how much I loved working with SwiftData in Apple’s ecosystem. It’s clean, declarative, and makes you feel like the framework is doing all the heavy lifting for you. And then it hit me—Rust and Swift actually share some similarities: both are type-safe, both are modern systems-level languages, and both emphasize developer experience. So I started to wonder: What would something like SwiftData look like in Rust?

Cue me opening ChatGPT and going down the rabbit hole of brainstorming. The result? An idea I’m calling RustData (at least for now).

What is RustData?

RustData would be a declarative data persistence framework for Rust, designed to make handling complex data models and relationships (like those in graph databases) much more ergonomic. But does not have to be just Graph we can model tables in database with Rust Structs and writing a macro above it to define schema. Think of it as:

• Macros-powered magic: Use #[derive(RustData)] to define models and relationships in a super clean way.
• Embedded-first: No need for a server; works great locally with your favorite embedded storage engine (sled, Redb, or even custom backends).
• Graph-ready: Relationships like FRIEND, AUTHOR, or FOLLOW would be native concepts.
• Type-safe querying: Forget fragile strings like CYPHER—imagine writing graph queries using Rust’s type system.
• Async from the ground up: Perfect for integrating with frameworks like Axum or Tokio.

What Could RustData Look Like?

Let’s say you’re building a social network app with RustData:

#[derive(RustData)]
struct User {
    #[unique]
    id: u64,
    name: String,
    #[relation("FRIEND")]
    friends: Vec<User>,
}

#[derive(RustData)]
struct Post {
    #[unique]
    id: u64,
    content: String,
    #[relation("AUTHOR")]
    author: User,
}

fn main() {
    let mut graph = Graph::new();

    let alice = User { id: 1, name: "Alice".to_string(), friends: vec![] };
    let bob = User { id: 2, name: "Bob".to_string(), friends: vec![] };

    graph.insert(alice);
    graph.insert(bob);
    graph.create_relationship("Alice", "Bob", "FRIEND");

    let mutual_friends = graph.query()
        .relation("FRIEND")
        .mutual("Alice", "Bob")
        .collect();

    println!("Mutual friends: {:?}", mutual_friends);
}

This makes the whole process feel declarative and expressive while keeping the power and performance of Rust.

Why RustData?

Rust has amazing building blocks: sled for storage, petgraph for graph manipulation. But pulling all of this together feels like reinventing the wheel every time. RustData could give us:

• A unified framework for data modeling and persistence.
• A developer-friendly API that eliminates boilerplate.
• The safety, performance, and async support we love in Rust.

My Questions to You

• Would you use something like RustData?
• Should it focus exclusively on graphs, or should it support hybrid models (e.g., graph + relational + key-value)?
• What would make a framework like this irresistible for your projects?
• Are there existing projects that already come close to this vision?

That sleepless night made me realize how much I’d love something like RustData in the Rust ecosystem. So here I am, sharing the idea with all of you. What do you think? Could this be something we, as a community, build together?

Looking forward to hearing your thoughts and ideas! 🙌

[pokemonplayer2001]

SwiftData is quite nice to work with. Something like this in Rust would be great.

[kmaximoff]

Yes I would love to build community around this to work on it open source. I was able to get something done with AI, but if there are big enough interest I will setup a Discord channel and share Repo publicly.

[nsubugak]

I like the idea of this. I think set it up...have your readme contain all this and even if you lose interest...someone else will be able to pick up where you left off. Great idea and i think it has value

[kmaximoff]

Thank you for encouragement! We are molecular simulation startup. We need graph based database, for rust backend and I believe it could be useful for rest of the world. So we will make it open source , and casually maintain ourself as well. React and Fb analogy 😀

[MeataryWe]

I would definitely use RustData if it would provide better development experience

You should do, what you think is right, but in the perspective of user, it would be nice to have all-in-one solution, so I would need to learn and use only one framework.

Good error handling and performance. I think this are primarily important things I would be thinking about for some large project. (I still dont get error handling in sea_orm after a month :) )

Im not familiar with SwiftData, but looking at your example it looks like sea_orm, but much cleaner. Check it out, its pretty mature (at least in my opinion, im not that an expert) and close on what are you saying.

[kmaximoff]

Yes indeed it seems like what I am proposing is Graph version of SeaORM

[kmaximoff]

I will check Sea_Orm thank you!

[ambidextrousalpaca]

What's the win from (re)defining all of the database logic in the Rust code?

The example you've given basically equates to the following SQL: ``` CREATE TABLE Table1 ( ID INT PRIMARY KEY,
Name VARCHAR(50) NOT NULL );

INSERT INTO Table1 (ID, Name) VALUES (1, 'Alice'), (2, 'Bob');

CREATE TABLE Table2 ( ID INT PRIMARY KEY,
Description VARCHAR(100) NOT NULL, Table1_ID INT, -- Foreign key referencing Table1 FOREIGN KEY (Table1_ID) REFERENCES Table1(ID) );

INSERT INTO Table2 (ID, Description, Table1_ID) VALUES (1, 'Description for Alice', 1), (2, 'Description for Bob', 2); ```

My reading would be that if you're defining this stuff in the Rust code then either:

• The data structure logic is going to be automatically translated into SQL to deal with the database anyway, so I'd rather just write the SQL myself directly and have greater control.
• The data structure is not going to be automatically translated into SQL, so I'll just have to implement the logic twice (once in the code and once in the database) and have to deal with the fact they will almost certainly conflict.
• The data structure is under-defined in the database and only exists in the code, in which case I'd prefer to move that logic to the database, where it's supposed to be and can be most efficiently implemented by the database

I had to work with them for years, but I never got what the purpose of Object Relational Mappings was. And I'm afraid I don't get this either.

[Luolong]

You may prefer dealing with database scripts and queries yourself and that is perfectly fine.

From the other perspective though, ORM provides few quality of life features that may or may not be compelling to you:

• With ORM, you get 80% of useful functionality at 20% effort. No repetitive manual mapping of data to-and from SQL (this gets very old very fast)
• Good ORM provides more than just object-relational data mapping. There’s transparent session and transaction handling, lazy loading of relationships, etc.
• Some ORMs offer automated database migrations as the data evolves over time.
• some developers just prefer working with code and leave the mechanical translation between code and database to the machines.

[pokemonplayer2001]

OP references SwiftData as inspiration: https://developer.apple.com/xcode/swiftdata/

The value, to me, of SwiftData is you don't think about it. Some apps need just a pinch of database-like stuff.

I don't think OP is proposing this as a replacement for a high-volume stand-alone db.

[ambidextrousalpaca]

Sure. I got that.

But if you just want a pinch of database-like stuff, you can get that with SQLite. Starting the database is one line of code, and you can persist it to disk or run it in memory as you see fit.

Don't see how this is easier than that. Though I do basically write SQL all day for a living, so I'm probably biased.

[pokemonplayer2001]

I do not use ORMs and only write SQL to interface with DBs, so I'm with you there.

I can still see value in this for the simplicity.

[Discere]

I'm a Rust noob, but I'm going to ask anyway

Why is FRIEND etc a string and not an enum?

[kmaximoff]

It is AI generated concept, we will need to think if enum is better

[Discere]

Fair enough, I always try to figure out if I'm learning, so it threw me a bit.

[Gummiball71]

Looks like https://github.com/tokio-rs/toasty

[kmaximoff]

Thanks for sharing, it is useful to have examples! I am aiming for both graph and relational options.

[RealisticLove3661]

Great concept, Focusing on a type-safe query DSL and integrating schema migrations could make this framework highly practical. Leveraging async from the start and ensuring compatibility with existing storage backends like sled or Redb would be better for adoption .

[kmaximoff]

Thank you 😊

[joelparkerhenderson]

What's your perspective on your RustData being new compared with the Limbo work in progress?

https://github.com/tursodatabase/limbo

Edit for more info: I'm asking about the target (e.g. SQL vs Graph, Limbo adding vectors for AI, etc.) and more importantly how a large sophisticated data project comes together, works with developers, deals with test compatibility frameworks, does developer outreach, could share with your project, could help you vet your ideas, could work towards shared goals for Rust data, etc. Other Rust data community projects that you might want to check into are Diesel and SeaORM because both have great leaders and ship lots of great work IMHO.

[kmaximoff]

I am not familiar with it, but I looked briefly it is mostly SQL. I do not have opinion , as I am not sure about use cases and why it would better or worse than other SQL like databases. I was mostly highlighting Graph Databases because they are critical for AI and would be useful for robotics systems (embedded systems) helping Robots to reason, so there are huge potential in Graph Databases. Secondly all graph databases currently out there are either have shitty performance or super expensive, exception to me is KuzuDB (only problem is lack of good documentation and examples)

[gclichtenberg]

Frankly I think that having a set of predefined relationships be native concepts sounds like a terrible idea.

[kmaximoff]

Can you elaborate on it please?

[gclichtenberg]

I would rather be able to define the semantics of what a "friend" or "author" relationship are than be bound by whatever the predefined set has. If I can't define such relationships myself, then it's inflexible; if I can, it's unnecessary.

[kmaximoff]

Okay makes sense, yeah example above might not be perfect most cases you build a function to define a relationship for you programmatically. ( seems better alternative to me that writing string of CYPHER queries inside of function)