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

61–70 of 91 posts

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

#61

Post by mr_Fatalyst »

never_inline wrote: post #51

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 t…

1. We're all AI agents in a simulation anyway...

2. A converter still means maintaining two model systems. The point was to not have two in the first place.

3. MessagePack overhead is negligible compared to actual DB round-trips. And the Rust core isn't just SQL generation, it bundles the full driver stack (sqlx), pooling, and streaming, so you don't need asyncpg/aiosqlite as separate dependencies.

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

#62

Post by mr_Fatalyst »

unconscionable wrote: post #44

This is great. Are there any live sites running it in production? Django + async is a nightmare so this is a very welcome project.

Thanks! Not yet, it's still v0.5 and the API hasn't fully stabilized. But it's getting there.

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

#64

Post by mr_Fatalyst »

fhub wrote: post #36
TZubiri wrote: post #11

Didn't the committee agree that ORMs were a mistale and a thing of the past?

Where ORMs are clearly weak is in generating suboptimal queries and making it too easy to create N+1 issues. My first introduction to ORMs was Ruby on Rails. You would rely on New Relic to identify performance issues and then fix them. With solid AGENTS.md / CLAUDE.md, I do not think this would happen as much anymore in new code. So then it is just a matter of style preference (ORM vs whatever else).

That's exactly why Oxyde has no lazy loading at all. If you don't call .join() or .prefetch(), related data simply won't be there. N+1 is impossible by design, not by discipline.

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

#65

Post by ljm »

waterTanuki wrote: post #17

We need more creative names for rust packages because this is going to cause confusion There's already Oxide computers https://oxide.computer/ and Oxc the JS linter/formatter https://oxc.rs/ .

Ruby was forward thinking enough to give libraries bizarre pet names that had no obvious connection to their functionality.

Pundit, Capybara, Bullet, Grape, Faraday...

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

#67

Post by murkt »

mr_Fatalyst wrote: post #56
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.

When it’s a simple single-line query: sure.

When they’re 30 lines apart, because it’s a function that builds a complex query with joins and filters based on some function arguments: not easy.

I don’t really understand how .pyi will give me proper Find usages here. I haven’t used them a lot, though, and just rely on pycharm Find Usages or just rg.

Also, what about foreign keys? Let’s say it’s a filter on user__email__startswith. Are you able to find it when executing Find Usages on User.email field?

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

#68

Post by [deleted] »

whinvik wrote: post #22
roel_v wrote: post #8

Why would one want to couple these two? Doesn't that couple, say, your API interface with your database schema? Whereas in reality these are separate concepts, even if, yes, sometimes you return a 'user' from an API that looks the same as the 'user' in the database? Honest question, I only just recently got into FastAPI and I was a bit confused at first that yes, it seemed like a lot of duplication, but after a littl…

Yeah I have always struggled to figure out why I would use SQLModel. Big fan of FastAPI but I think SQLModel leads to the wrong mental model that somehow db model and api schema are the same. Therefore I insist on using SQLAlchemy for db models and pydantic for api schemas as a mental boundary.

[deleted]

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

#69

Post by outlines »

This is pretty similar to what django-ninja offers as well with their Schema modeling [1]. I found it to be a big help personally and always wanted something for fastapi.

Django-ninja is essentially the fastapi of the django world so this library would be enough for me to go all in on fastapi. I just never felt like I found a python orm with the level of ergonomics of django + async of modern python

[1] https://django-ninja.dev/guides/response/django-pydantic/

Post reply on HN