Ormar or SQLModels?

[maitham]

Hey Folks, I'm starting a new project, should I be using this library or SQLModels? What are the pros/cons of both?
The main concerns are, Ormar uses encode/databases underneath while SQL Models uses SQL Alchemy which has been around for a while but async SQL alchemy is a bit less mature, I personally also don't like how heavy SQL Alchemy is, but I recognise that pretty much all edge cases are covered. How mature is the Ormar project?

[igormorgado]

I have read, somewhere in forums or documentation (can't recall) that Ormar is moving out from databases to use SQLAlchemy only, since databases seems abandoned.

But @collerek is a person better suited to answer that.

About maturity: At least in my use cases, seems its pretty stable, there is a few small bugs (nothing prohibitive), I even found one myself. @collerek seems a nice person and reply in here in discussion when he can.

I'm pretty happy with ormar, haven't put it under stress yet, but using typing, pydantic under the hood is a very good feature to me, don't know if SQLModels does that. If don't I really recommend keep with ormar.

There is also TortoiseORM. I have tried. But documentation is kind of lacking, community isn't good, also, I prefer Ormar syntax.

Also Ormar has a nice name that fits beautifully with Python object alias import ormar as orm seems a nice feature.

In portuguese Ormar looks like a person name, it's a kind of funny, at least to me.

My 2c.

[michaeltoohig]

I'm starting to use Ormar after I had the very same question. I went with Ormar after looking through SQLModel docs and online discussions and thought it seemed less mature at the moment. For example, I thought the way they used Pydantic validators to give functionality akin to SQLAlchemy computed properties felt like a kludge. Ormar is also supported by many FastAPI related packages such as FastAPI-CRUDRouter, FastAPI-Pagination, FastAPI-Users, etc. Personally, I also found the syntax of Ormar more appealing since SQLModel syntax is a complete mash-up of Pydantic and SQLAlchemy and it shows in the model definitions whereas Ormar models felt better to me coming from a SQLAlchemy background.

Since using FastAPI I've tried using plain old SQLAlchemy 1.3 to encode/databases to now Ormar and always have some level of frustration it seems. As for pros SQLModel does have a section in their docs for splitting models across multiple files here https://sqlmodel.tiangolo.com/tutorial/code-structure/ where I am facing this issue with Ormar now here #445 although I am probably doing something wrong.

EDIT:

You may also want to keep an eye on this discussion #451 to me it's just another issue I've run into in the two nights I've been working with Ormar. If both of my issues above are not solvable I may go back to using encode/databases on its own or look for something else. I thought using an ORM may be nice to try and simplify some of my verbose SQL code but now I'm not so sure.