Show HN: Iceaxe – A modern, fast ORM for Python and Postgres

[icyfox]

https://github.com/piercefreeman/iceaxe

Hey HN,

I've been writing webapps in Python for 6 years and have been using SQLAlchemy as my ORM for about that same time. As I've recently scaled more products with this stack a few things occurred to me:

- It takes really careful session management to avoid idle-in-transaction hanging in the database because objects are still floating around (see: PEP 249 and its prioritization “implicit begin” and “explicit commit”)

- Not once have we switched backend databases, we've always stuck with Postgres

While it was baking hot in San Francisco a few weekends ago I took a step back to write a ground-up Postgres ORM with modern syntax. It main focuses are typehinted schemas, async support, integrated database migrations, and explicit transaction management. You can certainly do all this with existing solutions but my hope is by making them first class primitives it's easier to write correct and performant database code.

Give it a try - would love to hear what you think!

(More documentation is also at https://mountaineer.sh/iceaxe/guides/quickstart)

[odie5533]

How does Iceaxe compare to SQLModel?

[icyfox → odie5533]

Definitely some similarities!

SQLModel is also based on Pydantic, so the schema definitions that you'll write will look very similar to Iceaxe. Internally however SQLModel is implemented as a wrapper over SQLAlchemy. This is beneficial for support of multiple different database backends (mysql+postgres+sqlite) and for its battle tested track record. But as a drawback it also inherits a lot of the SQLAlchemy baggage like async+sync incompatibility and some funkiness with passing through types.

Since Iceaxe just targets Postgres, it can simplify a lot of those assumptions. It's implemented as async-only, leverages the most recent additions to typehinting in Python 3.12, and bakes in migration support. Documentation can capture explicit best practices for targeting Postgres versus attempting to abstract across every database backend.

It's also a bit different philosophically. It encourages explicit sql when you need to write complex queries; we support programatic joins out-of-the-box, but for more complex SQL (common table expressions for one) I find an ORM can often overly abstract what your engine is actually doing and hide subtle bugs that make their way into production.

I've spent quite some time with SQLModel as part of my Mountaineer web framework. It's great - just targets a broader range of ORM goals. Philosophically I'm trying to keep Iceaxe lean, fast, and Postgres optimized.