Context
Follow-up improvements for the response store backends (SQLite, PostgreSQL) added in praxis-proxy/praxis#491, praxis-proxy/praxis#492, #4. These are not needed today but worth tracking for production deployments at scale.
Potential Improvements
Write performance tuning
Expose connection pool tuning options (e.g., max_connections, idle_timeout) in the store config. If write throughput becomes a bottleneck under high request volume, consider a bounded write queue with configurable worker count (num_writers, max_write_queue_size) to batch and buffer upserts. This would require backpressure policy decisions (drop vs. block) and graceful drain on shutdown.
Data compression
Large response_object, input, and messages JSON columns can be significant in size. Consider optional compression (e.g., zstd) before storage to reduce disk usage and I/O. Trade-off: CPU cost on read/write vs. storage savings. Could be a per-backend config option (compression: zstd).
TTL / data expiration
Add configurable time-to-live for stored records so stale conversation history and responses are automatically purged. Options:
- Database-level: PostgreSQL
pg_cron or scheduled DELETE WHERE created_at < now() - interval, SQLite trigger or application-side sweep
- Application-level: a background reaper task with configurable
ttl (e.g., ttl: 7d)
This prevents unbounded storage growth in long-running deployments.
Parent
Part of #93.
Context
Follow-up improvements for the response store backends (SQLite, PostgreSQL) added in praxis-proxy/praxis#491, praxis-proxy/praxis#492, #4. These are not needed today but worth tracking for production deployments at scale.
Potential Improvements
Write performance tuning
Expose connection pool tuning options (e.g.,
max_connections,idle_timeout) in the store config. If write throughput becomes a bottleneck under high request volume, consider a bounded write queue with configurable worker count (num_writers,max_write_queue_size) to batch and buffer upserts. This would require backpressure policy decisions (drop vs. block) and graceful drain on shutdown.Data compression
Large
response_object,input, andmessagesJSON columns can be significant in size. Consider optional compression (e.g., zstd) before storage to reduce disk usage and I/O. Trade-off: CPU cost on read/write vs. storage savings. Could be a per-backend config option (compression: zstd).TTL / data expiration
Add configurable time-to-live for stored records so stale conversation history and responses are automatically purged. Options:
pg_cronor scheduledDELETE WHERE created_at < now() - interval, SQLite trigger or application-side sweepttl(e.g.,ttl: 7d)This prevents unbounded storage growth in long-running deployments.
Parent
Part of #93.