[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?

[kstrauser]

> Lol I never knew django orm is faster than SQLAlchemy.

I don’t believe that for a second. Both are wonderful projects, but raw performance was never one of Django ORM’s selling points.

I think its real advantage is making it easy to model new projects and make efficient CRUD calls on those tables. Alchemy’s strong point is “here’s an existing database; let users who grok DB theory query it as efficiently and ergonomically as possible.”

[mr_Fatalyst]

I was surprised too when I saw the results. The benchmarks test standard ORM usage patterns, not the full power of any ORM. SQLAlchemy is more flexible, but that flexibility comes with some overhead. That said, the ORM layer is rarely the bottleneck when working with a database. The benchmarks were more about making sure that all the Pydantic validation I added comes for free, not about winning a speed race.

[mr_Fatalyst]

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.

[unrealhoang]

a bit tangent question: the communication between Python & Rust, could the pyo3 ser/de of Python objects be better than MsgPack?

[mr_Fatalyst]

Good question. Working with Python objects in PyO3 requires holding the GIL. With MessagePack, Python serializes to bytes, hands them off, and Rust works completely GIL-free from that point. Same on the way back. So the GIL is held only for the brief serde step, not during SQL generation or execution.

[zbentley]

I’m curious: why was this marked dead?