PostgreSQL is a popular choice for organizations building flexible, open-source GIS infrastructures. When used with ArcGIS, it provides a modern database platform, support for multiple spatial types, and deployment options for both self-managed and cloud database services. This article explains how PostgreSQL and ArcGIS work together, what to prepare before you begin, how spatial types fit into the picture, and when to use the Enable Enterprise Geodatabase and Create Enterprise Geodatabase tools.

PostgreSQL and ArcGIS

PostgreSQL is one of the database management systems supported in ArcGIS. In this blog, we refer to the PostgreSQL deployment options as:

• Self-managed PostgreSQL (on-premises or self-hosted in the cloud): PostgreSQL is installed and managed by your organization, on a physical server or virtual machine hosted on-premises or in the cloud, with full control over the database instance.
• Managed PostgreSQL service (Database-as-a-Service/DBaaS): PostgreSQL is provided as a managed service by cloud providers, such as AWS, Microsoft Azure, or Google Cloud Platform. While you typically administer databases and roles, the provider manages the underlying infrastructure, operating system, and database instance. As a result, certain server-level configurations and extensions may be restricted.

PostgreSQL supports multiple spatial storage options in both self-managed and DBaaS deployments. ArcGIS supports three spatial types in PostgreSQL:

• ST_Geometry (Esri) — The default spatial type for enterprise geodatabases in PostgreSQL.
• PostGIS geometry — A widely used open-source spatial type that integrates well with many GIS and analytics tools.
• PostGIS geography — An open-source spatial type designed for geodetic data and global-scale analysis.

You can use one or more of these types depending on your workflows. For example, DBaaS offerings support PostGIS but do not support ST_Geometry. If your long-term strategy includes moving to a PostgreSQL DBaaS platform, consider adopting PostGIS early and creating your spatial datasets using PostGIS spatial types.

It is also important to distinguish between a spatial type and a geodatabase. The spatial type defines how geometry is stored in PostgreSQL. The geodatabase adds to the underlying database a set of system tables, stored procedures, functions, and metadata allowing the database to support GIS-specific behavior.

Prepare your environment

Before you install or upgrade PostgreSQL, validate compatibility across your ArcGIS stack:

Ensure that the PostgreSQL version used by your organization is supported by all the ArcGIS client versions you plan to use. This maintains optimal performance and workflow functionality.

• Check the What PostgreSQL database versions are supported by ArcGIS Enterprise and ArcGIS Pro? knowledge article.

Choose a PostgreSQL database version with long-term support to minimize the frequency of upgrades.

• Check the Release Schedule of Current PostgreSQL Database Releases article.

Ensure the database client is at a release that is compatible with the PostgreSQL version, to allow the ArcGIS client applications to communicate with your database.

For PostgreSQL, the client libraries (for example, libpq) are included with ArcGIS Pro and ArcGIS Server installations, so a separate local PostgreSQL client installation is typically not required. However, always verify version compatibility. Conflicts can still occur despite bundled client files; for example, because of library path issues (such as LD_LIBRARY_PATH on Linux) or manually replaced client DLL/SO files that cause ArcGIS to load an unintended libpq version. If a supported ArcGIS release is paired with an unsupported PostgreSQL major version (or vice versa), connection and geodatabase operation issues can occur.

• Check out the How to Install Database Clients for ArcGIS article for more information.

Configure PostgreSQL connectivity and authentication

Before ArcGIS connects, confirm the database is reachable and authentication is configured according to your organization’s security requirements. These parameters apply only to self-managed deployments.

• In postgresql.conf, set listen_addresses, which controls which network interfaces PostgreSQL listens on to “* ” for all interfaces, or specific hostnames/IPs for tighter control.
• Confirm the PostgreSQL port (default 5432, sometimes 5433 or another value in custom deployments) in postgresql.conf or with SHOW port.
• In pg_hba.conf, allow the required client hosts and authentication methods so ArcGIS clients can connect from expected machines/subnets.
• Ensure required login or group roles have CONNECT privileges on the target database.

While this is a standard PostgreSQL configuration task, it helps to ensure ArcGIS connects successfully to the database.

Considerations for memory and initialization parameters

You can create an enterprise geodatabase with default settings, but performance and maintenance improve quickly with a few targeted adjustments. These tuning considerations apply to both self-managed PostgreSQL and DBaaS deployments, although the exact limits you can configure may vary by cloud provider and service tier.

Consider the following starter-level tuning areas:

• shared_buffers
  • Start value: ~25% of total RAM
  • Upper bound: Avoid exceeding ~40% of RAM
  • Example: 32 GB RAM → shared_buffers = 8GB

Why this matters for geodatabases:

Shared_buffers helps cache frequently accessed tables and indexes, which is important for spatial queries and versioned access patterns. PostgreSQL also depends heavily on OS cache, so over-sizing shared_buffers often gives diminishing returns. If you increase shared_buffers, also review max_wal_size, since larger buffer settings typically require a higher WAL threshold to reduce checkpoint pressure and spread write activity over longer intervals.

• work_mem
  • Start value: 8 MB – 32 MB (typical starting range)
  • Scale up cautiously based on workload
  • Example baseline: work_mem = 16MB

The work_mem parameter is especially important in geodatabase workloads because it applies per sort/hash operation, not per connection. Branch versioning and spatial queries can involve large joins and sorting intermediate result sets. If work_mem is too small, operations spill to disk and slow down; if it is too large, concurrent queries can overconsume memory. If your workload includes many complex sorts and the server has sufficient memory, increasing work_mem allows larger in-memory sorts, which are typically much faster than disk-based sorts.

On the other side, maintenance_work_mem is separate and defines memory for maintenance operations such as VACUUM, CREATE INDEX, ALTER TABLE, and ADD FOREIGN KEY. The default is 64 MB, which is often conservative. Because a single session runs one maintenance operation at a time, and only a limited number of maintenance tasks usually run concurrently, maintenance_work_mem can often be set higher than work_mem to improve maintenance and restore performance.

• effective_cache_size
  • Conservative: ~50% of RAM
  • Typical production: 50%–75% of RAM
  • Example: effective_cache_size = 16GB  (conservative approach on a 32GB system)
    effective_cache_size = 24GB  (more aggressive approach)

The effective_cache_size parameter is a PostgreSQL planner hint, not a direct memory allocation. It should represent the memory likely available for caching, including both the OS page cache and PostgreSQL cache. In geodatabase workloads, a realistic value can improve plan selection and increase the likelihood of index-based plans, which is especially important for selective attribute and spatial queries.

A common conservative setting is about 50% of total system memory, while 75% is a more aggressive but still common production estimate. You can refine this value using operating system statistics. On Linux systems, combine relevant memory values reported by tools such as free or top; on Windows, review System Cache in Task Manager (Performance tab). Changing effective_cache_size does not require a database restart.

Bottom line

• shared_buffers: 25% RAM
• effective_cache_size: 50–75% RAM
• work_mem: start ~16MB and tune carefully

The values above are starting points, not universal rules for PostgreSQL backed geodatabases. Validate them with your own workloads and adjust based on monitoring (query performance, cache behavior, WAL activity, and maintenance windows) and not as a one-time “set-and-forget” change.

Create an enterprise geodatabase

Creating an enterprise geodatabase in PostgreSQL involves two related but separate concepts:

1. Provide PostgreSQL access to a supported spatial type.
2. Enable or create the geodatabase itself.

Spatial type requirements

Before you create the geodatabase, PostgreSQL must have access to a supported spatial type.

• ST_Geometry requirements

If you want to use ST_Geometry, download the ST_Geometry package from My Esri.

A few details matter here:

• The package is tied to the ArcGIS release from which you will create the geodatabase.
• The library file must also match your PostgreSQL version.
• You must choose the correct file for your operating system.
• As stated earlier, the ST_Geometry spatial type cannot be used on DBaaS deployments.

For example, if you are creating the geodatabase with ArcGIS Pro 3.7 and using PostgreSQL 17, download the ST_Geometry package for the ArcGIS Pro 3.7 release from My Esri and use the library file for PostgreSQL 17 and your operating system.

On Windows, place the st_geometry.dll file in the PostgreSQL lib directory, such as: C:\Program Files\PostgreSQL\<PostgreSQL version>\lib

Also note that the st_geometry.dll file requires the appropriate Microsoft Visual C++ Redistributable Package (x64) on the PostgreSQL server when running on a Windows server. If the required package is not installed, geodatabase creation can fail.

• PostGIS requirements

If you want to use PostGIS geometry or PostGIS geography, install a version of PostGIS that is supported by ArcGIS for your PostgreSQL deployment. Once PostGIS is installed, configure the database to use the PostGIS types according to PostGIS documentation. In practice, this usually means creating the database from a PostGIS-enabled template or enabling PostGIS in an existing database.

On DBaaS deployments, you may need to enable PostGIS as well. Consult the technical documentation for your cloud provider.

Create the geodatabase

ArcGIS provides two geoprocessing tools to create an enterprise geodatabase in PostgreSQL: Enable Enterprise Geodatabase and Create Enterprise Geodatabase.

The sde user is the geodatabase administrator in both workflows; what differs is how the database, sde login role, and sde schema are prepared.

The geodatabase administrator

In PostgreSQL, the geodatabase administrator must be named sde. ArcGIS uses this account to own the sde schema and geodatabase system objects.

Creating a geodatabase in a self-managed PostgreSQL deployment requires the sde user to have the superuser privileges. If the sde user does not need to terminate database connections that are locking data, that elevated privilege can be revisited after geodatabase creation, subject to your administrative and security requirements, but superuser status must be regranted to the sde user when it is time to upgrade the geodatabase.

Note: See the Privileges for geodatabases in PostgreSQL for the privileges required for your environment.

Geoprocessing tools to create a geodatabase in ArcGIS Pro

Note: Obtain the ArcGIS Server keycodes file and place it in a location accessible from the ArcGIS client machine you will use to enable or create the geodatabase.

This distinction is important: you do not always need to create the PostgreSQL database manually first. If you use the Create Enterprise Geodatabase tool, ArcGIS can create the database using PostgreSQL’s default template unless you choose to pre-create it.

If you need a different database template, or your administration model separates database administration from geodatabase administration, create the database first and then use the appropriate workflow.

If you create the database first

If you create the database yourself before enabling the geodatabase, you must make sure the following are in place:

• The database exists.
• A login role named sde exists.
• The sde user has the privileges required to create the geodatabase.
• A schema named sde exists in the database.
• The sde user has authority on the sde schema.
• PostgreSQL has access to a supported spatial type.
• The public schema exists.

What creating or enabling a geodatabase does

Whether you use the Enable Enterprise Geodatabase or Create Enterprise Geodatabase tool, ArcGIS creates the system objects required for geodatabase behavior.

These include geodatabase system tables, views, functions, and procedures, primarily in the sde schema. In PostgreSQL, one geodatabase system table is also created in the public schema, which is why the public schema must exist when enabling a geodatabase in an existing database.

Managed PostgreSQL service considerations

ArcGIS supports several cloud-based PostgreSQL database services. The overall concepts are the same, but the workflow is usually different from a fully self-managed PostgreSQL installation.

In DBaaS deployments, you typically:

• Provision the database service instance first.
• Configure it to accept connections from the ArcGIS clients.
• Create the sde user login. Only database-authenticated sde logins are supported in DBaaS offerings.
• Grant the sde user the privileges required for geodatabase creation. See Privileges for geodatabases in PostgreSQL for the specific privilege needed for the database service you use.
• Create the sde schema and grant the sde user authority on it.
• Install ArcGIS Pro or ArcGIS Server in the same cloud platform and region.
• Create a database connection as the sde user and save the password with the connection file.
• Use Enable Enterprise Geodatabase tool to create the geodatabase.

While the security concepts are similar, the exact administrative steps and assigned privileges depend on the cloud provider’s PostgreSQL offering.

Note: Follow the ArcGIS clients and DBMS upgrade considerations blog article which illustrates a common workflow example that many organizations use when upgrading their systems.

Connect to your geodatabase in ArcGIS Pro

Once the geodatabase exists, connect to it from ArcGIS Pro.

To create a database connection file in ArcGIS Pro:

1. Open the Catalog pane.
2. Right-click Databases or a folder under Folders, and click New Database Connection.
3. Choose PostgreSQL from the Database Platform list.
4. In Instance, provide the database cluster name, host name, or IP address.
5. Choose the authentication type.
6. Specify the database name.
7. Provide the connection file name.
8. If PostgreSQL uses a nondefault port, expand Additional Properties, choose Port, and enter the port number.
9. Click Validate.
10. Click OK.

Manage users and roles

After the geodatabase is created, create users and roles for the people in your organizations that will own, edit, or view data.

A best practice for geodatabases in PostgreSQL is to separate geodatabase administration from data ownership.

• The sde user administers the geodatabase.
• Business data should usually be owned by other users, not by sde.

ArcGIS tools can help with user creation in some workflows. For example, in a PostgreSQL environment you can use the Create Database User tool to create a database user who can create tables and feature classes. PostgreSQL roles can also be managed directly with database tools such as psql or pgAdmin.

If a read-only user is needed, you must create the user role using DBMS tools such as psql or pgAdmin. For example, you would type the following:

create-reader-role.sql

CREATE ROLE reader1 LOGIN
ENCRYPTED PASSWORD 'pw.4reader1'
NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION;
GRANT readers TO reader1;

Note: See the Privileges for geodatabases in PostgreSQL topic to learn more about privileges for geodatabases in PostgreSQL.

It is important to mention that ArcGIS expects lowercase object names when working with PostgreSQL. Database names, schema names, and other object names used for geodatabase setup should be lowercase only.

You can also use the Create Role geoprocessing tool to manage permissions across multiple users.

Create and manage datasets

Once your geodatabase and users are in place, you can create or add datasets to the enterprise geodatabase using the data owners you created earlier.

You can also register existing data with the geodatabase. Registering data with the geodatabase allows you to use several geodatabase capabilities such as:

• versioning
• topology
• attribute rules

As the data owner you can use the Change Privileges geoprocessing tool to revoke or grant database users read or write access to your datasets.

Final thoughts

Deploying an enterprise geodatabase in PostgreSQL starts with choosing the right supported versions and spatial type, ensuring connectivity and authentication align with your organization requirements, and then creating the geodatabase with an access model that matches your organization’s roles. Once it’s in place, PostgreSQL supports a clear, role-driven security approach, and ArcGIS tools help keep dataset permissions consistent as your geodatabase grows.

See the following additional resources:

• For an overview of enterprise geodatabases, watch the Enterprise Geodatabase: An Introduction technical workshop presented at the Esri User Conference 2025.

• To learn about tools that you can use to troubleshoot cases in your own organization watch the Enterprise Geodatabase: Performance Troubleshooting technical workshop presented at the Esri User Conference 2025.

• Follow the example workflow to upgrade ArcGIS clients and the database version in an organization in the ArcGIS clients and DBMS upgrade considerations blog article.
• If you want to understand how to best upgrade your geodatabase when using services, check out Manage geodatabase upgrades in a service-based architecture blog.
• If your enterprise geodatabase is backed by an Oracle database, the Deploy an enterprise geodatabase on Oracle blog is for you.

For additional resources on spatial data management check out the Geodatabase Resources Hub.