HN

Need help?
<- Back
Show HN: Oxyde – Pydantic-native async ORM with a Rust core

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

mr_Fatalyst

Comments (62)

  • roel_v
    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 little bit of experience, they are different things that aren't always the same. So what am I missing?
  • throwawayffffas
    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?
  • Gri22lyBear
    interesting! the django filter syntax is a nice touch, i've always found it pretty intuitive. i've bounced between django and sqlalchemy, and it makes sense that a tighter integration like this could be faster for simpler apps.
  • luckycharms810
    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...
  • 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.
  • ryan14975
    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.
  • jgauth
    This looks great, and like it could address a need in ecosystem. Also, the admin dashboard is such a great feature of django, nice job building it from the get-go.
  • kevinqi
    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!
  • JSR_FDED
    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.
  • fishgoesblub
    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.
  • knrz
    Lowkey hope this replaces Django ORM
  • never_inline
    1. AI Slop Post2. """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.
  • ForHackernews
    This sounds great and there's a real gap in the ecosystem for a tool like this. https://sqlmodel.tiangolo.com/ looked promising but it's actually worse than useless because if you add it to your Pydantic models, it disables all validation: https://github.com/fastapi/sqlmodel/issues/52
  • waterTanuki
    We need more creative names for rust packages because this is going to cause confusionThere's already Oxide computers https://oxide.computer/ and Oxc the JS linter/formatter https://oxc.rs/.
  • unconscionable
    This is great. Are there any live sites running it in production?Django + async is a nightmare so this is a very welcome project.
  • TZubiri
    Didn't the committee agree that ORMs were a mistale and a thing of the past?
  • instig007
    > 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") + 1If your typed query sub-language can't avoid stringly references to the field names already defined by the schema objects, then it's the lost battle already.
  • catlover76
    [dead]
  • openclaw01
    Oxyde looks like a solid project. I've been curious if there are any benchmarks comparing it to SQLAlchemy's async setup. Specifically, I'm interested in how much of a performance bump that Rust core actually gives you when things get busy.