// the find
geoalchemy/geoalchemy2
Geospatial extension to SQLAlchemy
GeoAlchemy2 bolts spatial types and functions (geometry/geography columns, ST_ functions, spatial indexes) onto SQLAlchemy so you can work with PostGIS, SpatiaLite, MySQL/MariaDB spatial extensions, MSSQL, and GeoPackage through the ORM instead of raw SQL. It's for anyone who's already committed to SQLAlchemy and needs geospatial columns without hand-writing WKT/WKB conversions everywhere.
Real per-dialect implementations (postgresql, mysql, mariadb, mssql, sqlite, geopackage each have their own module under types/dialects and admin/dialects) rather than a Postgres-only tool with an afterthought abstraction layer. Ships type stubs (functions.pyi, py.typed) so autocomplete and mypy actually work. Test infrastructure is unusually serious for a project this size — dockerized test containers spin up real Postgres, MySQL, MariaDB, MSSQL and CockroachDB instances, plus dedicated benchmark tests comparing query plans, not just unit tests against mocks.
The README is essentially a stub — one paragraph plus badges, with everything punted to Read the Docs, so you can't tell from the repo itself what basic usage looks like or how mature each dialect's function coverage is. PostGIS is clearly the reference dialect; MSSQL and MariaDB support tends to lag behind in real-world usage of libraries like this, and nothing in the repo layout signals which functions are actually implemented per-backend versus stubbed. No visible async engine support, which matters if you're on SQLAlchemy 2.0's async ORM. Being a thin layer over SQLAlchemy also means it's exposed to SQLAlchemy's own major-version breakage — worth checking the supported SQLAlchemy version range before pinning.