I can't see the difference between the first two "VS" examples you have above, it just looks like they are formatted differently (oh, one has annotations and th

I can't see the difference between the first two "VS" examples you have above, it just looks like they are formatted differently (oh, one has annotations and the other doesn't. you'd use the annotated version. I guess you are cut-and-pasting from a migration guide that's for legacy code. "migration guide" means "I have legacy code". if you don't have legacy code, you have nothing to migrate. Go straight to https://docs.sqlalchemy.org/en/20/orm/quickstart.html https://docs.sqlalchemy.org/en/20/orm/quickstart.html ). The second example is a Core table. The new tutorial makes it clear that this is an underlying element that nonetheless you have to sometimes create directly. the third example is gone. That style is not in the docs anymore *except* in a clearly marked side-box that is talking about a legacy version of SQLAlhcemy - you don't have to read that and the box IMO makes it as clear as it can that this is not the current way of doing things. > Why so many styles? Why can't be like pydantic or Django and use just one style for ORM? pydantic is extremely new and SQLAlchemy's declarative style pre-dates Python 3 entirely. So we have changed it. The old ways of doing things have to be maintained for backwards compatibility with millions of existing applications. You can't be around for 16 years and have exactly one way of doing things that never changes, legacy patterns for large software libraries are a fact of life. as for django I dont know what they are doing, I am sure things had to change for them to accommodate pep-484 typing in models (if they have even done that).