Compare Scenarios

Migration Step 1

Both scenarios define a migration step at this stage. Search-Heavy Content Platform: triggered by 'Search query p99 > 500ms on full-text queries; faceted navig'. 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. Search-Heavy Content Platform: triggered by 'Application write latency increasing due to Elasticsearch in'. 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. Search-Heavy Content Platform: triggered by 'High write throughput (> 10k documents/min) causing segment '. Geospatial Tracking Platform: triggered by 'PostgreSQL location_history table exceeding 100GB with query'.

Elasticsearch index CDC consumer lag > 10s; search results showing items that no longer exist or missing recently published items; CDC connector health dashboard showing processing rate below write rate

Tier 1: Index Freshness Degradation: CDC consumer or Elasticsearch bulk indexer not keeping pace with PostgreSQL write rate. Recommended evolution: Increase Elasticsearch bulk indexer thread count; tune bulk index batch size and flush interval; profile CDC connector bottleneck (network vs Elasticsearch write throughput vs mapping complexity) .

Elasticsearch JVM heap usage > 75% sustained; GC pause events visible in cluster logs; query p99 latency spikes during GC; cluster health showing yellow (unassigned shards during GC recovery)

Tier 2: Search Cluster Heap Pressure: Large aggregation queries or high document count per shard exceeding JVM heap budget. Recommended evolution: Increase Elasticsearch heap to 50% of node RAM (max 30GB for ZGC); reduce shard count to keep per-shard document count < 50M; disable dynamic mapping and explicitly define all field types; move to doc values for all non-analyzed fields .

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. .