SQLAlchemy 2.0 removes Session autocommit parameter, forcing explicit transaction boundaries in legacy code

What Session.execute() does without an explicit begin()

In 2.0 the Session no longer accepts an autocommit flag. The documented behavior is:

• SELECT‑only statements run outside a transaction; the database sees a read‑only query.
• DML (INSERT/UPDATE/DELETE) automatically starts a transaction on first execution. That transaction remains open until the session is closed or you explicitly commit() or rollback().

Thus a DML operation is not committed after each statement – it is part of a single transaction that spans all subsequent DML calls until you end it.

How to refactor legacy autocommit=True code

Replace the old pattern where every statement was immediately committed with a single logical boundary:

# SQLAlchemy 1.x style
session = Session(autocommit=True)
session.execute(stmt1)  # committed immediately
session.execute(stmt2)  # committed immediately

With 2.0 you should group related operations inside a with session.begin(): block. This keeps the code readable and preserves atomicity:

# SQLAlchemy 2.0 style
session = Session()
with session.begin():
    session.execute(stmt1)
    session.execute(stmt2)  # both statements are part of the same transaction
# transaction is committed automatically when the block exits cleanly

If you have long‑running scripts or background jobs, open a new session for each logical batch and close it at the end. Avoid keeping a single session alive for the entire run.

Result handling changes

Prior to 2.0 Session.execute() returned a list. In 2.0 it returns a Result object. Replace list‑style access with the appropriate Result methods:

• result.all() – materialises all rows.
• result.first() – fetches the first row.
• result.scalars().all() – returns a list of scalar values.

Example:

result = session.execute(select(User).where(User.id == 1))
user = result.first()  # instead of result[0]

Gradual migration for mixed Query/select() codebases

1. Enable deprecation warnings – run your test suite with python -W default::DeprecationWarning to surface remaining session.query() usage.
2. Replace session.query() incrementally – keep both APIs in the same file during the transition; they coexist in 2.0.
3. Introduce explicit transaction boundaries – wrap each logical group of DML operations in with session.begin(): blocks. This is the only way to mimic the old autocommit behaviour without per‑statement commits.
4. Update Result consumption – change any list‑like access to the Result API shown above.
5. Test in a staging environment – verify that data is persisted exactly as before and that no accidental rollbacks occur.

There is no compatibility shim that restores autocommit=True in 2.0. The migration path is purely code‑based and incremental.

What to ask next

If your legacy code performs a mix of SELECT and DML in the same logical operation, do you already have a clear boundary that can be wrapped in a with session.begin(): block, or do you need to identify those boundaries first?