Skip to main content
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. 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. 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:
Verify on each database:
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, for password auth, postgresPassword in values.yaml). The install job uses this user to create databases and the runtime roles that Arize AX services use. A true Postgres superuser is not required and is usually unavailable on managed services. Set postgresUsername to a login user that is a member of the provider admin role:
  • AWS RDS: member of rds_superuser
  • Google Cloud SQL: member of cloudsqlsuperuser (the built-in postgres user is typical)
  • Azure Database for PostgreSQL Flexible Server: member of azure_pg_admin
  • IBM Cloud Databases: the instance admin login user
The admin user must be able to:
  • CREATE DATABASE (for postgresdb and druid, if not pre-created)
  • CREATE ROLE (runtime roles for Arize AX services)
  • CREATE EXTENSION for uuid-ossp and pg_stat_statements
  • ALTER DATABASE ... SET to set DateStyle
  • GRANT on the public schema of both databases
Arize AX creates and manages all runtime database roles. Those roles do not need to be pre-created. In password mode Arize AX services do not connect as the admin user at runtime. In rds_iam mode services authenticate as those runtime roles with IAM tokens. In cloudsql_iam mode services authenticate as postgresUsername (the Cloud SQL IAM DB user) and then SET ROLE to the runtime role. Set the following fields in values.yaml to use an external Postgres instance instead of the default in-cluster StatefulSet. values.yaml (password):
AWS RDS IAM (postgresAuthMode: rds_iam): enabling IAM authentication on RDS does not GRANT rds_iam to the master user. Keep postgresPassword set to that master password (base64) for the first install (and for a password-to-IAM cutover). The install job uses it once to grant rds_iam to the admin user, then switches to IAM tokens. After install succeeds, remove postgresPassword from values.yaml and re-apply. Later IAM upgrades do not need the password. If you omit it on first install, grant rds_iam to the admin user yourself before Arize can connect. Also set postgresSslEnable: true, postgresRegion, and awsServiceAccountRoleRwBucket to the existing IRSA role. That role needs rds-db:connect on arn:aws:rds-db:<region>:<account>:dbuser:<DbiResourceId>/* (wildcard) or per-username ARNs — these are not new IAM role ARNs. See Advanced → Postgres IAM auth. Cloud SQL IAM (GCP, no Auth Proxy): enable IAM database authentication on the instance, create a Cloud SQL IAM database user for the Workload Identity service account (username is the SA email without .gserviceaccount.com), and grant that principal cloudsql.instances.login (roles/cloudsql.instanceUser). Set postgresAuthMode: cloudsql_iam, postgresSslEnable: true, and supply postgresSslRootCert (the base64 server CA PEM). Only set postgresSslClientCert / postgresSslClientKey (base64 PEMs, both or neither) if the instance is configured to require trusted client certificates. Do not set postgresPassword. See the internal guide distribution/docs/internal/advanced/postgres-iam-auth.md for rotation (certs are re-read on new connections; rolling restart is the reliable yearly procedure). For the rest of values.yaml, follow the installation guide for the target environment: Installation on AWS, Installation on GCP, Installation on Azure, Installation on IBM Cloud, or Installation on OpenShift. Choose an approach based on the deployment. For helm:
For the complete installation walkthrough, see Installation for your platform. Note: initMode: restore_from_replica is not supported with external Postgres. For external Postgres (including Cloud SQL), you can rebuild the cluster from in-cluster backup files in object storage using initMode: restore_from_cloud with postgresAuthMode: password or cloudsql_iam; postgresdb / druid must have no tables in the public schema first (same rule as the restore job). See Advanced → Postgres IAM auth (restore section) or use your Postgres provider’s native backup/restore for provider-managed DR.