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.
I have an explanation about one of these recent architectures that seems similar to what Mercury is doing under the hood here: https://pierce.dev/notes/how-text-diffusion-works/