When teams add PostGIS to their PostgreSQL estate
PostGIS is the extension that adds spatial support to PostgreSQL, giving the database geometry and geography types, spatial functions and spatial indexes. For a team that already runs self-hosted PostgreSQL and now needs to store, index and query location data, the work is mostly about versions, indexes and upgrades. Installing the extension files and creating the extension in a database takes little time by comparison. The harder questions come later: which PostGIS release matches the PostgreSQL major version in use, how spatial indexes will behave as tables grow, and how the extension will move through each future PostgreSQL upgrade without becoming the reason a cluster cannot be upgraded on schedule.
Teams usually add PostGIS for one of three reasons. The first is a new product feature that depends on location, such as finding nearby records, drawing service areas or checking whether a point falls inside a boundary. The second is an imported geographic dataset, such as administrative boundaries, postal areas or asset coordinates from a GIS export, that must be stored and queried alongside existing tables. The third is regional reporting, where totals, rates or exceptions are grouped by geographic area. Each reason places different demands on the database, so the first decision is which one drives the project. That choice sets the expected data volume, the query patterns and the index design.
PostGIS runs inside the PostgreSQL server, so the supported PostgreSQL major version, the server's upgrade path and its backup and replication setup all apply to spatial data as well. The PostgreSQL versioning policy lists major versions 14 through 18 as supported, with 14 scheduled to end on November 12, 2026. A team on an older major version will need to plan a PostgreSQL upgrade and a PostGIS upgrade together. Before choosing a PostGIS release, confirm with the PostGIS project which release supports your target PostgreSQL major version, because that compatibility information determines the order in which the work must happen.
Before scoping the work, run three checks. First, record the current PostgreSQL major version and any PostGIS version already installed on each cluster, since teams often find the extension in a database that nobody has documented. Second, list the tables and queries that will use spatial types, and note whether any existing code depends on older geometry functions or behavior. Third, ask which team owns extension upgrades, because the extension is released and patched on a different schedule than the server. These answers show whether the project is a straightforward addition or a combined PostgreSQL and PostGIS upgrade, and that difference changes both the test plan and the quote you request.
What PostGIS adds to PostgreSQL, according to its documentation
PostGIS extends PostgreSQL with spatial types, functions, indexes and coordinate reference system handling. Each group changes schema design, query behavior or upgrade planning, so the choices you make in one affect the others. Confirm the supported feature set against the PostGIS release you plan to install.
Spatial data types
PostGIS documents geometry and geography types for storing points, lines, polygons and collections of them in ordinary tables. The two types calculate differently: geometry uses planar calculations in the units of its coordinate system, while geography uses spherical or ellipsoidal calculations in meters. Choosing between them early affects query results, index use and how data is cast between systems. Confirm which types and subtypes your target release documents before you design the schema.
Spatial functions and operators
The documentation groups functions for constructing geometries, reading and writing formats, measuring distance and area, testing relationships such as containment and intersection, and transforming or overlaying shapes. Operators support index-aware comparisons. The main implementation risk lies in mixing planar and spherical functions and in unexpected results near the dateline or poles. Build a test set with known answers for the functions your application calls, and rerun it after each PostGIS upgrade.
Spatial index support
PostGIS documents spatial indexing on geometry and geography columns, built on PostgreSQL's index access methods so the planner can skip most rows for bounding-box and relationship queries. Index creation on large tables is a planned maintenance task, and the index must be kept current as data changes. Check the index type and operator class your release documents for each column type, then compare query plans with EXPLAIN on representative data volumes before sizing storage and maintenance windows.
Coordinate reference system handling
PostGIS stores a spatial reference identifier with geometry data and documents functions that transform coordinates between reference systems. Missing or mismatched identifiers are a common cause of wrong distances and failed joins, so the reference system for each dataset should be set and checked at load time. Confirm the reference system catalog and transformation behavior in the release you install, and record which projections your agencies, partners or data sources require.
Extension packaging and upgrades
PostGIS is installed as a PostgreSQL extension in each database that needs it, and its documentation describes upgrade scripts that move an installed extension to a newer version. Those scripts must match the PostgreSQL major version you run and the packages present on the server. Confirm the upgrade path between your current and planned PostGIS releases before scheduling a PostgreSQL major upgrade, because the two upgrades are easier to sequence than to repair after the fact.
How PostGIS versions must line up with each PostgreSQL major
PostGIS is built against specific PostgreSQL major versions, so the extension package you install must target the same major as the server that loads it. A build for one major will not load on another. The PostgreSQL major and the PostGIS release therefore have to be chosen as a pair. Today's supported PostgreSQL majors are 14 through 18. PostgreSQL 14 leaves support on November 12, 2026, and PostgreSQL 18 is supported until November 14, 2030. Any plan for the database has to start from that pair, not from one component alone.
The PostGIS release you pin today limits the PostgreSQL majors you can move to next. Illustrative example: a team running PostgreSQL 14 that standardizes on a PostGIS release whose compatibility list stops short of PostgreSQL 18 cannot upgrade directly to 18 until it moves to a PostGIS release that supports it. The upgrade date for PostgreSQL 14 is fixed by the project's support policy, so the team needs the target major and the matching PostGIS release identified well before the change window opens. Add the extension path to the upgrade plan as a dependency, not as an afterthought.
Confirm the compatibility matrix with the PostGIS project before you pin any version. Check which PostGIS releases list each PostgreSQL major as supported, and whether the chosen release works with the GEOS, PROJ and GDAL versions your operating system packages provide. Also check how long that PostGIS release line receives fixes. Record the answers in your build notes, along with the operating system package source, so the next person can reproduce the pairing without guessing.
During an upgrade, install the matching PostGIS package on the new PostgreSQL major before restoring data or running pg_upgrade, and test on a copy of the cluster first. After the database starts, run the extension update step and confirm the loaded version with SELECT PostGIS_full_version(). With logical replication, install the matching package on the subscriber before the initial sync begins. Minor PostgreSQL releases do not change the storage format, so routine minor updates rarely affect the PostGIS pairing. A PostGIS release change, though, needs its own test cycle.
Treat each PostgreSQL major and PostGIS release pair as one tested combination in configuration management. Pin both versions together, rerun your spatial query and index checks after every change, and keep a record of which pair is running in each environment. Review that record against the PostgreSQL support dates each year so the next major upgrade starts with a compatible PostGIS release already selected.
Which installation and version decisions shape the PostGIS build
This table compares the installation paths, version policies and data placement choices that determine how PostGIS is built, patched and restored on self-hosted PostgreSQL. Read each row by asking which option fits your change process, test capacity and recovery commitments. The main takeaway is that the extension version and the location of geometry data affect backups, access control and upgrade effort as much as the installation method does.
| Decision | Option | Trade-off | When it fits |
|---|---|---|---|
| Installation source | Operating system or PostgreSQL repository packages | Quick to install and patch, but the available build follows the repository schedule | Teams that patch often and accept routine package updates |
| Installation source | Build from source against your PostgreSQL installation | Full control of compiler, dependencies and version, but you own the build pipeline | Hardened or air-gapped estates where every artifact must be reproduced and tested |
| Installation source | Container image bundling PostgreSQL and PostGIS | Reproducible and easy to move, but image rebuilds and scanning become your responsibility | Kubernetes estates that already promote images through an internal registry |
| Version policy | Pin one tested PostGIS release for each PostgreSQL major version | Predictable and easy to assess, but security fixes need a planned upgrade cycle | Regulated environments that need a frozen, tested build |
| Version policy | Follow new PostGIS releases as they ship | Picks up fixes sooner, but each change needs regression testing of spatial queries | Teams with strong test coverage and frequent patch windows |
| Geometry location | Spatial tables in existing application schemas | One backup set and one role model, but spatial data inherits application access and restore timing | Small spatial datasets tightly coupled to one application |
| Geometry location | Spatial data in a dedicated database | Separate access and restore scope, but cross-database joins need extra design | Several applications share spatial data or it has different access rules |
How spatial indexing and data model choices affect query speed
The choice between geometry and geography, and the spatial reference identifier (SRID) behind each column, shapes both what a query returns and how quickly it runs, so settle it before the first load. Geometry values use planar math in the units of their SRID, which suits data confined to one projected area. Geography values treat coordinates as points on an ellipsoid and return distances in meters across wide areas, at a higher calculation cost per comparison. Many teams store data in a geographic SRID such as 4326 and use a projected SRID for local distance work. Record the type and SRID chosen for each table and the reason for it, because mixing them in one query is a common source of wrong results, not only slow ones.
Spatial indexes in PostGIS are normally GiST indexes on the geometry or geography column, created with CREATE INDEX and the GIST access method. Building one reads the whole table, so build time and temporary disk use grow with row count and with the complexity of each shape. Index entries hold bounding boxes, which filter candidate rows before exact geometry tests run. A query benefits only when its predicate can use the index, such as ST_Intersects or ST_DWithin applied directly to the indexed column. Wrapping that column in a function or cast often disables the index. Inserts and updates maintain the index as well, so autovacuum and ANALYZE must keep statistics and free space current. Confirm with your PostgreSQL administrators how bloated spatial indexes will be rebuilt, including whether REINDEX CONCURRENTLY is available in your planned version.
Index and data model choices also drive storage. A GiST index over large polygons with many vertices can be large, and heavy geometries raise the cost of every exact test that follows the index lookup. Options to evaluate with the data owners include simplifying geometry for coarser query tiers, storing precomputed bounding boxes, and splitting very large features into smaller pieces. Changing the SRID later usually means rewriting stored values and rebuilding indexes, which makes the decision expensive to reverse. Compare table size and index size for each candidate design using the same source data, so the trade-off between query behavior and storage is measured rather than assumed.
Test index usage with query plans captured on representative data volumes. Load a production-shaped copy into staging, run ANALYZE, and capture EXPLAIN (ANALYZE, BUFFERS) output for the queries the application sends, using parameter values that match real usage. Confirm that the plan uses the spatial index and look for sequential scans on large tables. Repeat the test after expected growth and after any change to SRID or index definition. On staging, also measure index build time and table and index size using pg_total_relation_size and pg_relation_size. These measurements determine when production loads and index builds can be scheduled and what maintenance window to request. Ask for the plans and measurements to be delivered as part of the written scope.
How the PostGIS build runs from staging to production
This sequence takes a PostGIS deployment from an inventory of spatial data to a production cutover that the team can repeat. Each step closes with a written record, so the team can check the work at every stage before a change reaches production.
Inventory data, queries and spatial workload
The team lists every spatial dataset, including its geometry types, coordinate reference systems, row counts and expected growth, along with the queries and applications that read or write it. DeployOpen works with your data owners and developers on this inventory, and your team confirms the final list. The output is an inventory register that names each spatial table, the spatial functions it depends on (for example, distance or intersection tests) and the systems that rely on it. The step is done when data owners have signed off the register.
Confirm PostgreSQL major and PostGIS release
The team checks which PostgreSQL major versions are still supported, picks the one the platform will run, and confirms in the PostGIS documentation which PostGIS release supports that major. The PostgreSQL versioning policy lists support end dates, and version 14 is scheduled to reach end of life on November 12, 2026, so a platform started on 14 needs its upgrade path set early. The output is a version matrix covering the PostgreSQL major, the PostGIS release, the operating system packages and the supporting libraries that release requires. The step is done when the matrix is approved and pinned in configuration management.
Install PostGIS on a staging cluster
DeployOpen's engineers build a staging cluster in your environment that matches the production topology, install PostGIS at the versions pinned in the matrix, and create the extension in each target database. The extension must be created in each database, not only installed on the server, and the version reported by the server must match the matrix. The team also sets extension privileges according to who may create spatial objects. The output is a staging build record with package versions, installation commands, extension versions per database and configuration changes. The step is done when a clean rebuild from that record produces the same result.
Design the spatial schema and indexes
Using the inventory, the team specifies how each spatial column is typed, whether each dataset uses geometry or geography, the SRID for each column and any constraints on geometry type and dimension. It defines GiST indexes on spatial columns and decides where expression or partial indexes are justified, then documents the query patterns those indexes are meant to serve. Reviewers test the design with EXPLAIN on representative queries in staging. The output is a schema and index specification with DDL, index definitions and the query plans that support each decision. The step is done when the application team confirms the query set matches the specification.
Load and validate sample data
The team loads representative sample data, ideally a subset that includes the edge cases from the inventory, such as invalid geometries, mixed SRIDs and very large polygons. It checks validity with PostGIS validation functions, confirms that transforms between SRIDs return expected coordinates and reruns the key queries to check index use and plan quality. Any data fixes are scripted and recorded as migration steps so they repeat in production. The output is a validation report listing failed checks, the fixes applied and before-and-after plan results. The step is done when data owners accept the report.
Test backup, restore and point-in-time recovery
The team takes a base backup, archives WAL files and restores into a separate environment. After the restore, it confirms that the extension is present in each database at the expected version, that spatial indexes exist and are valid and that the validation queries return the same results as before. It also runs a point-in-time recovery to a chosen moment and checks the spatial data at that point. Where incremental backups are used, the restore includes reconstruction with pg_combinebackup. The output is a restore test record with backup identifiers, restore steps, extension version checks and results. The step is done when a restore from the production backup chain passes every check.
Rehearse a major upgrade with PostGIS
Before production, the team runs a full major upgrade rehearsal on a copy of the staging data, using the method chosen for this platform: pg_upgrade, a dump and restore, or logical replication. The PostgreSQL upgrade documentation notes that logical replication works across major versions and can limit downtime to several seconds. After the core upgrade, the PostGIS extension is upgraded to the release that matches the new PostgreSQL major, and spatial queries and indexes are rechecked. The output is an upgrade runbook with prerequisites, commands, rollback points, extension upgrade steps and observed timings. The step is done when a rehearsal runs cleanly and any differences in query results are explained.
Cut over to production with rollback
The team schedules the cutover, freezes schema changes and runs the approved runbook against production. Validation checks reuse the queries and results from the restore and sample data steps, and applications reconnect through the connection layer. After the change, the team watches spatial query latency and error rates. The rollback plan states the last point at which reverting is still possible. The output is a signed cutover record with executed steps, validation results, the rollback decision point and handover documentation for operations. The step is done when operations has taken over monitoring and the record is filed.
Licensing questions to settle before the build
Settle the licensing questions before the build starts, because the answers decide what you may do with the database once it is running and whether you can ship it. PostgreSQL itself is released under the PostgreSQL License, a liberal open source license similar to the BSD and MIT licenses. Read the license text on the project's licence page yourself and keep a dated copy with the build record. Your team should be able to show which license governs each component in the stack.
PostGIS is a separate project with its own license terms, and those terms do not come from the PostgreSQL License. Confirm the license for the exact PostGIS release you plan to install, and check the terms of any bundled components, such as libraries packaged alongside it in your operating system packages or container image. Record the release number, the license file you reviewed and the date of your check. A later PostGIS upgrade can change both the version and its terms, so repeat this check at each upgrade.
Internal use and distribution raise different questions. If the database and PostGIS run only inside your organization and staff use applications built on them, the licensing review is usually narrower. If you embed the database in a product, include it in an installer, deliver it as an appliance or hand copies to customers, the notice and source-availability obligations of the components you ship may apply to your package. Ask counsel whether your application and the database are separate programs and what you must provide with each release.
Running the platform for customers on servers you operate is a different case from shipping copies to them. Customers who never receive a binary may raise different obligations than customers who install software on their own hardware. This is a question for counsel, and the answer depends on how your contracts, deployment model and any modifications to the code fit together. Do not assume that a hosting arrangement and a distribution arrangement carry the same terms.
Give counsel a written package before the build: the deployment model (internal, hosted or distributed), the full list of components with their versions, whether you will modify any source code, whether customers receive binaries or images, and how the application connects to PostGIS. Assign one owner for the license record and set a review point for each PostgreSQL or PostGIS upgrade. Use the project's license documentation as the primary reference, and treat counsel's written opinion, not this page, as the basis for your decision.
What drives PostGIS effort and cost, and how to keep it down
This table lists the drivers that change PostGIS effort and cost on a self-hosted PostgreSQL cluster, with the direction each one pushes and a containment step. Read the first column as a question to settle before scoping, and the last column as a lever you control. The main takeaway is that dataset count, cluster state and the upgrade path usually matter more than the extension itself.
| Driver | Effect on cost and effort | How to keep it down |
|---|---|---|
| Spatial datasets and source formats | Each dataset adds loading, geometry validation, SRID decisions and indexing. Messy source formats add cleaning work before any load. | Fix scope to the first datasets in a written statement of work, and treat later datasets as change requests. |
| Spatial queries and integrations | More query shapes and consuming applications add index tuning, performance testing and API contract work. | List the top queries with their owners, and agree in writing which integrations ship in the first release. |
| New cluster or extending an existing one | Extending a busy cluster adds change windows, regression testing and access reviews. A new cluster adds platform setup but carries less shared workload risk. | Reuse existing monitoring, backup and access patterns. Confirm extension availability for your PostgreSQL build before scoping. |
| High availability and backup requirements | Replicas, failover tooling and point-in-time recovery add build and restore-test effort, plus recurring operations work. | Reuse the backup pipeline already in place, and test restores with spatial tables included before go-live. |
| PostgreSQL upgrade path | Each major upgrade needs a PostGIS compatibility check for the target version. PostgreSQL 14 support ends November 12, 2026, so older clusters may need planning soon. | Confirm the PostGIS build supports the target PostgreSQL major, then stage upgrades on a copy and plan both upgrades together. |
| Compliance evidence | Assessors may ask for change records, access reviews and restore test results that cover spatial data. Evidence collection repeats each assessment cycle. | Agree the evidence list in writing at the start, and generate it from the runbooks your operations team already uses. |
How PostGIS connects to the rest of the PostgreSQL platform
PostGIS runs inside the same PostgreSQL cluster as your other workloads, so its behavior depends on the platform around it. The cards below cover the components that most often touch spatial data: replicas, backups, connection pooling, audit logging, container operators and reporting tools. Confirm each integration in your own environment before you rely on it.
Extension presence on standbys
Hot standbys serve read-only queries, but PostGIS functions and types are only usable on a standby if the extension is installed there at a matching version. Physical replication normally carries the extension with the primary, while failover tooling and manual extension changes can break that assumption. Run spatial queries on a promoted standby during failover tests, and confirm the PostGIS version is the same on every node.
Backups and point-in-time recovery
Point-in-time recovery combines a base backup with archived WAL files, so spatial tables are covered when the backup captures the whole cluster. Restore tests should run spatial queries, check geometry validity and confirm that spatial indexes are used, in addition to comparing row counts. If you use incremental backups with pg_combinebackup, include that reconstruction step in the rehearsal. Confirm which PostGIS version the restore target needs.
Connection pooling with PgBouncer
PgBouncer sits between application services and PostgreSQL to limit the number of server connections. Spatial workloads often run long or CPU-heavy queries, so pool mode, query timeouts and connection limits need review before go live. Check that search_path and other session settings used by GIS clients still apply under the pool mode you choose. Track PgBouncer releases for security fixes and confirm the version your team deploys.
Audit logging of spatial access
pgAudit writes session and object audit records to the PostgreSQL log, which helps show who read or changed geometry columns. Decide which statement classes to log, because broad read logging on large layers produces high log volume. Confirm that your pgAudit version matches your PostgreSQL major version and that the logs reach your SIEM with the fields your auditors expect. Review sample entries to see how spatial queries are recorded.
Kubernetes operators for PostgreSQL
If the cluster runs in containers, a PostgreSQL operator manages replicas, failover and backups, and it determines how extensions are loaded. Confirm that the operator supports PostGIS in your container image and that the extension version is pinned in the cluster definition. Image changes made during an operator-driven upgrade need a test restore in a staging cluster first. Check the operator's documentation for each behavior, because support differs between projects.
Reporting tools that query geometry
Metabase, Apache Superset and Grafana can query PostGIS geometry columns, but each tool handles geometry types and map views differently. Confirm how each tool renders geometry and whether it needs a dedicated read-only role with access only to the spatial tables it reports on. Long-running map queries can compete with transactional workloads, so route them to a replica where your topology allows. Test with production-sized layers.
What do teams ask before hiring help for PostGIS?
What does a PostGIS implementation cost and how is the quote built?
The quote follows from the written scope, and DeployOpen does not publish a price list. Cost is driven by the number of databases and environments, the volume and geometry types of your data, how many spatial queries and indexes need tuning, whether existing GIS applications or ETL jobs must change, and how many systems connect to the database. Work usually falls into one-time items (planning, installation, data loading, index design, testing and handover) and recurring items (extension updates, PostgreSQL minor and major upgrades, monitoring, and support if you buy a retainer). Ask for each item to be listed with its deliverable and who performs it. Ask what is excluded, such as GIS desktop client changes or basemap data licensing.
How long does a PostGIS implementation take and what sets the timeline?
The timeline comes from the scope agreed in writing, and no single duration applies to every deployment. The largest factors are the number of spatial datasets to load and validate, the number of query patterns that need index review, how many applications depend on the database, and whether the work must fit a change window in a regulated environment. Approvals, access provisioning in your cloud account or data center, and the availability of your GIS subject matter experts often take longer than the technical build. If PostGIS is paired with a PostgreSQL major upgrade, that upgrade adds its own test cycle. Ask for a plan with milestones, named dependencies, and the assumptions behind each date, so you can see which delays sit with your team and which sit with the partner.
What must our team provide before a PostGIS project starts?
Plan to provide representative data samples, a list of the spatial queries and reports your applications run, access to the target PostgreSQL environment, and a maintenance window for cutover and any restarts. Samples should cover the coordinate reference systems, geometry types, and data sizes you actually store, because index and query tuning depends on them. Query lists should include slow queries from the current system, with the response times users expect. Access usually means accounts for the database host, the backup system, and the monitoring stack, plus the network paths your applications use. Name a data owner who can approve how sample data is handled, since location data can be personal or sensitive. Confirm these items in the statement of work so gaps are found before the build starts.
Can our in-house team implement PostGIS without a partner?
Often yes, if your team already runs PostgreSQL in production and has someone comfortable with spatial data. The skills that matter are installing and versioning the extension alongside PostgreSQL, understanding spatial reference systems and geometry types, choosing and maintaining spatial indexes, and testing query plans with realistic data. Gaps usually appear in three places: the first major upgrade, where extension compatibility must be checked again; performance work on large or complex query sets; and operational runbooks for backup, restore and recovery. Ask your team to test itself against these areas before deciding. A partner makes more sense when the deadline is fixed, the team is small, or the deployment must produce audit evidence. Weigh internal time against the cost of mistakes in production.
How does PostGIS affect a PostgreSQL major upgrade?
PostGIS is a loadable extension, so it must be installed for the new PostgreSQL major version, and its compatibility must be confirmed before you cut over. The upgrade method matters. The PostgreSQL upgrading documentation lists three options: pg_dumpall with restore, pg_upgrade, and logical replication. Logical replication works between major versions and allows an upgrade with only several seconds of downtime. The extension must exist in the target cluster, and its objects and data types must survive the chosen method. Test the full sequence on a copy that holds your real spatial data and queries, then compare query plans after the upgrade. PostgreSQL 18's pg_upgrade retains planner statistics across major upgrades, which helps performance after cutover. Confirm the PostGIS release supported on each target PostgreSQL version before you schedule the work.
Does DeployOpen issue a compliance certification for PostGIS deployments?
No. DeployOpen does not issue audit reports, attestations, or certifications. Independent auditors and certification bodies perform that work. DeployOpen can prepare the system, configuration, access controls, and evidence that an assessor will review, such as documented extension versions, backup and restore records, and access and audit logging settings for the spatial database. Which control requirements apply to your geospatial data depends on your regulators, contracts, and data classification, so confirm those first. Ask the partner which evidence it will produce, who owns each control after handover, and how the records will stay current through PostGIS and PostgreSQL updates. Then share the evidence with your auditor early to confirm it meets their expectations.
Which PostgreSQL version should we pair with PostGIS today?
Choose a PostgreSQL major version that is still supported for the whole period you plan to run it, and confirm PostGIS support for that version before you commit. According to the PostgreSQL versioning policy, supported major versions are 18, 17, 16, 15 and 14. Version 18 was first released on September 25, 2025 and has a final release date of November 14, 2030. Version 17 is supported to November 8, 2029, version 16 to November 9, 2028, and version 15 to November 11, 2027. Version 14 reaches end of life on November 12, 2026, so a new deployment should not start on it without a documented reason. Ask the implementation team which PostGIS release it will install on the target major version and how that pairing will be tested before go-live.
How DeployOpen scopes and delivers a PostGIS implementation
DeployOpen plans, installs, configures and documents PostGIS on PostgreSQL clusters you run in your own cloud accounts, data centers or air-gapped networks. Each engagement starts from a written scope that fixes the spatial workloads, the PostgreSQL and PostGIS versions, and the handover deliverables before any build work begins.
How we scope
- Inventory the geospatial datasets, geometry and geography types, coordinate reference systems and the queries that depend on them.
- Confirm the PostgreSQL major version you run or plan to run, and map which PostGIS release your team will install against it.
- Agree in writing whether the work covers extension installation, spatial indexing, data loading, backups, or major upgrade planning.
How we build
- Install and version PostGIS alongside your PostgreSQL packages, then test extension creation and upgrade paths in a non-production cluster.
- Design GiST and SP-GiST spatial indexes against your real query patterns, and measure index build time and size before go-live.
- Review GPL licensing implications for how your organization distributes or embeds PostGIS, and record the conclusions for your legal team.
How we hand over
- Deliver runbooks for installing, upgrading and rolling back the PostGIS extension in step with PostgreSQL minor and major releases.
- Document the spatial schema, index strategy, coordinate reference system conventions and the test queries used for acceptance.
- Walk your database and platform engineers through the procedures and record who owns each operational task after handover.
How we support
- Plan PostGIS compatibility checks before each PostgreSQL major upgrade, whether you use pg_upgrade or logical replication.
- Offer ongoing support, upgrades and testing as a retainer if your team wants DeployOpen to keep PostGIS current after the project.
- Ask your DeployOpen contact to confirm the support boundaries, response expectations and change process in the written scope.
