> ## Documentation Index
> Fetch the complete documentation index at: https://arize-ax.mintlify.site/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# External Postgres Requirements

> Postgres version, sizing, parameters, and permissions for self-hosted deployments using an external database.

This section describes requirements for using a managed or external Postgres instance (for example AWS RDS, Google Cloud SQL, or Azure Database for PostgreSQL Flexible Server) instead of the default in-cluster Postgres StatefulSet. The following requirements apply before installation.

**Postgres version**

* Postgres **17.x**, with **17.6 or later recommended**.

**Resource sizing**

These are the baseline requirements for a standard Arize AX deployment. Scale up as your workload and connection count grow.

| Resource     | Recommended                  |
| ------------ | ---------------------------- |
| Storage type | Block storage (e.g. AWS gp2) |
| Storage size | 50 GB                        |
| Memory       | 6 GiB                        |
| CPU          | 3 vCPU                       |

**Postgres parameters**

Configure the Postgres instance with the following parameters. For every row except `max_connections`, the value matches the bundled Arize AX Postgres 17 server configuration (`postgres.conf`) and the default database flags for Arize AX self hosted deployments.

| Parameter                  | Value   |
| -------------------------- | ------- |
| `max_connections`          | `600`   |
| `log_timezone`             | `UTC`   |
| `timezone`                 | `UTC`   |
| `track_io_timing`          | `on`    |
| `pg_stat_statements.max`   | `10000` |
| `pg_stat_statements.track` | `all`   |

**`max_connections`:** On-prem Terraform defaults use **`600`**. The in-cluster Arize AX Postgres 17 image ships **`max_connections = 900`** in `postgres.conf`. For external Postgres, **`600` is the documented baseline**; raise it if your expected client count requires more headroom.

**Databases**

* Arize AX uses two databases: `postgresdb` (application data) and `druid`. The Arize AX install job will create both databases if they do not already exist. You may also pre-create them.

**DateStyle**

Both databases must use the `ISO, MDY` DateStyle. The Arize AX install job applies the necessary `ALTER DATABASE` statements when the admin user can run them. Setting `DateStyle` explicitly is required — some managed Postgres providers default to `ISO, DMY`, which causes date parsing errors in Arize AX.

To set `DateStyle` manually, use:

```sql theme={null}
ALTER DATABASE postgresdb SET DateStyle = 'ISO, MDY';
ALTER DATABASE druid SET DateStyle = 'ISO, MDY';
```

Verify on each database:

```sql theme={null}
postgresdb=# SHOW DateStyle;
 DateStyle
-----------
 ISO, MDY
(1 row)
```

**Extensions**

The install job runs `CREATE EXTENSION IF NOT EXISTS` against `postgresdb` for:

* `uuid-ossp`

* `pg_stat_statements`

Both are part of the standard `contrib` package and are available on AWS RDS, Google Cloud SQL, and Azure Database for PostgreSQL.

**Admin user and permissions**

Provide Arize AX with a single admin-level Postgres user (via `postgresUsername` and `postgresPassword` in `values.yaml`). The install job uses this user to bootstrap the databases and create the fine-grained runtime roles that Arize AX services use.

The admin user must be able to:

* `CREATE DATABASE` (for `postgresdb` and `druid`, if not pre-created)

* `CREATE ROLE` (the install job creates roles used by Arize AX services, including `migrations`, `app_server`, `druid`, `auth`, and others)

* `CREATE EXTENSION` for `uuid-ossp` and `pg_stat_statements`

* `ALTER DATABASE ... SET` to set `DateStyle`

* `GRANT` on the `public` schema of both databases

On managed Postgres this maps to the provider's equivalent admin role: `rds_superuser` on AWS RDS, the `cloudsqlsuperuser` role on Google Cloud SQL, or membership in `azure_pg_admin` on Azure Database for PostgreSQL Flexible Server.

The runtime roles created by the install job are managed entirely by Arize AX. You do not need to pre-create them, and the admin user is not used by Arize AX services at runtime.

Set the following fields in `values.yaml` to use an external Postgres instance instead of the default in-cluster StatefulSet.

**values.yaml:**

```yaml theme={null}
postgresHostEndpoint: "<postgres host or FQDN>"
postgresPort: 5432
postgresUsername: "<admin user>"
postgresPassword: "<external postgres admin password>" (base64 encoded)
postgresSslEnable: true
```

For the rest of `values.yaml`, follow the installation guide for your environment: [Installation on AWS](/ax/selfhosting/installation/installation-on-aws), [Installation on GCP](/ax/selfhosting/installation/installation-on-gcp), [Installation on Azure](/ax/selfhosting/installation/installation-on-azure), or [Installation on OpenShift](/ax/selfhosting/installation/installation-on-openshift).

Choose an approach based on the deployment. For helm:

```bash theme={null}
helm upgrade --install -f values.yaml arize-op arize-operator-chart.tgz
```

For the complete installation walkthrough, consult **Advanced → Helm** in the documentation included with your distribution.

**Note:** Restoring from a cloud snapshot or from a Postgres replica is not supported when using an external Postgres database. Use your Postgres provider's native backup and restore tooling instead.