Hosted PostGIS: which service should you choose?

What you need from a hosted PostGIS database

PostgreSQL is an open source database engine; PostGIS is its spatial extension, also open source, which adds geometry and geography types, spatial indexes and hundreds of analysis functions. A hosted PostGIS database is that pair installed, updated and monitored by a provider, and used remotely.

For GIS work, the need is concrete: load layers from QGIS, edit them as a team, publish them in a web map portal or an OGC server, and never lose data. So the real question is not just where to find PostgreSQL online, but which service makes that workflow simple day to day.

General-purpose cloud services

The major managed PostgreSQL services all offer PostGIS, which you enable yourself with an SQL command. They are excellent products, designed first for application developers, with advanced options such as replicas, autoscaling and data branching.

PostGIS availability checked on 11/09/2026 in the Amazon RDS documentation, on the Supabase extensions page and in the Neon documentation. PostGIS versions vary with the PostgreSQL version you choose. Pricing for these services depends on many parameters and is not repeated here: see their official pages.

Five criteria for choosing hosted PostGIS

• PostGIS available and current. Check which PostGIS version is offered and how to enable it. On a general-purpose service, you create the extension yourself; on a database built for GIS, it is already there.
• Access from QGIS. QGIS connects directly to PostgreSQL. You need an address reachable from your workstation, credentials that are easy to copy, and no private network to configure.
• Encrypted connection (SSL). Your data travels over the Internet: the connection must be encrypted, without complicated certificate handling in QGIS.
• Size and overage. What happens when the database is full? Early warning and zero data loss matter more than a large theoretical volume.
• Clear price per GB. A GIS grows with its data. A price per GB per month is easy to forecast; billing by compute time, I/O and transfer needs a finer estimate.

Add one practical question to these five criteria: who answers when a connection fails? On a general-purpose service, support covers PostgreSQL in general; a projection error, a missing spatial index or a layer that will not display in QGIS remains your problem. A GIS-focused host knows these situations and speaks the same language as your GIS team. That matters most in the first weeks, when most connection and import questions come up.

A database built for GIS: the LizPack approach

LizPack, an open source geospatial infrastructure, did not write PostgreSQL or PostGIS: it hosts and maintains them. The dedicated PostgreSQL/PostGIS databases come with PostgreSQL 17 and PostGIS 3.5, plus the hstore, uuid-ossp and pg_trgm extensions already installed.

• Each database has its own credentials and an SSL connection, usable from QGIS Desktop, pgAdmin, DBeaver or your scripts.
• You choose the size at creation, from 1 to 10 GB; billing follows that volume, per GB per month.
• An email warns you at 60% full, then at 75, 80, 90 and 95%.
• Beyond the quota, you have 24 hours to free up space; then the database is stopped, and no data is deleted.
• A database linked to a LizPack Map instance serves its layers on the map, editable online; it also connects to GeoServer Cloud and receives LizPack Field surveys.

The Basic and Pro plans already include PostgreSQL/PostGIS storage tied to the LizPack Map instance, reachable directly from QGIS starting with the Pro plan. Dedicated databases are additional databases, sized independently. The current price per GB is shown on the pricing page.

Getting a hosted PostGIS database up and running

Whatever service you choose, setting up hosted PostGIS follows the same path. Here it is with a LizPack database, noting what differs elsewhere.

1. Create the database from the dashboard by choosing its size, from 1 to 10 GB. On a general-purpose service, you also choose a region, an instance class and network rules.
2. Copy the host, port and credentials. On a general-purpose service, check that your workstation's address is allowed to connect.
3. Add a PostgreSQL connection in QGIS with these details, in SSL mode, and save it for the whole team.
4. Import your layers from QGIS or with the GDAL ogr2ogr tool. On a general-purpose service, first create the PostGIS extension in the database.
5. Link the database to your LizPack Map instance to serve its layers on the map, editable online.

To leave a service or switch providers, standard PostgreSQL tools are enough: pg_dump exports the database and pg_restore loads it elsewhere. That is the advantage of an open format: your database is not tied to any provider, and you can run a trial without fear of lock-in. Just check that the PostGIS version at the destination is the same as or newer than the original.

The most common connection errors from QGIS

Most failed connections to a hosted PostGIS database have well-known causes. Before opening a ticket, go through this list: it solves the vast majority of cases, whatever the provider.

• Timeout. The workstation cannot reach the server. On a general-purpose service, your workstation's IP address is often not allowed in the network rules. At the office, a firewall may also block the PostgreSQL port: ask your IT department whether outbound traffic on it is open.
• Password authentication failed. The username or password is wrong, often because of an extra copied space or a badly pasted special character. Copy them again from the source instead of retyping them.
• Database does not exist. The database name is not the same as the username. Check the database field of the connection: it must contain the exact name provided by the host.
• SSL error. The server requires an encrypted connection and the client does not request one, or the other way round. In QGIS, the SSL mode is set in the connection dialog; require mode encrypts the connection without checking the certificate, while verify-ca and verify-full also check the server's identity but need its certificate authority.
• Empty or missing layers. The connection works but no layer appears: the table has no registered geometry column, or the user lacks read permission on the schema. Also tick the option that lists tables without geometry if you are looking for an attribute-only table.

Keep a record of the configuration that works: host, port, database name, SSL mode. The day a colleague cannot connect, comparing their connection with yours takes a minute. Write it down in a shared note rather than in someone's head, without the password.

Coordinate systems and spatial indexes: two settings that drive speed

A slow hosted PostGIS database is rarely a server problem. In most cases, the cause is a wrongly declared coordinate system or a missing spatial index. Both can be fixed in minutes.

• Declare the right SRID. Each geometry column carries a coordinate system code (SRID), for example 4326 for WGS 84 geographic coordinates. A column declared with the wrong SRID shows up in the wrong place, or forces QGIS to reproject every feature on the fly. The PostGIS functions Find_SRID and UpdateGeometrySRID let you check and fix the declaration.
• Store data in a projection suited to your measurements. To compute areas and distances in meters over a territory, a local metric projection avoids conversions. Keep the same system for tables you often combine: a spatial join between two different SRIDs forces PostGIS to transform geometries.
• Create a spatial index. A GiST index on the geometry column (CREATE INDEX ... USING GIST) lets PostGIS read only the features in the displayed area. Without it, every pan of the map scans the whole table. QGIS creates one by default during import, but tables loaded by script or by ogr2ogr with custom options sometimes lack one.
• Refresh the statistics. After a large import, the ANALYZE command tells the query planner about the table's contents. It will then choose to use the index instead of a full scan.

These settings matter even more when the database feeds an online map: each visitor triggers queries, and a missing index is paid for on every display.

Protecting database credentials in your QGIS projects

By default, QGIS can save the username and password of a PostgreSQL connection in plain text inside the project file. That is convenient, but any .qgs or .qgz file shared by email or placed on a shared drive then carries the keys to your database.

• Use the QGIS authentication manager. It stores credentials in a local database encrypted with a master password. The project then holds only a reference to that configuration, not the password.
• Or a PostgreSQL service file. The pg_service.conf file maps a service name to the host, port and database. The project references the service; each workstation keeps its own settings.
• Create separate accounts per use. A read-only account for viewing, a read-write account for editors. If one credential leaks, the damage stays limited.
• Change the password when a team member leaves, and check that no shared project still contains the old one in plain text.

For a project published on the web, the question is different: the map server connects to the database with its own credentials, and visitors never access it directly. On a LizPack Map instance, the link between Lizmap, QGIS Server and PostGIS comes preconfigured.

Backing up and sizing hosted PostGIS

A host protects its infrastructure, but your mistakes remain yours: a table dropped by accident or a badly targeted SQL update can only be undone with a copy. So keep your own exports, on top of the provider's protections.

1. Export the database in custom format with pg_dump (the -Fc option): the file is compressed and can be restored table by table if needed.
2. Keep several dated copies, at least one off your workstation.
3. Restore a copy into a test database from time to time with pg_restore, to check that it is complete.
4. Note the PostgreSQL and PostGIS versions of each export: a restore goes to an equal or newer version.

For sizing, start from the real volume of your data, not from the size of the source files: a layer imported into PostGIS, with its indexes, often takes a different amount of space than its Shapefile or GeoPackage. Import a representative sample, measure the space used with the pg_database_size function, then extrapolate with a margin for growth. Large rasters are often better kept as files served by a map server than inside the database itself.

At LizPack, the size of a dedicated database is chosen from 1 to 10 GB at creation, and fill-level alerts give you time to react before you reach the limit.

When to prefer one or the other

A general-purpose service fits better if your database mainly serves a business application, if you need several hundred gigabytes or read replicas, or if your organization is already committed to a cloud provider. You gain power in exchange for configuration work and closer bill tracking.

A database built for GIS fits better if your users work in QGIS, if volumes stay at a few gigabytes and if the database must feed an online map. To compare with running your own server, read host Lizmap or install it yourself; for the overall budget, what an open source web GIS costs; and to understand our role, what LizPack does.

Frequently asked questions