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

31–40 of 91 posts

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

#31

Post by Onavo »

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…

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.

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

#32

Post by mr_Fatalyst »

kevinqi wrote: post #28

I think Prisma does type-safe ORM really well on the typescript side, and was sad it doesn't seem to be super supported in python. This feels sort of similar and makes a lot of sense!

Thanks! Haven't used Prisma much myself, but glad the approach resonates.

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

#33

Post by mr_Fatalyst »

TZubiri wrote: post #29
mr_Fatalyst wrote: post #14

Earlier quoted context omitted.

Must have missed that meeting. ORMs are not for everything, but for CRUD-heavy apps with validation they save a lot of boilerplate. And there's always execute_raw() for when you need to go off-script.

If there's an Open Source application that you can show me as a good example of ORM usage, I'd be interested in seeing it as a steelman argument for them.

For Oxyde specifically, it's still a young project, so the best public examples I have are the FastAPI tutorial (https://github.com/mr-fatalyst/fastapi-oxyde-example) and the admin panel examples (https://github.com/mr-fatalyst/oxyde-admin). Bigger real-world showcases will come with time. But in general, ORMs pay for themselves when you have lots of models, relations, and standard CRUD with validation. The moment you hand-write the same INSERT/UPDATE/SELECT with joins for every endpoint, it adds up fast.

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

#34

Post by mr_Fatalyst »

Onavo wrote: post #31
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…

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.

Exactly, that's the idea.

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

#35

Post by bognition »

luckycharms810 wrote: post #30

As a non ORM person - I do love the Pydantic functionality that comes out of the box w pyscopg3. https://www.psycopg.org/psycopg3/docs/advanced/typing.html#e...

Oh this is super cool. Coming from Java I've long missed JDBI and Rosetta which makes writing SQL Queries in Java a dream. I've toyed around with a similar style interface for python, and looking at this give me hope I can achieve it.

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

#36

Post by fhub »

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).

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

#37

Post by ElectricalUnion »

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…

I also find it really strange this weird ORM fascination. Besides the generic "ORM are the Vietnam War of CS" feeling, I feel that with average database to ORM/REST things, end up with at least one of:

a) you somehow actually have a "system of record", so modelling something in a very CRUD way makes sense, but, on the other hand, who the hell ends up building so many system of record systems in the first place to need those kinds of tools and frameworks?

b) you pretend your system is somehow a system of record when it isn't and modelling everything as CRUD makes it a uniform ball of mud. I don't understand what is so important that you can uniformly "CRUD" a bunch of objects? The three most important parts of an API, making it easy to use it right, hard to use it wrong, and easy to figure out the intent behind how your system is meant to be used, are lost that way.

c) you leak your API to your database, or your database to your API, compromising both, so both sucks.

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

#38

Post by gavmor »

Onavo wrote: post #31
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…

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.

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

#39

Post by unrealhoang »

mr_Fatalyst wrote: post #3
throwawayffffas wrote: post #2

Lol I never knew django orm is faster than SQLAlchemy. But having used both that makes sense. > Why Rust? ... Rust handles the database plumbing. Queries are built as an IR in Python, serialized via MessagePack, sent to Rust which generates dialect-specific SQL, executes it, and streams results back. Speed is a side effect of this split, not the goal. Nice. So what does it take to deploy this, dependency wise?

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?

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

#40

Post by bb88 »

ElectricalUnion wrote: post #37
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…

I also find it really strange this weird ORM fascination. Besides the generic "ORM are the Vietnam War of CS" feeling, I feel that with average database to ORM/REST things, end up with at least one of: a) you somehow actually have a "system of record", so modelling something in a very CRUD way makes sense, but, on the other hand, who the hell ends up building so many system of record systems in the first place to nee…

The vietnam of computer science was written 20 years ago (2006 even), and didn't kill off ORMs then. We've only had 20 years of improvement of ORMs since then. We've long ago accepted Vietnam (the country) as what it is and what it will be in the forseeable future. We should do the same with ORM.

I for one don't want to write in a low level assembly language, and shouldn't have to in 2026. Yet, SQL still feels like one.

I've written a lot of one off products using an ORM, and I don't regret any of the time savings from doing so. When and if I make $5-50M a year on a shipped product, okay, maybe I'll think about optimizing. And then I'll hire an expert while I galavant around europe.

Post reply on HN