Add support for spatial / geometry types in DBAL

[ddegasperi]

Hi Doctrine team,

I’d like to propose adding support for spatial / geometry column types in DBAL (e.g., geometry, point, linestring, polygon, etc.).

These types are supported in several database platforms (e.g., MySQL, PostgreSQL with PostGIS, SQLite with SpatiaLite), and having native support for them in DBAL would improve schema introspection, migrations, and type mapping consistency.

I understand this could be complex due to platform differences, but even basic support would already be a step forward for many use cases.

If this is something the project is open to accepting, I would be happy to work on a pull request to contribute the feature, starting with one platform (e.g., PostgreSQL/PostGIS) and iterating from there.

Would love to hear your thoughts!

Best regards,
Daniel

[derrabus]

Yes, this would be interesting. But.

A type that is only supported by a single platform is not what we want to maintain in this repository. You won't build a good abstraction with only one platform in mind. You can release such a type as your own package though.

[ddegasperi]

Just to elaborate a bit: the OGC Simple Features Specification defines a standard set of spatial types like:

• POINT, LINESTRING, POLYGON
• MULTI* variants
• GEOMETRYCOLLECTION

These are consistently supported across multiple RDBMSs, including:

• PostGIS (PostgreSQL extension)
• MySQL (8.0+)
• SpatiaLite (≥5.0)

All of these systems also support defining an SRID per geometry column, which is critical for spatial correctness (e.g., spatial indexing, coordinate systems, etc.).

I completely understand that DBAL core doesn’t want to maintain types that aren’t portable across platforms. However, there is a meaningful cross-platform subset of spatial types and shared concepts (like SRID) that could serve as a basis for a reusable abstraction.

Therefore I believe my contribution would be a viable abstraction also for other RDBMSs, but of course I might introduce a bias towards PostgreSQL as there lies my expertise. We might use the PR as a basis for discussion with experts on other engines.

[derrabus]

there is a meaningful cross-platform subset of spatial types and shared concepts (like SRID) that could serve as a basis for a reusable abstraction.

Indeed there is. And if you were to contribute a type that operates on this cross-platform subset, I'm more than happy to review the PR and maintain the code afterwards. But I completely understand that a solution that lives on Postgres island only is everything you personally need and that's fine. But that's not what we are looking for.

[seb-jean]

Laravel created a PR on this issue a year ago. I hope this helps: laravel/framework#49634

[ddegasperi]

@derrabus I’ve created a first implementation and pushed it to a branch in my fork of doctrine/dbal.

Would it be helpful if I opened a draft PR to gather some early feedback on whether the overall direction makes sense, or would you prefer that I keep the reference here for now?

In the meantime, I’ll also review the code references provided by @seb-jean to see how the implementation is handled across different platforms.

[derrabus]

Yes, please open a draft PR if you want to gather feedback.

[maxhelias]

For implementations specific to Postgres + PostGIS, there are:

• https://github.com/jsor/doctrine-postgis
• https://github.com/martin-georgiev/postgresql-for-doctrine

[tibobaldwin]

Indeed, there are these two GitHub repositories. I find that a direct integration into Doctrine is interesting. This will allow for less dependency if needed and offer integration for other platforms.

[ddegasperi]

I’m aware of the existing community projects providing spatial extensions and appreciate the work behind them. My intention isn’t to replace or diminish their value.

My initial motivation came from the missing DBAL 4 support in doctrine-postgis (which was only recently added). While exploring alternatives, I noticed that DBAL itself is evolving significantly — for example, with upcoming changes in Column and ColumnEditor — which make it harder to add metadata like geometry type and SRID externally. That’s why I proposed integrating spatial types directly into DBAL to ensure consistent and maintainable support across platforms.

These community packages will still have their place, especially for advanced spatial functions or platform-specific features, while this work focuses on providing a solid type foundation.

The PR already includes working implementations for PostgreSQL/PostGIS and MySQL/MariaDB — I’d really appreciate any feedback on the approach or design.