🛠 This page is for engineering teams self-hosting their own Lightdash instance. If you want to connect your data warehouse, go to the Connect a project guide.
Lightdash requires a PostgreSQL database (version 12 or greater).
Configuration options for external database
configMap
Required pg extensions for external database
Lightdash requires the following extensions to be installed on the database:uuid-ossp— used for generating unique IDspgvector— required for Enterprise AI features (AI Analyst embeddings and verified answers)
Running Postgres in production
Beyond the connection settings above, this is what to run on the database side to match Lightdash 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"andPGMINCONNECTIONS: "0"inconfigMap, then make sure Postgresmax_connectionscoverspods × PGMAXCONNECTIONSwith headroom. - Query insights / slow-query logging enabled on the database side.
- TLS to the database via the chart’s
sslblock, which injectsPGSSLMODE=verify-fullandNODE_EXTRA_CA_CERTS:
Migrations
Migrations run automatically when the Lightdash server or workers start, including on upgrade. If a migration fails with apg_lock error, the lock lives in the knex_migrations_lock table — release it there before retrying. For multi-replica deployments, enable the migration job so replicas don’t race; see Upgrading Lightdash.