All presets
Pass any of these strings as the second argument to withLatency or withLatencyAll. Values are in milliseconds. Error rate is the fraction of calls that reject with a transient error.
Presets are starting points. If your production metrics differ, use a custom profile: withLatency(fn, { p50: 6, p99: 400, errorRate: 0.002 }).
Database presets
postgres
Models a Postgres database on the same network segment as the application — typical of a managed RDS or Cloud SQL instance in the same availability zone. The p50 of 5ms reflects a warm connection pool serving a simple indexed query. The p99 of 200ms accounts for lock contention, autovacuum interference, and occasional plan cache invalidation. The 0.1% error rate models brief connection drops during failovers or connection pool exhaustion under burst load.
mysql
Similar to Postgres but slightly faster at the median (4ms vs 5ms) and lower tail (180ms vs 200ms), reflecting MySQL's historically faster simple query path. The error rate is identical at 0.1%. Use this for any MySQL-compatible database including MariaDB and PlanetScale.
redis
Models an in-process or same-datacenter Redis instance. Redis is memory-resident and single-threaded for command processing, making it extremely fast: 1ms median, 20ms at p99. The very low p99 means timeouts are rare, but the 0.05% error rate accounts for connection pool exhaustion and brief unavailability during replica promotion. Use this preset for Elasticache, Upstash, or any Redis-compatible store.
mongodb
Models a MongoDB Atlas cluster or self-hosted replica set. MongoDB's document-oriented access pattern and BSON serialization add a bit more overhead than SQL databases, reflected in the higher p50 (8ms) and p99 (250ms). The longer tail accounts for collection scans on under-indexed queries and replica sync lag during writes.
dynamodb
Models AWS DynamoDB with provisioned or on-demand capacity in the same region. DynamoDB is an SSD-backed distributed key-value store with consistent single-digit millisecond latency for single-item operations — p50 of 3ms and p99 of 50ms. The low error rate (0.05%) reflects DynamoDB's high availability design, though throttling during burst traffic can cause transient failures not captured by this simple model.
Storage presets
s3
Models AWS S3 (or any S3-compatible object store like GCS, Cloudflare R2, or MinIO) for small to medium object operations. S3 has higher baseline latency than databases because of the HTTP overhead, distributed consistency model, and geographic variance. The p50 of 30ms is typical for a GetObject in the same region. The p99 of 500ms accounts for large objects, cold prefixes, high request rates hitting rate limits, and cross-region access. The 0.1% error rate models 503 SlowDown responses and transient network issues.
API presets
stripe
Models the Stripe API for payment operations like charge creation, customer lookups, and refunds. Stripe's infrastructure is highly reliable but involves significant server-side processing for payment operations — fraud scoring, network authorization, compliance checks. The p50 of 200ms is typical for a charge.create call. The p99 of 2000ms reflects occasional processing delays. The 0.2% error rate is higher than database presets because Stripe returns transient errors (rate limits, connection timeouts) that your retry logic must handle.
openai
Models the OpenAI Chat Completions API for medium-length requests. LLM inference is computationally expensive and has high variance: the p50 of 800ms is for short completions, while the p99 of 8000ms reflects longer generations, high load periods, and cold model loading. The 0.5% error rate accounts for rate limiting (429s), server overload (503s), and connection timeouts that are common when OpenAI is under heavy traffic. This preset is particularly useful for testing timeout and retry logic around LLM calls.
anthropic
Models the Anthropic Messages API. Slightly faster than OpenAI at the median (600ms vs 800ms) with a similar tail (7000ms vs 8000ms at p99) and the same 0.5% error rate. Both LLM presets share the characteristic that the "typical" case is already quite slow compared to database or cache operations, which means timeouts need to be set much higher — usually 10–30 seconds rather than 1–2 seconds.
http
A generic HTTP API preset for services not covered by a specific preset. The p50 of 80ms and p99 of 1000ms represent a well-operated but not exceptional external API — typical of third-party webhooks, geocoding services, email providers, or internal microservices over the network. The 1% error rate is the highest of all presets, reflecting the reality that generic HTTP services tend to have less strict SLAs than specialized infrastructure like Redis or DynamoDB.
When to use a custom profile
Use a preset when you're getting started or when you don't have production data. Switch to a custom profile when:
- Your production APM (Datadog, New Relic, Honeycomb) shows p50/p99 values that differ materially from the preset.
- You're modeling a service that doesn't fit any preset — e.g., a gRPC microservice, a message broker, or an in-house API.
- You want to test a degraded scenario — e.g., what happens when your database's p99 climbs to 2000ms during peak load?
- You need a specific error rate different from the preset defaults.
// Custom profile — your actual production p50/p99 const slowQuery = withLatency(query, { p50: 6, // your measured median p99: 450, // your measured 99th percentile errorRate: 0.003 // observed transient error rate })