Fly Labs
Ask FlyBot

Oxyde – Pydantic-native async ORM with a Rust core

Hi HN! I built Oxyde because I was tired of duplicating my models.If you use FastAPI, you know the drill. You define Pydantic models for your API, then define separate ORM models for your database, then write converters between them. SQLModel tries to fix this but it's still SQLAlchemy underneath. Tortoise gives you a nice Django-style API but its own model system. Django ORM is great but welded to the framework.I wanted something simple: your Pydantic model IS your database model. One class, full validation on input and output, native type hints, zero duplication. The query API is Django-style (.objects.filter(), .exclude(), Q/F expressions) because I think it's one of the best designs out there.Explicit over implicit. I tried to remove all the magic. Queries don't touch the database until you call a terminal method like .all(), .get(), or .first(). If you don't explicitly call .join() or .prefetch(), related data won't be loaded. No lazy loading, no surprise N+1 queries behind your back. You see exactly what hits the database by reading the code.Type safety was a big motivation. Python's weak spot is runtime surprises, so Oxyde tackles this on three levels: (1) when you run makemigrations, it also generates .pyi stub files with fully typed queries, so your IDE knows that filter(age__gte=...) takes an int, that create() accepts exactly the fields your model has, and that .all() returns list[User] not list[Any]; (2) Pydantic validates data going into the database; (3) Pydantic validates data coming back out via model_validate(). You get autocompletion, red squiggles on typos, and runtime guarantees, all from the same model definition.Why Rust? Not for speed as a goal. I don't do "language X is better" debates. Each one is good at what it was made for. Python is hard to beat for expressing business logic. But infrastructure stuff like SQL generation, connection pooling, and row serialization is where a systems languag

Hacker NewsToolDevSource
0Sign in to voteCopy link

FL score

69

out of 100

Verdict

VALIDATE

high confidence

Competition

11

competitors found, emerging market, funded players

Trend

No signal yet

A Pydantic-native async ORM with a Rust core, targeting FastAPI developers to eliminate model duplication and boost performance, faces high build complexity in a crowded market.

The pain

FastAPI developers currently suffer from model duplication (Pydantic for API, separate ORM models), complex converters, performance overheads, and surprise N+1 queries with existing async ORMs. This leads to wasted development time, increased bug surface, and slower applications.

The gap

While many ORMs exist, none combine true Pydantic-nativeness (one model definition for API and DB) with a performance-oriented Rust core, explicit query loading (preventing N+1), and a Django-style API. Existing solutions like SQLModel are still SQLAlchemy-based, and others lack strong documentation or full Pydantic integration, creating a specific whitespace for developers prioritizing type safety, performance, and simplicity.

Build angle

Focus on being the absolute simplest, most performant Pydantic-native async ORM for FastAPI + Postgres users, with a clear migration path and superior developer experience by eliminating boilerplate and N+1 queries 'by design'.

Strengths

  • Addresses a deeply felt, specific pain for FastAPI/async Python developers (model duplication, N+1 queries, performance).
  • Strong technical differentiation with a Rust core and Pydantic-native design.
  • Clear value proposition: simplicity, type safety, performance, explicit behavior.
  • The async Python/FastAPI ecosystem is growing, providing a receptive audience.

Risks

  • Extremely high build and maintenance complexity for a solo builder (ORM + Rust core).
  • Highly crowded market with strong, established (SQLAlchemy) and funded (Prisma) competitors.
  • Difficult monetization as an open-source project in a free-tool-heavy ecosystem.
  • High switching costs for developers already invested in other ORMs.
  • Potential for being perceived as 'yet another ORM' without significant, proven advantages.

Next steps

  1. Conduct in-depth interviews with FastAPI developers currently using SQLModel, Tortoise, or SQLAlchemy to deeply understand specific breaking points and willingness to pay for a solution.
  2. Focus on building a small, hyper-performant, and perfectly Pydantic-native core for a single common use case (e.g., simple CRUD for two related models) and get real users to try it.
  3. Explore potential monetization models (e.g., enterprise features, managed services, support, commercial licenses) and validate demand for these before significant further investment.
  4. Build a strong developer community around the project to help with maintenance and contributions, as solo effort is unsustainable for a project of this scope.

Questions about this idea?

FlyBot reads the scoring and gives you a second opinion on “Oxyde – Pydantic-native async ORM with a Rust core”.

Open FlyBot