clear references

tasks/web-production/06-db-connection-pooling.md

@@ -5,7 +5,7 @@ meta:
   feature: web-production
   priority: P1
   depends_on: []
-  tags: [performance, database, production]
+  tags: [performance, database, production, turso, sqlite]
 
 objective:
 - Optimize database connections and queries for production load
@@ -17,10 +17,10 @@ deliverables:
 - Slow query logging
 
 steps:
-1. Configure connection pooling:
-   - If using PostgreSQL: configure PgBouncer or use @libsql/client pooling
-   - Set max connections based on server instances (e.g., 20 per instance)
-   - Add connection timeout and idle timeout settings
+1. Configure connection handling:
+   - Turso/libsql handles connection management internally — no external pool needed
+   - Configure `@libsql/client` with appropriate timeout settings
+   - Leverage Turso's edge distribution for low-latency reads
 2. Audit all Drizzle queries for performance:
    - Check web/src/server/db/schema/*.ts for missing indexes
    - Review web/src/server/api/routers/*.ts for N+1 queries
@@ -58,5 +58,6 @@ validation:
 
 notes:
 - Current schema has some indexes but may need more for production scale
-- Drizzle ORM doesn't automatically handle connection pooling — configure at driver level
-- Consider read replicas if dashboard load is heavy
+- Turso/libsql handles connection management internally — no PgBouncer or connection pool needed
+- Turso provides edge read replicas automatically — configure primary for writes, edges for reads
+- SQLite has different query patterns than PostgreSQL — avoid heavy JOINs on large tables, prefer indexed lookups

tasks/web-production/15-docker-infra.md

@@ -30,7 +30,7 @@ steps:
 3. Create docker-compose.prod.yml:
    - Web app service with replicas
    - Redis service with persistence
-   - PostgreSQL service (or external)
+   - Database is external (Turso) — no container needed
    - Nginx reverse proxy with SSL termination
    - Watchtower for automatic updates
 4. Add security scanning:
@@ -42,7 +42,7 @@ steps:
    - VPC, subnets, security groups
    - ECS/Fargate or Kubernetes deployment
    - Load balancer with SSL
-   - RDS/Cloud SQL for PostgreSQL
+   - Turso database (managed — no IaaS needed, configure via environment variables)
    - ElastiCache/Memorystore for Redis
 6. Add environment-specific configs:
    - Production nginx.conf with rate limiting
@@ -73,3 +73,4 @@ notes:
 - Current scheduler/Dockerfile copies many source files — optimize with .dockerignore
 - Consider using distroless images for even smaller footprint
 - Use AWS Fargate or Google Cloud Run for serverless containers
+- Turso is fully managed — no database container or IaaS needed, just `DATABASE_URL` and `DATABASE_AUTH_TOKEN`

tasks/web-production/31-db-backup.md

@@ -5,10 +5,10 @@ meta:
   feature: web-production
   priority: P1
   depends_on: []
-  tags: [database, reliability, production]
+  tags: [database, reliability, production, turso, sqlite]
 
 objective:
-- Implement automated database backups with point-in-time recovery capability
+- Implement automated database backups with point-in-time recovery capability using Turso's built-in backup features
 
 deliverables:
 - Automated daily backups
@@ -18,24 +18,24 @@ deliverables:
 
 steps:
 1. Set up automated backups:
-   - If PostgreSQL: configure pg_dump cron job or managed backups (RDS, Cloud SQL)
-   - If SQLite/Turso: configure Turso database branching/backups
+   - Configure Turso database backups using the Turso CLI (`turso db backup`)
+   - Use Turso's branching feature for safe schema changes and rollbacks
    - Daily full backups at off-peak hours (3 AM UTC)
-   - Hourly incremental backups (WAL archiving for Postgres)
+   - Leverage Turso's built-in replication for high availability
 2. Configure backup storage:
-   - Store in separate region/cloud provider (S3, GCS, R2)
+   - Store backups in separate region/cloud provider (S3, GCS, R2)
    - Encrypt backups at rest
    - Versioning enabled (protect against deletion)
 3. Implement point-in-time recovery:
-   - WAL archiving for PostgreSQL
-   - Transaction log backups every 15 minutes
-   - Test recovery to specific timestamp
+   - Use Turso branches to test migrations before applying to main
+   - Schedule regular backups to external storage
+   - Test recovery to specific backup point
 4. Add backup monitoring:
    - Alert on backup failure
    - Track backup size and duration
    - Verify backup integrity (checksum)
 5. Test restore procedures:
-   - Monthly restore test to staging environment
+   - Monthly restore test to staging environment using `turso db restore`
    - Document step-by-step restore process
    - Measure RTO (Recovery Time Objective) and RPO (Recovery Point Objective)
    - Target: RTO < 1 hour, RPO < 15 minutes
@@ -55,7 +55,7 @@ tests:
 - Monitoring: Verify backup alerts
 
 acceptance_criteria:
-- Daily automated backups running successfully
+- Daily automated Turso backups running successfully
 - Backups stored in separate region with encryption
 - Point-in-time recovery tested and working
 - Backup failures trigger alerts within 5 minutes
@@ -63,6 +63,7 @@ acceptance_criteria:
 - RTO < 1 hour, RPO < 15 minutes
 - Retention policy enforced automatically
 - Redis backups included in strategy
+- Turso branching workflow documented for safe schema changes
 
 validation:
 - Check backup storage → daily backups present
@@ -71,7 +72,8 @@ validation:
 - Check retention → old backups purged per policy
 
 notes:
-- Turso offers automatic backups for SQLite — verify configuration
-- RDS automated backups are easiest for PostgreSQL
+- Turso offers automatic backups and branching for SQLite — leverage both
+- Use `turso db backup <database> <file>` for manual backups
+- Use `turso branch create <name>` to create safe testing environments
 - Test restores are critical — untested backups are useless
 - Document restore process for on-call engineers