What happens when a database pod goes down?
Kubernetes detects the failure and restarts the pod automatically — typically within seconds. Your app will experience a brief connection interruption during the restart. We recommend configuring your application's database connection pool with retry logic (most frameworks do this by default).
Do database addons have high availability or automatic failover?
PostgreSQL, Redis, and Elasticsearch addons each run as a single pod. There is no hot standby or automatic promotion to a replica. If the pod is killed or the node it runs on fails, Kubernetes restarts it automatically — typically within seconds — and the data on the EBS volume is preserved.
If you need zero-downtime database failover, the right answer today is to use a managed database service (RDS, ElastiCache, Elastic Cloud) and point your app at it via a DATABASE_URL environment variable. neetoDeploy manages your application; it does not prevent you from using external managed databases alongside it.
What backup strategy is in place for PostgreSQL?
Three independent layers:
- SQL dumps — a full database dump is exported to S3 every 30 minutes, plus a daily snapshot at midnight. These are what the automated restore tester validates daily.
- Continuous WAL archiving via pgBackRest — PostgreSQL Write-Ahead Logs are continuously shipped to S3, enabling point-in-time recovery (PITR) to any moment within the retention window.
- EBS snapshots — daily disk-level snapshots of all database PVCs (via Velero), retained for 30 days.
What about Redis and Elasticsearch backups?
Redis and Elasticsearch addons are backed up via scheduled exports to S3.
Are database backups actually tested?
Yes. An automated script runs daily and:
- Downloads a random SQL dump from S3
- Restores it into a temporary local PostgreSQL database
- Verifies the restored schema (table count check)
- Checks that the most recent backup is no older than 25 hours
The test results are tracked in GitHub. If either check fails, the Deploy team is alerted.