PostGIS Tiger Geocoder gets version 2025.2 and leaves PostGIS core

The PostGIS development team announced version 2025.2 of the postgis_tiger_geocoder extension, published on Planet PostgreSQL. More than a bug-fix release, it confirms an important structural change: the extension is leaving the PostGIS core and moving to its own release lifecycle. According to the note, this is the second release since the split from the PostGIS core.

What is Tiger Geocoder and why it matters

postgis_tiger_geocoder is an extension written entirely in PL/pgSQL that turns PostgreSQL, with PostGIS installed, into a geocoding service. It works on top of TIGER/Line data (the U.S. Census Bureau's geographic database) loaded into the database, allowing addresses to be converted into coordinates and vice versa within a SQL query, without depending on an external API.

The advantage for whoever manages the data is obvious: geocoding happens in the same place where the spatial data already lives, under the same integrity, backup, and access-control rules as the database. There is no traffic of sensitive addresses to third-party services, nor cost per request. For an application that needs to geocode large volumes in batch, solving this with an indexed SQL function tends to be more predictable than orchestrating HTTP calls.

It's worth noting a scope caveat that the versioning model itself makes clear: Tiger Geocoder operates on the United States TIGER database. Versioning follows precisely the year of the Census dataset current as of the release date, hence the 2025.2 naming. For Brazilian addresses it doesn't work directly; the interest here is architectural and methodological, or for Brazilian companies that need to geocode US-based data.

The split from PostGIS core

The most relevant point in this announcement is organizational. The note formalizes two practical consequences:

• The PostGIS 3.6 series is the last one to include postgis_tiger_geocoder.
• PostGIS 3.7 will ship without the extension.

From now on, the code has a dedicated repository on OSGeo's Gitea, inside the PostGIS organization. Anyone depending on the geocoder needs to incorporate this new source into their installation and update process, instead of simply relying on what comes bundled with the PostGIS package.

From a governance standpoint, the decision makes sense. Tiger Geocoder is tied to a dataset that changes every year and has a narrower audience compared to the PostGIS universe as a whole. Decoupling its release cycle from the core prevents the spatial database's schedule from being held hostage to Census updates, and allows faster delivery to those who actually use the tool. The other side of the trade-off is that the extension is no longer a guaranteed component of the stack: it now requires explicit dependency management.

Requirements and installation

Version 2025.2 requires PostgreSQL 16 or higher and should work with any supported version of PostGIS. Since the extension is pure PL/pgSQL, there are no binaries to compile: if no toolchain is available, the distribution offers pre-built files prefixed postgis_tiger_geocoder-pg, which just need to be copied into the share/extension directory of the installation.

For those upgrading from a previous version, the standard path is:

ALTER EXTENSION postgis_tiger_geocoder UPDATE;

If the command fails with the error extension "postgis_tiger_geocoder" has no update path from version "x" to version "2025.2", or if the source is a development version, the note recommends forcing the update path:

ALTER EXTENSION postgis_tiger_geocoder UPDATE TO "ANY";
ALTER EXTENSION postgis_tiger_geocoder UPDATE;

This kind of detail deserves the attention of any DBA managing databases with the extension in production: the upgrade path is not always linear, and having the update plan tested in a staging environment before touching production remains the prudent approach.

Fixes in this release

The 2025.2 changelog is lean and focused on build and packaging infrastructure, which is consistent with an extension that just gained autonomy and is still stabilizing its own pipeline:

• GT-35, install target fix (Devrim Gündüz);
• GT-38, parallel builds fix (Paul Ramsey);
• GT-40, schema qualification in extension dependencies (Regina Obe).

The GT-40 fix is the most interesting from a robustness standpoint: schema-qualifying dependencies prevents object resolution from depending on the current search_path, a classic source of unexpected behavior and even security risks in multi-schema environments. It's the kind of hygiene that separates an amateur extension from one ready for production.

What to do from here

For those already using Tiger Geocoder, the message is clear: start treating it as an externally managed dependency, not something that comes bundled for free with PostGIS. That means following the dedicated repository, documenting the origin of the extension files in your provisioning process, and planning the migration before reaching PostGIS 3.7.

For those evaluating adopting the tool, it remains a solid option for in-database geocoding, with the caveat already mentioned that the dataset is American. In scenarios involving Brazilian databases, the value lies more in the architecture (geocoding inside PostgreSQL, under the database's transactional guarantees) than in the dataset itself, which would need to be replaced with equivalent national sources.