Query volume against Meridian Line's bill-of-lading Vector Search index has grown tenfold since launch, and terminal planners now report slow search responses during peak intake hours. The index's sync mode and embedding model are unchanged. What is the appropriate first lever to address the slowdown?

A Vector Search endpoint has provisioned compute capacity that serves query traffic for the indexes attached to it, and query throughput/latency under load is governed substantially by that capacity — a tenfold volume increase against unchanged endpoint sizing is a textbook case of the endpoint becoming the bottleneck, and scaling it up is the direct fix that doesn't require touching the index's sync mode, embedding model, or document set at all. Switching from Delta Sync to Direct Vector Access changes how the index is updated (change-feed-driven vs. direct API upserts), not how fast it answers queries under load — there's no basis for Direct Vector Access being inherently faster to query, and this doesn't address the described compute bottleneck. There's no fixed document-count ceiling that forces deletion of older records to keep an index servable, and even if capacity were genuinely constrained, deleting historical bills of lading destroys retrievable content the charter-desk and compliance use cases may still need — a real fix wouldn't start there. Changing the embedding model's dimensionality could plausibly shift compute cost per query at the margin, but claiming it is 'the only way to reduce latency under any circumstances' overstates a minor lever into an absolute, when endpoint capacity is the direct and appropriate first lever for a load-driven slowdown. Exam framing: this is the sizing/provisioning half of 'create and configure Vector Search endpoints and indexes,' distinct from the sync-mode and CDF questions already covered.