- Can I use jsor/doctrine-postgis with Laravel Eloquent?
- No. The package registers PostGIS geometry and geography column types with Doctrine DBAL and exposes spatial functions to Doctrine's query layer, so it provides no benefit to a pure Eloquent application because Eloquent bypasses DBAL type mapping entirely. The realistic adoption paths are a Laravel app already using laravel-doctrine, a Doctrine-based service co-hosted with a Laravel front end, or a module where Doctrine DBAL is deliberately introduced for spatial work. If you just need to store a latitude and longitude and run a proximity search, an Eloquent-native PostGIS package or parameterized raw SQL is the lighter baseline to evaluate first.
- How do I install and register jsor/doctrine-postgis in a Laravel project?
- Install it with Composer, then register the PostGIS geometry and geography DBAL types and add mapping_types entries so the PostGIS column names resolve to those types. Confirm the PDO pgsql driver is in use and that the target database actually has the PostGIS extension enabled. If you are running laravel-doctrine, this registration happens in your Doctrine configuration rather than in Eloquent's connection config.
- Which Laravel and PHP versions does it support?
- The package itself is thin, so the version question really belongs to its transitive chain. The most likely thing to break on an upgrade is whether laravel-doctrine (or your equivalent Doctrine bridge) supports your current Laravel and PHP versions. Confirm that bridge and the Doctrine DBAL release matrix align before committing, and check the package's release notes for the supported DBAL range.
- What is the difference between the geometry and geography column types?
- Geometry is planar and geography operates on the sphere or ellipsoid, so the same coordinates can produce different distances, index behavior, and function results depending on which you choose. Picking the wrong one is a correctness bug that shows up as wrong distances or bad search results rather than an exception. Decide the convention per column, document it, and stay consistent across the schema.
- Which spatial functions does it expose to Doctrine queries?
- It maps PostGIS functions such as distance, containment, and intersection into Doctrine's SQL and DQL layers so you can use spatial predicates inside your query builder instead of hand-writing raw SQL. The exact registered function set is documented in the README and should be checked against the operations you need. Anything not registered can still be expressed as raw SQL where necessary.
- How do I create spatial columns and GiST indexes in migrations?
- Doctrine's schema tool and Laravel's migration system are two sources of truth, so designate one as authoritative before you add spatial columns. GiST indexes frequently need explicit, hand-written DDL because neither tool generates them correctly by default, so plan to add CREATE INDEX ... USING GIST statements yourself. Keep those index migrations versioned alongside the column definitions.
- How do I avoid SRID mismatches and invalid geometry bugs?
- SRID mismatches, geometry-versus-geography confusion, and invalid geometries often fail quietly or return wrong distances instead of throwing, which surfaces in production as incorrect search results. Pick a single SRID convention, enforce it in column definitions and inserts, and validate geometries at write time. Add tests with known real-world distances so a regression in spatial semantics fails your suite.
- What are the alternatives to jsor/doctrine-postgis for Laravel?
- For an Eloquent application, an Eloquent-native PostGIS package or parameterized raw SQL using PostGIS functions is usually the lighter answer and should be the baseline you compare against. If you already run Doctrine, this package is a narrow, well-scoped fit that avoids reimplementing type mapping. A dedicated spatial service is another option when spatial analytics is a large, separate concern.
- Is jsor/doctrine-postgis production ready and how does it perform?
- It is MIT-licensed, actively maintained with a recent 2025 release, and has a small but contained footprint, so the main risk is the single primary maintainer rather than code complexity. Performance is dominated by your GiST indexes and query patterns, not by the package: point-in-polygon at scale behaves very differently from nearest-neighbor lookups, so benchmark with realistic row counts. Expect low effort for a proof of concept and moderate effort for production hardening around indexes and SRID conventions.
- What is the exit cost if we need to drop jsor/doctrine-postgis later?
- Low, because the package is thin and fully replaceable with raw SQL against standard PostGIS. Confine spatial work to one bounded context and one repository so swapping the query layer does not touch the rest of the application, and keep the underlying PostGIS schema portable. That containment is the main mitigating factor against maintainer and dependency risk.