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

SQLAlchemy 2.0 eliminates the autocommit parameter from both Session and Connection, replacing implicit transaction behavior with explicit begin() and commit() calls. For codebases upgrading from 1.4, this creates a compatibility boundary where legacy ORM queries that previously persisted changes automatically now require deliberate transaction management. The shift also changes Session.execute() to return a Result object rather than a list, altering how row data is consumed.

The goal is to identify the minimal refactoring boundary for a legacy application that mixes 1.x-style Query objects with 2.0-style select() statements without introducing behavioral regressions. Uncertainty remains around whether implicit transactions still occur in certain 1.4 compatibility modes under 2.0, and how the Result return type interacts with existing code that expects list-like access patterns. It is also unclear which documented patterns apply when a Session operates outside a web request context where transaction boundaries are not naturally scoped.

What is the documented behavior for Session.execute() when no explicit begin() block is active in SQLAlchemy 2.0? How should legacy code that relied on autocommit=True be restructured to preserve atomicity without wrapping every statement in manual transaction blocks? Are there compatibility shims or configuration settings in 2.0 that allow a gradual migration for mixed Query and select() usage?