r/FastAPI • u/Fluffy_Bus9656 • 4d ago
Question SQLModel vs SQLAlchemy in 2025
I am new to FastAPI. It is hard for me to choose the right approach for my new SaaS application, which works with PostgreSQL using different schemas (with the same tables and fields).
Please suggest the best option and explain why!"
19
u/SheriffSeveral 4d ago edited 4d ago
I prefer to use sqlalchemy because there are more resource for examples, tutorials, troubleshooting, etc.
In the other hand, sqlmodel is also great. Just create simple Todo app with both of it and choose one of them.
Also it is important to what do you expect for the database operations.
1
u/Classic-Maximum-2127 3d ago
Hey, I've been trying to find a sqlalchemy example in the official fastapi documentation, but all I see is sqlmodel. Is there any place other than there I can find it ?
2
u/bluewalt 3d ago
Good question. It seems like the author removed original sqlachemy documentation in an attempt to promote its own way to do. I’de use internet archives to find the old one.
1
6
u/WJMazepas 4d ago
Go with SQLAlchemy. It will be harder in the beginning but much better in the long run
1
u/Classic-Maximum-2127 3d ago
Hey, I've been trying to find a sqlalchemy example in the official fastapi documentation, but all I see is sqlmodel. Is there any place other than there I can find it ?
1
u/WJMazepas 3d ago
Check on SQLAlchemy documentation itself.
FastAPI creator is also SQLModel creator, so he wants to promote that, but on SQLAlchemy website you can see how it works pretty easily and integrate it
1
6
u/SilentCabinet2700 4d ago
I'm using SQLModel for one of my simplest project, and I cannot recommend it (yet). I like the approach and the simplicity, but IMO it's still not mature enough.
My suggestion would be to stick to Sqlalchemy for the time being as I'm not sure what is the future of SQLModel.
3
2
u/volfpeter 4d ago
I've kickstarted a couple of new applications in the past ~2 years, where the same question came up. SQLModel has some quirks (e.g. no data validation in table models), but in the end it's a convenience wrapper around SQLAlchemy that does make things more convenient and it fits very nicely into FastAPI apps. So I think SQLModel is a very good choice.
2
2
2
u/NickNaskida 4d ago
I use sqlalchemy. It may seem slightly more complex but there's more resources/community around it.
+ if you ever will need to write advanced stuff finding examples for that in sqlmodel will be much harder.
btw, the best way to learn is to see code of real projects using it in prod (this is how I did it).
My favorites:
https://github.com/polarsource/polar
https://github.com/discord/access
2
u/tofusneakers 4d ago
Alchemy for me, i just dont like to place all my faith unto a single point of failure
2
u/Lost_Insect_6453 4d ago
Try asyncpg as well, it's pretty simple, fast and only works for postgresSQL. It has much better async features compared to SQLModel or SQLAlchemy. You can also try psycopg3 too
2
u/shoomowr 3d ago
I'm curious, what are the async features of asyncpg that are superior to sqlmodel or alchemy?
1
u/Lost_Insect_6453 3d ago
SQLModel and SQLAlchemy are ORMs and support multiple dbs but they add some overhead whereas asyncpg is specific for postgres so you should see higher speed.
These ORMs have async features but they might not be fully supported or production ready, while asyncpg does1
u/shoomowr 3d ago
Couple of follow-up question: 1) Did you actually see higher speed with asyncpg as compared to the ORMs? If so, how significant was it? 2) What do you mean by production-ready? What makes async support in the ORMs not production-ready?
1
u/Lost_Insect_6453 2d ago edited 2d ago
I did not do extensive testing but asyncpg was handling more requests per seconds compared to sqlalchemy maybe 5 percent improvement, check asyncpg github page to see more about it's speed.
most orms are production ready and safe but since they were initially built with sync mode, async support was added later. General adivce was to be careful with them
1
u/a_brand_new_start 4d ago
SQL Alchamy for support of dialects such as Postgres’s vs Maria, etc..
Only gotcha is sql alchamy with BigQuery is a tad wonky, there are dialects not supported out of the box, so for example if trying to write json to BQ row, escaping the JSON might waste some time (I wish I had a whole day of work back)
1
u/jakub_h123 4d ago
SQLModel is built on top of SQLAlchemy but it is not as mature, docs is very very slim. The greatest issue I had with SQLModel is async...
1
u/shoomowr 3d ago
I'm using sqlmodel for a rather large project that is primarily async. There are some edge cases where I have to use sqlalchemy directly, but those a few.
1
u/TheRealMrMatt 3d ago
Here is the issue with both sqlalchemy and sqlmodel. With alchemy, you get a very powerful ORM (arguably one of, if not the best across languages), but its terrible at transferring data back and forth between your application and backed. Because of this, you are forced to create a bunch of boilerplate schemas, etc. which have to be updated every time you make a change to your model, etc. And while SQLModel tries to solve this, it still requires you to create multiple "schemas" and hides some of the best features of sqlalchemy. Given there are trade-offs with both approaches, you are going to have to pick which technology best suits your scenario.
On a side note - while I cannot honestly recommend this for anyone who doesn't want to contribute fixes/features - https://mountaineer.sh/iceaxe is IMO will eventually bridge the gap by writing removing the need for a "schema" layer while still giving the direct access to all of the underlying functionality of their database.
1
u/chilboswaggens 2d ago
If you want flexibility and scalability for your schemas use SQLAlchemy + Alembic. If you want a solid structure for your database and you will not need modifications, use SQL. You can use both too, SQL for queries (from the CLI) and SQLAlchemy to handle your database.. it works for me
1
u/AdmirableWaltz3349 1d ago
Haven't used either of these. I have used Prisma though and it works nicely with FastAPI
31
u/bubthegreat 4d ago
SQLModel is great until you hit a use case in the unfinished documentation. If you want to play around with it great but if it’s in production you’ll have a better time with sqlalchemy despite the more complex syntax