Time-series data: TimescaleDB or InfluxDB?
100M rows a day breaks a plain table, so chunk it by time with hypertables, materialize the averages as continuous aggregates, and compress the old chunks.
Tag
Growing under load: horizontal and vertical scaling, autoscaling and hunting bottlenecks.
6 answered questions carry this tag.
100M rows a day breaks a plain table, so chunk it by time with hypertables, materialize the averages as continuous aggregates, and compress the old chunks.
Stand up monthly RANGE declarative partitioning on `created_at`, backfill history in batches while the app writes, then swap names in a single transaction.
Split the critical path (browse, cart, checkout) from the nice-to-haves, put those behind feature flags with short timeouts, and rehearse the kill-switch.
On SIGTERM drain the load balancer first, finish in-flight work inside the server.Shutdown(ctx) deadline, then align the grace period with that drain.
Database-per-tenant does not scale operationally at 10k; keep tenant_id on every table and bury isolation in Postgres Row-Level Security instead.
Don't make EFS the interim step; switch to a Flysystem s3 disk, route reads and writes via Storage::disk(), and migrate with dual-read for zero downtime.