Reduced risk for SQL injection: SQLInjection is considerably more difficult in SQLAlchemy as compared with using raw sql, and the interface implicitly discourages use of it. Only when using raw SQL does the risk increase.
Reduced need to understand SQL -- useful especially for developers less familiar with SQL. This enables backend develops to work more consistently within the environment of Python.
Database-agnostic: Outside of raw SQL queries such as the above, SQLAlchemy can function with different SQL dialects, from SQLite, PostgreSQL, and Oracle. Thus, if we want to change databases, this can be done with minimal changes to our code.
This enables us to represent tables and views in Python classes, which enhances the in-repository documentation -- rather than having to switch between the database and the python code to see how tables are represented, we can have in-repository models which express the tables and their relationship with each other and which can be more easily viewed from an IDE.
Representing SQL in SQLAlchemy can reduce the amount of code, especially for simpler, more repetitive queries. It does this by abstracting boilerplate code and enabling leaner python syntax in replacement of wordier SQL syntax. That can make maintenace easier
Strong community support with a lot of documentation.
Why not use SQLAlchemy?
Overhead for learning SQLAlchemy logic: SQLAlchemy can be thought of as a kind of transitional interface between Python and SQL, which will itself have to be learned.
Models represented in code will need to be updated as their corresponding tables are updated. There are some workarounds for this, such as Alembic, which are worth considering later on, but which I have little experience.
Performance overhead: SQLAlchemy offers an additional layer of abstraction, which means that queries can be slower, especially in the case of more complex queries
Implicit behavior: SQLAlchemy, by its nature, hides the SQL queries being executed. These queries can be viewed for debugging purposes, but generally speaking, using SQLAlchemy requires a degree of trust that it's executing the intended functions.
My thoughts
SQLAlchemy's advantages outweigh its downsides, and SQLAlchemy is widely used for precisely that reason. It reduces language switching, reduces security risks through SQLInjection, enhances self-documentation, and generally reduces the total number of lines of code. If we were working in an environment where performance to the tune of milliseconds count, it'd be a different story. Since we don't, the performance overhead is acceptable and well-compensated by how it will make things easier for developers.
Converting from raw SQL to SQLAlchemy will take time, but can be piecemeal, gradually replacing components with SQLAlchemy.
SQLAlchemy is an Object-Relational Mapping (ORM) tool that represents SQL database actions in Python code.
Why use SQLAlchemy?
Why not use SQLAlchemy?
My thoughts
Resources: