{"slug": "sqlalchemy", "name": "SQLAlchemy", "category": "dev-libs", "category_name": "Libraries and frameworks", "description": "", "recommenders": 3, "commenters": 6, "warners": 3, "score": 0.151, "rising": 0.35, "first": "2025-12-22", "latest": "2026-10-25", "why": "I am 100% sure what SQL do I want it to produce and what SQL will a particular ORM invocation produce.", "why_is_quote": true, "has_verdict": false, "sentiment": {"recommend": 3, "neutral": 0, "compare": 0, "warn": 3}, "spark": [0, 0, 0, 0, 0, 1, 0, 0, 1, 0, 0, 1], "listed": true, "loved": [], "caveat": "", "short_quote": "I am 100% sure what SQL do I want it to produce and what SQL will a particular ORM invocation produce.", "icon": true, "domain": null, "github_repo": null, "official_url": "https://www.sqlalchemy.org", "pricing": "", "aliases": ["SQLAlchemy"], "verdict": null, "praise": [{"label": "", "summary": "", "quotes": [{"id": 803714561, "item_id": 50232160, "url": "https://news.ycombinator.com/item?id=50232160", "by": "munro", "date": "2026-10-25", "stance": "recommend", "quote": "SQLAlchemy has an eDSL of SQL, so you can skip the whole ORM/table mapping layer, and just use it to programmatically construct SQL syntax", "excerpt": "IDK lot of noise in report, I need more signal to noise ratio, already reading so much AI output as it is. But the example PR... It said code generate with Claude, is it really still this bad? Last I was using SQLAlchemy with Claude was Opus 4.5, and it took some heavy coaching and skill gen not to generate code like this--but why even use SQLAlchemy at all if you're just going to use string interpolation jeez https:", "context": "", "use_case": "programmatically constructing SQL", "switched_from": "", "story": "Show HN: Farol \u2013 A risk map of a pull request for the person who approves it"}, {"id": 780602896, "item_id": 48787681, "url": "https://news.ycombinator.com/item?id=48787681", "by": "vova_hn2", "date": "2026-07-04", "stance": "recommend", "quote": "I am 100% sure what SQL do I want it to produce and what SQL will a particular ORM invocation produce.", "excerpt": "I don't like the title, it implies that the only reason for using an ORM is not knowing SQL, which is obviously not the case. Every time I tried to do a project without an ORM, using only raw SQL, I inevitably ran into: - serialization/deserialization boilerplate. Like, having to manually map values returned by the DB library to object (or named tuple, or structure) properties - poor code reuse, having multiple very ", "context": "", "use_case": "ORM for database access", "switched_from": "", "story": "What ORMs have taught me: just learn SQL (2014)"}, {"id": 764007170, "item_id": 47750448, "url": "https://news.ycombinator.com/item?id=47750448", "by": "hk__2", "date": "2026-04-13", "stance": "recommend", "quote": "one Python app (FastAPI/SQLAlchemy) for the backend that exposes a REST API", "excerpt": "Not a big thing, but I\u2019m happy to work again on a side project I started last year and abandoned because of some limitations from the stack I chose. It\u2019s https://napodico.it, a very simple online Neapolitan dictionary. Nothing extraordinary here but it\u2019s something that will tremendously help me organize my notes on Neapolitan words and expressions that are currently scattered across Google docs. I\u2019ve built https://ww", "context": "", "use_case": "ORM", "switched_from": "Drizzle", "story": "Ask HN: What Are You Working On? (April 2026)"}]}], "caveats": [{"label": "", "summary": "", "quotes": [{"id": 800794816, "item_id": 50049676, "url": "https://news.ycombinator.com/item?id=50049676", "by": "listenallyall", "date": "2026-10-12", "stance": "warn", "quote": "of all the pain points, SQLAlchemy was the worst of them.", "excerpt": "Yea, I used the psycho-pg (yes I know thats not the right spelling) often. But that is postgres-specific. Tried other alternatives too. I'm sure it is better now, but those 2 were the dominant approaches back then. Obviously I had other issues with the Python language and ecosystem, but of all the pain points, SQLAlchemy was the worst of them.", "context": "", "use_case": "Python database access", "switched_from": "", "story": "SQLAlchemy 2.1.0 Released"}, {"id": 750809712, "item_id": 46925607, "url": "https://news.ycombinator.com/item?id=46925607", "by": "woeirua", "date": "2026-02-07", "stance": "warn", "quote": "Every time I use them I think to myself it would be easier to just write SQL myself", "excerpt": "I use coding agents almost exclusively now and I\u2019m going to say yes and no on this one. Yes, I think there\u2019s the potential to replace some frameworks that abstract away too many details and make things way too complicated for basic apps. A good example of this are ORMs like SqlAlchemy. Every time I use them I think to myself it would be easier to just write SQL myself, but it would be a tremendous amount of boilerpla", "context": "uses coding agents almost exclusively", "use_case": "ORM", "switched_from": "", "story": "Software Engineering Is Back"}, {"id": 741733426, "item_id": 46358339, "url": "https://news.ycombinator.com/item?id=46358339", "by": "petcat", "date": "2025-12-22", "stance": "warn", "quote": "But at this point I've sworn-off using query-builders and ORMs.", "excerpt": "I've loved and used Django ORM and SQLAlchemy for many years. It got me a long way in my career. But at this point I've sworn-off using query-builders and ORMs. I just write real, hand-crafted SQL now. These \"any db\" abstractions just make for the worst query patterns. They're easy and map nicely to your application language, but they're really terrible unless you want to put in the effort to meta-program SQL using w", "context": "", "use_case": "database access", "switched_from": "", "story": "The Rise of SQL:the second programming language everyone needs to know"}]}], "who": [], "tags": [], "use_cases": ["orm", "programmatically constructing sql", "python database access", "orm for database access", "database access"], "compared": [{"slug": "drizzle", "name": "Drizzle", "co": 1, "switched_from": 1, "switched_to": 0}, {"slug": "claude", "name": "Claude", "co": 2, "switched_from": 0, "switched_to": 0}], "makers": [{"id": 739691680, "item_id": 46230730, "url": "https://news.ycombinator.com/item?id=46230730", "by": "zzzeek", "date": "2025-12-11", "stance": "recommend", "quote": "I use it ubiquitously.", "excerpt": "SQLAlchemy has its own frozendict which we've had in use for many years, we have it as a pretty well performing cython implementation these days, and I use it ubiquitously. Would be a very welcome addition to the stdlib. This proposal is important enough that I chimed in on the thread with a detailed example of how SQLAlchemy uses this pattern: https://discuss.python.org/t/pep-814-add-frozendict-built-in-type/104854/", "context": "", "use_case": "frozendict implementation in ORM", "switched_from": "", "story": "A \u201cfrozen\u201d dictionary for Python"}], "threads": [{"url": "https://news.ycombinator.com/item?id=50231349", "title": "Show HN: Farol \u2013 A risk map of a pull request for the person who approves it", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=50043030", "title": "SQLAlchemy 2.1.0 Released", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=48742175", "title": "What ORMs have taught me: just learn SQL (2014)", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=47741527", "title": "Ask HN: What Are You Working On? (April 2026)", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=46923543", "title": "Software Engineering Is Back", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=46312755", "title": "The Rise of SQL:the second programming language everyone needs to know", "mentions": 1}], "sentiment_by_month": {"2025-11": {}, "2025-12": {"warn": 1}, "2026-01": {}, "2026-02": {"warn": 1}, "2026-03": {}, "2026-04": {"recommend": 1}, "2026-05": {}, "2026-06": {}, "2026-07": {"recommend": 1}, "2026-08": {}, "2026-09": {}, "2026-10": {"warn": 1, "recommend": 1}}, "quotes": [{"id": 803714561, "item_id": 50232160, "url": "https://news.ycombinator.com/item?id=50232160", "by": "munro", "date": "2026-10-25", "stance": "recommend", "quote": "SQLAlchemy has an eDSL of SQL, so you can skip the whole ORM/table mapping layer, and just use it to programmatically construct SQL syntax", "excerpt": "IDK lot of noise in report, I need more signal to noise ratio, already reading so much AI output as it is. But the example PR... It said code generate with Claude, is it really still this bad? Last I was using SQLAlchemy with Claude was Opus 4.5, and it took some heavy coaching and skill gen not to generate code like this--but why even use SQLAlchemy at all if you're just going to use string interpolation jeez https:", "context": "", "use_case": "programmatically constructing SQL", "switched_from": "", "story": "Show HN: Farol \u2013 A risk map of a pull request for the person who approves it"}, {"id": 800794816, "item_id": 50049676, "url": "https://news.ycombinator.com/item?id=50049676", "by": "listenallyall", "date": "2026-10-12", "stance": "warn", "quote": "of all the pain points, SQLAlchemy was the worst of them.", "excerpt": "Yea, I used the psycho-pg (yes I know thats not the right spelling) often. But that is postgres-specific. Tried other alternatives too. I'm sure it is better now, but those 2 were the dominant approaches back then. Obviously I had other issues with the Python language and ecosystem, but of all the pain points, SQLAlchemy was the worst of them.", "context": "", "use_case": "Python database access", "switched_from": "", "story": "SQLAlchemy 2.1.0 Released"}, {"id": 780602896, "item_id": 48787681, "url": "https://news.ycombinator.com/item?id=48787681", "by": "vova_hn2", "date": "2026-07-04", "stance": "recommend", "quote": "I am 100% sure what SQL do I want it to produce and what SQL will a particular ORM invocation produce.", "excerpt": "I don't like the title, it implies that the only reason for using an ORM is not knowing SQL, which is obviously not the case. Every time I tried to do a project without an ORM, using only raw SQL, I inevitably ran into: - serialization/deserialization boilerplate. Like, having to manually map values returned by the DB library to object (or named tuple, or structure) properties - poor code reuse, having multiple very ", "context": "", "use_case": "ORM for database access", "switched_from": "", "story": "What ORMs have taught me: just learn SQL (2014)"}, {"id": 764007170, "item_id": 47750448, "url": "https://news.ycombinator.com/item?id=47750448", "by": "hk__2", "date": "2026-04-13", "stance": "recommend", "quote": "one Python app (FastAPI/SQLAlchemy) for the backend that exposes a REST API", "excerpt": "Not a big thing, but I\u2019m happy to work again on a side project I started last year and abandoned because of some limitations from the stack I chose. It\u2019s https://napodico.it, a very simple online Neapolitan dictionary. Nothing extraordinary here but it\u2019s something that will tremendously help me organize my notes on Neapolitan words and expressions that are currently scattered across Google docs. I\u2019ve built https://ww", "context": "", "use_case": "ORM", "switched_from": "Drizzle", "story": "Ask HN: What Are You Working On? (April 2026)"}, {"id": 750809712, "item_id": 46925607, "url": "https://news.ycombinator.com/item?id=46925607", "by": "woeirua", "date": "2026-02-07", "stance": "warn", "quote": "Every time I use them I think to myself it would be easier to just write SQL myself", "excerpt": "I use coding agents almost exclusively now and I\u2019m going to say yes and no on this one. Yes, I think there\u2019s the potential to replace some frameworks that abstract away too many details and make things way too complicated for basic apps. A good example of this are ORMs like SqlAlchemy. Every time I use them I think to myself it would be easier to just write SQL myself, but it would be a tremendous amount of boilerpla", "context": "uses coding agents almost exclusively", "use_case": "ORM", "switched_from": "", "story": "Software Engineering Is Back"}, {"id": 741733426, "item_id": 46358339, "url": "https://news.ycombinator.com/item?id=46358339", "by": "petcat", "date": "2025-12-22", "stance": "warn", "quote": "But at this point I've sworn-off using query-builders and ORMs.", "excerpt": "I've loved and used Django ORM and SQLAlchemy for many years. It got me a long way in my career. But at this point I've sworn-off using query-builders and ORMs. I just write real, hand-crafted SQL now. These \"any db\" abstractions just make for the worst query patterns. They're easy and map nicely to your application language, but they're really terrible unless you want to put in the effort to meta-program SQL using w", "context": "", "use_case": "database access", "switched_from": "", "story": "The Rise of SQL:the second programming language everyone needs to know"}]}