Compare Scenarios

Migration Step 1

Both scenarios define a migration step at this stage. Multi-Tenant SaaS Platform: triggered by 'Adding a second paying customer; first audit or security rev'. Geospatial Tracking Platform: triggered by 'PostGIS proximity query p99 > 100ms under concurrent fleet t'.

Migration Step 2

Both scenarios define a migration step at this stage. Multi-Tenant SaaS Platform: triggered by 'Database read load growing disproportionately with tenant co'. Geospatial Tracking Platform: triggered by 'Location update API p99 > 200ms correlated with geofence cou'.

Migration Step 3

Both scenarios define a migration step at this stage. Multi-Tenant SaaS Platform: triggered by 'Enterprise customer requesting dedicated infrastructure in c'. Geospatial Tracking Platform: triggered by 'PostgreSQL location_history table exceeding 100GB with query'.

PgBouncer pool wait queue > 0 during peak hours; application errors reporting "connection pool exhausted" or pool timeout; pool utilization > 90%

Tier 1: Connection Pool Exhaustion: Aggregate tenant connection demand exceeding PgBouncer pool_size. Recommended evolution: Implement per-tenant connection quotas at the application layer before hitting the pool; increase pool_size incrementally; identify top-N connection consumers by tenant and implement connection reuse within tenant request handlers .

pg_stat_activity shows one tenant's queries dominating query runtime; other tenants reporting p99 latency regression while their own query counts are stable; PostgreSQL shared_buffers cache eviction rate increasing

Tier 2: Noisy Tenant I/O Saturation: Single large tenant displacing other tenants' working sets from shared buffer cache. Recommended evolution: Implement pg_cgroups or connection-level resource groups if available; consider database-per-tenant for the top N largest tenants while keeping the shared schema for smaller tenants (hybrid isolation model) .

Redis used_memory > 75% of maxmemory; Redis evictions appearing in INFO stats; GEOSEARCH returning stale or missing entity positions; Redis OOM errors in application logs during fleet expansion events; proximity query latency increasing above 10ms baseline

Tier 1: Redis Geospatial Memory Pressure: Redis memory exhausted by unbounded geospatial entity growth without entity expiry or cleanup. Recommended evolution: Implement entity-scoped Redis key TTL tied to the last received update timestamp. Entities that have not sent a position update in > 5 minutes are expired from Redis automatically (Redis EXPIRE on the ZSET entry using a per-entity auxiliary key pattern, since ZSET members do not support per-member TTL natively). Alternatively, introduce a background reconciliation job that removes entities from the live position surface after an inactivity threshold. Shard the geospatial index across multiple Redis instances by geographic region using consistent hashing on the region key. .

TimescaleDB write p99 > 50ms; WAL volume > 200MB/minute sustained; disk I/O utilization > 80% on TimescaleDB data volume; chunk creation log entries during fleet expansion events correlated with write latency spikes; TimescaleDB worker queue depth growing during ingestion bursts

Tier 2: TimescaleDB Write Throughput Ceiling: TimescaleDB hypertable chunk write throughput saturated by high-frequency location update volume; chunk creation DDL causing write stalls during expansion. Recommended evolution: Tune TimescaleDB chunk_time_interval to match the ingestion rate: smaller chunks (1-hour intervals instead of 1-day) reduce per-chunk write volume but increase chunk creation frequency. Use timescaledb-parallel-copy for bulk historical ingestion. Move the TimescaleDB WAL to a dedicated NVMe volume. Introduce write batching at the application layer: buffer 500ms of position updates per entity and write as a single multi-row INSERT, reducing the per-update overhead from N single-row INSERTs to N/batch_size batch INSERTs. .