--- title: "Why I Keep Reaching for SQLAlchemy" url: https://daily.dev/posts/why-i-keep-reaching-for-sqlalchemy-mqcgfdq9w source_url: https://spin.atomicobject.com/keep-reaching-sqlalchemy type: article source: "Atomic Spin" published: 2026-08-19T12:09:02.560Z updated: 2026-08-19T12:17:08.976Z tags: ["python", "sql"] reading_time: 2 upvotes: 0 comments: 0 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Why I Keep Reaching for SQLAlchemy **[Atomic Spin](https://daily.dev/sources/atomicobject)** · 2 min read · 0 upvotes · 0 comments ## Summary A developer reflects on why SQLAlchemy earns its place beyond simply avoiding raw SQL: its real value is the unit-of-work pattern for coordinating multi-step database writes within a single transaction. An example endpoint updating a document status, creating signing sessions, writing outbox messages, and recording an audit event illustrates how these changes must succeed or fail together. The piece also notes SQLAlchemy's downsides—lazy relationships causing hidden N+1 queries, unexpected auto-flushing, and the continued need to understand SQL, joins, and query plans for performance-sensitive work. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why would I use SQLAlchemy instead of just writing raw SQL for transactions? SQLAlchemy's main value isn't avoiding SQL but coordinating multiple writes as a single unit of work. When one operation touches several tables, like updating a document status, creating signing sessions, writing outbox messages, and recording an audit event, SQLAlchemy lets all those changes share one session and transaction so a failure anywhere rolls everything back together. _Weighing ORMs versus raw SQL for transactional code is easier with real-world takes like this on daily.dev._ ### What are the downsides of using SQLAlchemy in production? Lazy relationships can silently trigger dozens of extra queries, and automatic flushing can occur earlier than expected, both of which are easy to miss without integration tests since mocked sessions hide these behaviors. It's also not ideal for everything; reporting endpoints and performance-sensitive queries are often clearer written as explicit SQL rather than through the ORM. _Developers debugging ORM query behavior can find practical gotchas like these on daily.dev._ ## Similar posts on daily.dev - [The revenge of SQL: How a 50-year-old language reinvents itself](https://daily.dev/posts/the-revenge-of-sql-how-a-50-year-old-language-reinvents-itself-ptgmonz65) · InfoWorld · 1 upvotes · 0 comments - [QCon SF: Database-Backed Workflow Orchestration Challenges Traditional Architecture](https://daily.dev/posts/qcon-sf-database-backed-workflow-orchestration-challenges-traditional-architecture-slmsieila) · InfoQ · 1 upvotes · 0 comments --- Tags: [#python](https://daily.dev/tags/python), [#sql](https://daily.dev/tags/sql) [View this post on daily.dev](https://daily.dev/posts/why-i-keep-reaching-for-sqlalchemy-mqcgfdq9w)