Qyra requires a PostgreSQL database, version 12 or greater. In production, we recommend using a managed database service (depending on your cloud provider). This ensures that your database is highly available and secure. You can also use a self-hosted database, but you will need to manage the database yourself.

The following configuration shows an example of how to configure Qyra to use an external database. You can use this as a starting point for your own configuration.

Configuration options for external database

# values.yaml

# Disable the internal database
postgresql:
  enabled: false

# Configure Qyra to use an external database
externalDatabase:
  host: qyra-db.mycompany.com
  port: 5432
  user: qyra
  password: qyra
  database: qyra

Optionally you can pass any of the PostgreSQL Environment Variables to the configMap

Required pg extensions for external database

Qyra requires the following extensions to be installed on the database:

• uuid-ossp — used for generating unique IDs
• pgvector — required for Enterprise AI features (AI Analyst embeddings and verified answers). On managed services such as AWS RDS, Google Cloud SQL, and Azure Database for PostgreSQL, enable the vector extension in the instance's configuration first, then run CREATE EXTENSION IF NOT EXISTS vector; in the Qyra database.

Running Postgres in production

Beyond the connection settings above, this is what to run on the database side to match Qyra Cloud:

• Managed Postgres (Cloud SQL / RDS / Azure Database) — version 14+ recommended (12 is the documented minimum).
• High availability: a regional / multi-AZ primary, with a cross-region replica for disaster recovery.
• Backups: daily automated backups with point-in-time recovery enabled, ≥ 7 days of transaction logs, and 7–31 retained backups.
• SSD storage with auto-resize.
• Sizing: 2 vCPU / 8 GB RAM is a solid single-org baseline; 4 vCPU / 16 GB+ for large orgs or heavy scheduler usage.
• Connection budget: every backend and worker pod opens its own pool. Set PGMAXCONNECTIONS: "50" and PGMINCONNECTIONS: "0" in configMap, then make sure Postgres max_connections covers pods × PGMAXCONNECTIONS with headroom.
• Query insights / slow-query logging enabled on the database side.
• TLS to the database via the chart's ssl block, which injects PGSSLMODE=verify-full and NODE_EXTRA_CA_CERTS:

ssl:
  enabled: true
  configMapName: qyra-db-ca   # your CA cert
  certFileName: ca.pem

Migrations

Migrations run automatically when the Qyra server or workers start, including on upgrade. Do not clear the knex_migrations_lock table by hand on 1.123.0 and later — use migrate status to inspect a stuck migration and migrate unlock --actor to release its lease. For multi-replica deployments, enable the migration job so replicas don't race. Both are covered in the upgrade runbook.