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

Re:Show HN: Oxyde – Pydantic-native async ORM with a Rust core by gavmor on Monday March 16, 2026 @09:29PM (#47407482)

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.

[ Parent | on HN ]

Re:Show HN: Oxyde – Pydantic-native async ORM with a Rust core by ramon156 on Tuesday March 17, 2026 @03:12AM (#47409551)

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

[ Parent | on HN ]

Re:Show HN: Oxyde – Pydantic-native async ORM with a Rust core by gavmor on Tuesday March 17, 2026 @04:32PM (#47417904)

Well yeah, of course. Sorry, when I said "DB" what I should have said was "data-layer," and this can include: repositories, ORM models, query-builders, etc. All of these are type-hinted "db domain in-code" and, still, not one coupled to your API.

[ Parent | on HN ]