Reference

Routing benchmarks (illustrative)

This page is not a performance guarantee. It describes a canonical evaluation task Amply uses for comparability across listings (catalog + probes), and how to read estimated_cost_usd and compute_ms without over-claiming.

Canonical vector workload (reference)

A typical probe-aligned task shape (also used in smoke tests) is: ~100k embeddings, 1536 dimensions, hybrid read/write, medium-to-high metadata filters. Your real workload should set explicit dimension, workload_type, and filter_complexity on POST /api/v1/route so quotes match intent.

{
  "task": "store 100k 1536-dim vectors with metadata filters and similarity search",
  "dimension": 1536,
  "workload_type": "hybrid",
  "filter_complexity": "high"
}

What Amply measures vs what it does not

  • Measured: Amply handler compute_ms, synthetic probe history, route telemetry aggregates, and (when enabled) customer POST /api/v1/route/outcome rollups — see catalog methodology.
  • Not measured by Amply: Your application's end-to-end wall time inside the vendor SDK, cold partitions, or model fine-tuning cost. Those remain your benchmarks.

“Faster / cheaper than build” — safe interpretation

A defensible claim is directional: for commodity vector retrieval, managed listings often beat a from-scratch control plane once you include reliability work, upgrades, and on-call — but the exact multiplier depends on team size, traffic shape, and reserved capacity. Use Amply's estimated_cost_usd and catalog latency fields as decision inputs, not as proof of savings until you validate against your own baseline.

Back to API docs