Doctrine Postgis Laravel Package

Product Decisions This Supports

• Feature feasibility: this package is the unblocker for location-aware features. It makes PostGIS geometry/geography columns first-class, typed entity fields instead of opaque blobs, which is what lets you say "yes, we can ship a store locator" with confidence.
• Concrete roadmap candidates it enables:
  • "Near me" / radius search and distance sorting
  • Delivery zones, service areas, geofencing and territory assignment
  • Store/dealer/asset locators with map rendering
  • Route and logistics planning, pickup-point selection
  • Real-estate, travel, marketplace and field-service listing maps
  • Coverage/heatmap analytics on user or order locations
• Build vs. buy: strong "borrow" case. Re-implementing Doctrine DBAL types for PostGIS EWKB, SRID handling, and geometry/geography round-tripping is roughly 1–3 engineer-weeks plus an ongoing tax of spatial edge cases. This is MIT-licensed, dependency-light, and released as recently as October 2025.
• Platform commitment: adopting it is effectively a decision to standardize on PostgreSQL + PostGIS. That is the real product decision — everything else is a tactical add-on.
• Data modeling: it steers you toward geo attributes as typed, indexed columns (GiST) rather than JSON strings, which materially affects query performance and future feature options for "near me" and polygon containment.
• Sequencing: it tells you whether geo lands in v1 or v2. If PostGIS is already in the stack, geo features get cheap; if it isn't, the cost is infrastructure, not this library.
• Vendor and maintenance exposure: 221 stars and a single-maintainer profile is a real, if modest, line item — pin the version and plan a fallback.

When to Consider This Package

Adopt when:

1. Your PHP stack uses Doctrine ORM — Symfony applications, or Laravel running laravel-doctrine/orm rather than Eloquent.
2. PostgreSQL + PostGIS is already, or will become, your primary datastore.
3. You need to persist and hydrate Point, LineString, Polygon, Multi* values as typed PHP objects with SRID awareness.
4. You want spatial predicates (ST_DWithin, ST_Contains, distance ranking) to run against columns that are correctly typed and indexable.
5. A permissive license and no runtime service matter — MIT, no external API, no per-query cost.
6. You want to keep the geo layer thin rather than add a heavyweight GIS platform.

Look elsewhere when:

• You are Eloquent-first. This is the most common false positive. Most Laravel teams should use clickbar/laravel-postgis or build on raw PostGIS expressions; this package will not integrate with Eloquent models.
• You are on MySQL/MariaDB spatial types — use a MySQL-oriented spatial package.
• You need a spatial query DSL. This is a type-mapping layer, not a query builder. If the roadmap depends on a rich library of DQL spatial functions, count on writing and maintaining those yourself.
• You need PostGIS raster, topology, or pgRouting — explicitly out of scope.
• No Doctrine and no appetite for it. Adding Doctrine to a Laravel codebase to get geo types is almost certainly the wrong trade.
• You cannot own PostGIS operations: GiST indexes and ANALYZE behavior, SRID and coordinate-system conventions, geometry-column migrations, and backup/restore of spatial data. These are org capabilities, not library features.

Risk notes before committing: pin the version, add round-trip tests for geometry serialization and SRID handling, and confirm migration tooling writes geometry/geography columns correctly. Keep a documented ~2–3 week exit path to in-house DBAL types.

How to Pitch It (Stakeholders)

To executives: this is a small, MIT-licensed, actively released library that lets our application store and query location data natively in PostgreSQL. It is the difference between shipping location features in days-to-weeks versus a custom geospatial build. There is no license cost, no external vendor, and little lock-in — worst case, replacing it is a couple of engineer-weeks. It is a tactical dependency, not a strategic bet; the strategic decision is standardizing on PostgreSQL with PostGIS, which is also what buys us location search, delivery zones, and store locators on the roadmap.

To engineering: it is a thin DBAL/ORM type layer for PostGIS — geometry and geography columns mapped to PHP objects with SRID handling, integrated with Doctrine metadata and migrations. No runtime service, no external calls, no meaningful performance overhead. Two caveats to plan for explicitly: (1) it maps types, it does not give you a DQL spatial-function library, so distance and containment queries will be hand-written SQL/DQL; (2) PostGIS operations are ours to own — GiST indexes, SRID conventions, and spatial migrations need an owner. Adoption is low (221 stars, single maintainer), so pin the version and cover geometry round-tripping with tests.

The ask: approve the PostgreSQL + PostGIS platform direction and this library as the Doctrine integration layer. The alternative — hand-rolling spatial DBAL types or adding Doctrine to an Eloquent-only codebase — costs more than it saves.