Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Oxyde – Pydantic-native async ORM with a Rust core

github.com

Post reply on HN
Print view View original

51–60 of 91 posts

Re: Show HN: Oxyde – Pydantic-native async ORM with a Rust core

#51

Post by never_inline »

1. AI Slop Post

2. """You define Pydantic models for your API, then define separate ORM models for your database, then write converters between them.""" So you could've written something that let you convert between two. That would not warrant a whole new ORM.

3. """But infrastructure stuff like SQL generation, connection pooling, and row serialization is where a systems language makes sense."""

This makes no sense to me (except row serialization - maybe, but you're incurring a messagepack overhead instead). Unnecessary native dependency.

Re: Show HN: Oxyde – Pydantic-native async ORM with a Rust core

#53

Post by ramon156 »

gavmor wrote: post #38
Onavo wrote: post #31

Earlier quoted context omitted.

With this you don't need to have two sources of truth on the backend. Previously you will end up with one set of DB ORM level validation and a second set of validation on the data transfer object and you have to make sure the types line up. Now the data transfer object will automatically inherit the correct types.

The two sources of truth are for two disparate adapters. Neither the API nor the DB define the domain, but both must adapt the domain to their respective implementation concerns. The ontology of your persistence layer should be entirely uncoupled from that of your API, which must accommodate an external client. In theory, anyway.

I'd rather define my db domain in-code so I do not have to worry about writing the queries without type hinting.

Raw sql -> eh, I don't have the patience Raw sql w type hints -> better, I at least get a compilation error when I do something wrong, and preferably a suggestion ORM -> this usually introduces it's own abstraction that needs it's own maintenance, but at least it's more code-oriented.

Yes, SQL is an awesome solution to querying DB's, hence I prefer option 2

Re: Show HN: Oxyde – Pydantic-native async ORM with a Rust core

#54

Post by [deleted] »

instig007 wrote: post #10

> But infrastructure stuff like SQL generation, connection pooling, and row serialization is where a systems language makes sense. not really, what makes sense is being JIT-able and friendly to PyPy. > Type safety was a big motivation. > https://oxyde.fatalyst.dev/latest/guide/expressions/#basic-u... > F("views") + 1 If your typed query sub-language can't avoid stringly references to the field names already defined b…

[deleted]

Re: Show HN: Oxyde – Pydantic-native async ORM with a Rust core

#55

Post by murkt »

Seeing a new library in 2026 that uses Django-style filter syntax is really surprising.

With SQLAlchemy approach I can easily find all usages of a particular column everywhere.

    .filter(Folder.user_id == user_id)
Versus

    .filter(user_id=user_id)
Grepping by user_id will obviously produce hundreds and thousands of matches, probably from dozens of tables.

Re: Show HN: Oxyde – Pydantic-native async ORM with a Rust core

#56

Post by mr_Fatalyst »

murkt wrote: post #55

Seeing a new library in 2026 that uses Django-style filter syntax is really surprising. With SQLAlchemy approach I can easily find all usages of a particular column everywhere. .filter(Folder.user_id == user_id) Versus .filter(user_id=user_id) Grepping by user_id will obviously produce hundreds and thousands of matches, probably from dozens of tables.

You can't call filter() without a model. It's always Folder.objects.filter(user_id=user_id), so the context is right there in the code. Plus the generated .pyi stubs give your IDE full type info per model, so "go to usages" works through the type system.

Re: Show HN: Oxyde – Pydantic-native async ORM with a Rust core

#57

Post by mr_Fatalyst »

unrealhoang wrote: post #39
mr_Fatalyst wrote: post #3

Earlier quoted context omitted.

Just pip install oxyde, that's it. The Rust core (oxyde-core) ships as pre-built wheels for Linux, macOS, and Windows, so no Rust toolchain needed. Python-side dependencies are just pydantic, msgpack, and typer for the CLI. Database drivers are bundled in the Rust core (uses sqlx under the hood), so you don't need to install asyncpg/aiosqlite/etc separately either.

a bit tangent question: the communication between Python & Rust, could the pyo3 ser/de of Python objects be better than MsgPack?

Good question. Working with Python objects in PyO3 requires holding the GIL. With MessagePack, Python serializes to bytes, hands them off, and Rust works completely GIL-free from that point. Same on the way back. So the GIL is held only for the brief serde step, not during SQL generation or execution.

Re: Show HN: Oxyde – Pydantic-native async ORM with a Rust core

#58

Post by mr_Fatalyst »

JSR_FDED wrote: post #49

This is great, you’ve taken the pieces of Django I’m most envious of (the amazing ORM and Admin panel), and made them available separately. Timing couldn’t be better just as I’m starting to use Quart in earnest.

Thanks! The admin panel supports Quart out of the box, so you should be good to go.

Re: Show HN: Oxyde – Pydantic-native async ORM with a Rust core

#59

Post by mr_Fatalyst »

fishgoesblub wrote: post #46

Is it possible to initialise a fresh database without manually running commands to run migrations? I'm not seeing anything in the docs to do so.

Right now it's CLI-based: 'oxyde migrate'. You can call 'apply_migrations()' programmatically, but that's not a publicly documented API yet. Good point though, worth adding.

Re: Show HN: Oxyde – Pydantic-native async ORM with a Rust core

#60

Post by mr_Fatalyst »

ryan14975 wrote: post #45

The coupling concern is valid but I think it's the right trade-off for most CRUD apps. In practice, 80% of your endpoints are thin wrappers around your models anyway. The remaining 20% where you need separate request/response schemas — you just write those by hand. The auto-generated admin panel is a nice touch. That alone saves days on internal tooling.

Well said, that's pretty much how I see it too. Thanks!
Post reply on HN