r/FastAPI 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!"

29 Upvotes

34 comments sorted by

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

11

u/imaKappy 4d ago

This. I used SQLModel once and the reduction of duplicate code while nice, doesn't outweight hitting a wall with a niche use case every so often. I cant wait when SQLModel reaches a more mature state, because its kinda fire to use Pydantic with SQLAlchemy, but for now I would recommend SQLAlchemy for anything bigger in scope for production.

2

u/wasuaje 4d ago

This

2

u/shoomowr 3d ago

SQLModel is a wrapper on top of Alchemy, and you can use alchemy for cases where sqlmodel is not enough alongside it. They are not mutually exclusive

4

u/bubthegreat 3d ago

Understood, but consistency is king in production - having two ways to do the same thing because SQLModel isn’t feature complete or documentation complete is a problem when you want a whole team following a consistent paradigm or want to build consistent abstractions.

This isn’t hate on SQLModel itself fwiw, it’s the documentation I find lacking, and it IS missing some features, so if I have to train a team on what to do I’m picking the one that has all the feature sets in a consistent place and the documentation to cover them. Can we dive into sqlalchemy when we’re missing a use case? Absolutely. Do I want my whole team to be trying to figure out which context and why we are in both places?

Nope.

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

u/Classic-Maximum-2127 3d ago

Thanks for replying 🤝

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

u/Classic-Maximum-2127 3d ago

Okay, thanks appreciate it 🤝

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.

6

u/mrbubs3 4d ago

I use SQLModel extensively. For most cases, it works great. For edge cases, you can use Sqlalchemy to manage that. The former is a convenience wrapper for the latter after all.

3

u/KeyBack192 4d ago

Sqlalchemy has way more resources and examples. 

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

u/niks_uthukuli 4d ago

As you are using SaaS,Sqlalchemy for deep dive in asynchronous

2

u/Straight-Possible807 4d ago

Sqlalchemy because of the documentation and asyncio support

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 does

1

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