Skip to main content

Backup Strategies

Full Backend Backup

For deployments using Pixeltable as the full backend:

Batch Processing Backup

For batch processing deployments:
  • Primary data lives in your external RDBMS and blob storage
  • Pixeltable state can be rebuilt by re-running transformation pipelines
  • Back up your schema.py and UDF code in version control

Recovery Procedures

Full Backend Recovery

  1. Stop the Pixeltable application
  2. Restore PostgreSQL data: psql -f backup.sql
  3. Restore media files to ~/.pixeltable/media/
  4. Restart the application

Batch Processing Recovery

  1. Deploy fresh Pixeltable instance
  2. Run python schema.py to recreate schema (idempotent with if_exists='ignore')
  3. Re-process data through computed columns (incremental)

Security Best Practices

Network Security

Secrets Management

Never hardcode secrets. Use environment variables or secrets managers:
For production, use:
  • AWS: Secrets Manager, Parameter Store
  • GCP: Secret Manager
  • Kubernetes: Secrets, External Secrets Operator

Cloud Storage Credentials

For S3/GCS/Azure media storage:

Audit and Compliance

Data Lineage

Pixeltable automatically tracks:
  • Table versions and schema changes
  • Computed column definitions and dependencies
  • Insert/update/delete operations

Access Logging

Implement application-level access logging:

Disaster Recovery

Recovery Time Objectives

Recommendations

  1. Regular backups: Daily for production workloads
  2. Test recovery: Quarterly disaster recovery drills
  3. Multi-region: Store backups in different region than primary
  4. Immutable backups: Use S3 Object Lock or GCS retention policies
Last modified on June 24, 2026