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) customerPOST /api/v1/route/outcomerollups — 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.