PostgreSQL and PostGIS for institutional data: licence, support period and responsibility

PostgreSQL is distributed under the PostgreSQL Licence. The project describes this licence as a liberal open-source licence similar to the BSD and MIT licences. The licence text permits the use, copying, modification and distribution of the software and its documentation for any purpose, free of charge and without a written agreement. The only condition is that the copyright notice and the licence paragraphs are preserved in all copies. The licence also appears on the Open Source Initiative's list of licences.

For the institution, the first consequence of this is that there is no licence fee tied to the number of users or processors, and no licence-audit risk. The second consequence is that the software's future does not depend on the commercial decisions of a single vendor. PostgreSQL is developed as a project carried out under the name PostgreSQL Global Development Group, by developers in different parts of the world, through open mailing lists and publicly open review cycles. The project explicitly states that it is committed to offering PostgreSQL as free and open-source software indefinitely and that it has no plan to change the licence.

The licence text also states that the software is provided as is and carries no obligation of maintenance, support or updates. Institutions that need commercial support must therefore obtain this service through a separate agreement with the contractor or a support company.

Under PostgreSQL's version policy, each major version is supported for five years from its first release. At the end of this period a final minor release is published and the major version falls out of support. Security fixes are distributed within minor releases, and the project always recommends using the latest available minor release. No new security patch is issued for unsupported versions.

According to the table on the PostgreSQL versioning page, as of 23 October 2026 the supported major versions and their planned final release dates are as follows:

• PostgreSQL 18: first released 25 September 2025, final release 14 November 2030
• PostgreSQL 17: first released 26 September 2024, final release 8 November 2029
• PostgreSQL 16: first released 14 September 2023, final release 9 November 2028
• PostgreSQL 15: first released 13 October 2022, final release 11 November 2027
• PostgreSQL 14: first released 30 September 2021, final release 12 November 2026

This five-year period provides direct input into the institution's information systems planning. Once a project is accepted, the major version in use and when support for that version will end are both known. This allows the upgrade work to be scheduled into the budget and work calendar well ahead of time, rather than being left to the last minute.

PostGIS is the extension that gives PostgreSQL the ability to store, index and query spatial data, and is a project of the OSGeo Foundation. In urban information systems, geometries such as parcels, roads, buildings and infrastructure lines can be kept in the same database as attribute data thanks to this extension. PostGIS is distributed under GNU GPL version 2. According to the project's official explanation, this licence does not affect the licence of an application merely because that application uses a PostGIS database; the obligation to share arises only when the PostGIS source code itself is modified and distributed.

PostGIS's spatial data model is based on the Simple Feature Access standard published by the Open Geospatial Consortium (OGC). The SQL part of this standard is also known as ISO 19125, and it defines how spatial objects are stored, queried and updated within an SQL schema. The PostGIS documentation states that geometry is expressed as text in Well-Known Text (WKT) form and in binary as Well-Known Binary (WKB) form. Thanks to these common formats, the same data can be read by many open-source and commercial geographic information system programs.

The most concrete benefit of compliance with open standards for the institution is that the data does not remain dependent on a specific piece of software. PostgreSQL aims for compliance with the SQL standard; the project states that, as of version 18, it meets at least 170 of the 177 features mandatory for SQL:2023 core compliance. On the spatial data side, the OGC- and ISO 19125-based geometry model provides a common basis for transferring the data to another database or to desktop geographic information system software.

Portability becomes decisive when the contractor changes, when data is shared between institutions, and when the system is restructured. The institution should explicitly require in the technical specification that the data can be exported in open and documented formats and that the data model is shared with the institution. Using an open database does not guarantee this on its own; application-specific, undocumented table structures can weaken portability.

The PostgreSQL documentation states that, as with any system holding valuable data, PostgreSQL databases must also be backed up regularly, and it defines three basic methods: SQL dump, file-system-level backup, and continuous archiving. Continuous archiving provides point-in-time recovery, allowing a return to a specific moment. Which method is used should be determined according to how much data loss and how much downtime the institution can accept.

In Türkiye, there is also a binding framework for public institutions on this matter. The March 2026 version 1.1 of the Information and Communication Security Guide, prepared pursuant to Presidential Circular No. 2019/12, requires that backups be subjected to regular restore testing and that these tests be recorded. The same guide, among its database hardening measures, states that systems no longer supported by their vendor may contain vulnerabilities, and requires that the currency of systems be checked at regular intervals.

Major version upgrades also require planning. According to the PostgreSQL documentation, the internal data storage format may change between major versions, and new major versions may contain incompatibilities visible to the user. The documentation describes upgrade methods such as logical dump, the in-place migration tool pg_upgrade, and logical replication, and recommends that cautious users test their client applications on the new version before fully switching over. For this reason, maintenance agreements should specify in writing, in addition to minor version updates, who is responsible for major version transitions, on what schedule, and through what testing steps.

• The major version in use and the support end date for that version should be recorded in the institution's software inventory.
• A regular application schedule should be set for minor version updates.
• The backup method, retention period and frequency of restore testing should be put in writing.
• The major version upgrade should be tied to a plan that has been tested in a staging environment before the support end date.
• The ability to export the data in open formats and the delivery of the data model documentation to the institution should be included in the technical specification.