SLA (Service Level Agreement)

A unique and critical SLA for approximate nearest neighbor (ANN) search in vector databases. It guarantees the accuracy of search results.

• Definition: Recall measures the fraction of true nearest neighbors (found by an exact, brute-force search) that are returned by the database's approximate index. A recall of 0.99 means 99% of the true top-K neighbors are in the result set.
• SLA Structure: "For a query with topK=10, the system guarantees a recall of >= 0.95 when searching an index of 10 million vectors."
• Trade-off with Latency: Higher recall guarantees often require more computational resources, impacting latency and throughput. The SLA defines the operating point on this trade-off curve.

The maximum allowable percentage of requests that result in a server-side error (HTTP 5xx or equivalent gRPC status codes), excluding client-caused errors (4xx).

• Calculation: (Number of Failed Requests / Total Requests) * 100.
• Typical Guarantee: Less than 0.1% (0.001) error rate.
• Exclusions: Errors due to invalid client requests, rate limit violations, or authentication failures are typically not counted toward the provider's error rate SLA.

A specific URL where a client sends requests to interact with a particular function of a vector database. Each endpoint corresponds to a distinct operation, such as /v1/collections for managing data groups or /v1/query for executing similarity searches. The availability and latency of these endpoints are the primary subjects of an SLA. Endpoints are defined in the API's documentation and OpenAPI specification.

A control mechanism enforced at the API layer to restrict the number of requests a client can make within a specific time window (e.g., 1000 requests per minute). This ensures:

• System Stability: Prevents any single client from overwhelming the database and degrading performance for others.
• Fair Usage: Enforces tiered access based on subscription plans.
• SLA Protection: Acts as a first line of defense against traffic spikes that could violate latency or uptime guarantees. Exceeding limits results in HTTP 429 Too Many Requests responses.

A resilience pattern implemented within a Client SDK that temporarily halts requests to a failing API. When error rates or latency from the vector database exceed a threshold, the circuit breaker "opens," failing requests immediately at the client side. This prevents:

• Cascading Failures: Stopping calls allows the backend service to recover.
• Resource Exhaustion: Avoids threading deadlocks in the client application.
• SLA Violation Amplification: By failing fast, it prevents the client's application from contributing to its own latency degradation. After a cooldown period, it allows a test request to see if the service has recovered.

An error-handling strategy in SDKs where transiently failed API requests (e.g., HTTP 5xx errors, network timeouts) are automatically reattempted. Exponential backoff progressively increases the wait time between retries (e.g., 1s, 2s, 4s, 8s). This is critical for:

• Transient Fault Recovery: Handling brief network blips or database node failovers.
• SLA Adherence: Intelligent retries can turn a failed request into a successful one without violating overall latency expectations for the end-user operation.
• Load Management: Prevents retry storms that could further destabilize the system.

A security protocol for authenticating both the client and the vector database server during API connection establishment. Unlike standard TLS where only the server presents a certificate, mTLS requires the client to present an X.509 certificate signed by a trusted Certificate Authority. This provides:

• Strong Authentication: Verifies the identity of both parties, crucial for machine-to-machine communication.
• SLA Security Context: Ensures performance guarantees apply only to authenticated, authorized clients, preventing abuse from unauthorized entities.
• Encrypted Communication: All API traffic remains encrypted in transit, protecting vector data and metadata.

The formal process of marking an API version or feature as obsolete and scheduling its removal. A clear sunset policy is part of a comprehensive SLA, specifying:

• Announcement Timeline: When the deprecation is communicated (e.g., 6 months in advance).
• Support Period: The duration the deprecated version will remain operational, often with reduced SLA guarantees.
• Removal Date: The final date after which the endpoint will return errors. This process allows developers to migrate their Client SDK integrations without unexpected service breaks, maintaining overall system reliability.