Tenant-Level SLA Enforcement on Columnar Query Engines

Tenant-level SLA enforcement on columnar query engines requires structural mechanisms. Keeping each tenant within its latency contract requires workload classification, continuous resource accounting, and scheduling below the query optimizer. Those mechanisms must work together because access controls and a well-tuned query plan still leave a tenant exposed to other tenants’ demand for shared resources.

Why tenant-level SLA enforcement is a structural problem, not a configuration one

A compute-heavy tenant starts running more complex queries on a shared columnar engine. A latency-sensitive co-tenant changes nothing about its traffic, yet its queries slow down. The extra work consumes CPU and memory that both tenants need, so contention propagates across the shared system. The affected tenant has done nothing differently. Its latency now depends on work it did not ask for and cannot control.

Shared columnar OLAP infrastructure was built for analytical throughput, and it will produce noisy-neighbor degradation without explicit engine-level enforcement. Query timeouts, connection limits, and basic priority flags operate above the point where resources are contested. They can shed load. They cannot, by themselves, guarantee that each tenant receives enough resources to meet its SLA.

How can that failure remain hidden in production? Average latency can look acceptable while one tenant’s slowest queries breach its contract. Even when the shared service looks healthy as a whole, p99 latency must stay below the limit for each tenant. USPTO patent US11144360 formalizes a corresponding scheduling requirement, combining resource estimation with placement onto a cluster that has enough capacity or proactive autoscaling when it does not. This lets the system check which resources are free before it decides to start the query.

What SLA enforcement actually requires — workload classification, resource accounting, and scheduling discipline

Workload classification gives that decision its starting point. Before a query enters the execution queue, the system needs to identify its tenant, query type, and expected resource profile. Otherwise, it cannot distinguish work with different latency budgets or assign consumption to the right contract.

Per-tenant resource accounting must track actual consumption continuously because tail queries that exceed their estimates are a primary source of SLA breaches. An estimate helps the system decide whether work can start. Accounting reveals whether it is consuming more than expected once it runs. Without that distinction, the scheduler acts on a forecast even after reality has departed from it.

Scheduling discipline supplies the ability to respond. It must operate below the query optimizer so that it can preempt, defer, or route work independently of the optimizer’s plan. A query considered fast in isolation can still saturate shared memory when admitted with other work. Enforcement also has a cost of its own. Keeping controller decisions tied to workload events rather than individual queries avoids adding that control overhead to every request.

The three isolation architectures and where each one breaks down for SLA enforcement

A shared database with row-level security, or RLS, moves tenant filtering from application code into the database engine. Its policy acts as an automatic predicate on every query, providing access isolation without relying on each application query to include the right filter. That is an important boundary, but a specific one. It governs which rows a tenant can access. It does not stop an expensive aggregation over permitted rows from consuming shared compute and degrading another tenant’s p99.

The distinction is between access isolation and workload isolation. Treating them as interchangeable leaves shared compute contention unchecked, even when the access policy works correctly. RLS also introduces operational costs because its predicates can affect query plans and make debugging less obvious. To administer data across tenants, staff need access paths with their own controls. Against the three-part enforcement requirement, RLS supplies a data boundary rather than continuous accounting or scheduling discipline.

Database-per-tenant isolation takes a different approach by keeping each tenant’s data physically separate. This lets each tenant have schema variations, custom calculated columns, and performance tuning of its own. Separation does not make provisioning automatic, though. Each database can still receive too little or too much compute, while schema migrations, backups, and monitoring multiply with tenant count independently of aggregate usage. Enforcing the SLA depends on sizing every tenant correctly, an expensive and inflexible way to secure latency.

Physical resource isolation in HTAP systems gives them more direct control over contention. OS-level cgroups limit how much CPU the work uses, other mechanisms provide memory isolation, and physical read-write separation puts column-store replicas on follower replicas. Automatic routing can then move heavy analytical work away from OLTP primaries. I/O contention can remain in production because cgroups bound it only in some configurations, these controls require OS-level access beyond what most managed service contexts provide, and all three patterns require additional mechanisms to enforce tenant contracts at the scheduler.

How scheduling must operate below the query optimizer to enforce per-tenant SLAs

A query runs, consumes shared resources, and degrades a co-tenant before throttling reduces the offending workload. The throttle may keep the disruption from spreading, but the breach has already happened. With admission control, the sequence changes. The system evaluates resource availability before allowing the query to consume the capacity another tenant needs.

This is a different job from query optimization. The optimizer minimizes execution cost for a single query in isolation, without modeling co-tenant contention or individual SLA contracts. The scheduler must classify the query by tenant and workload tier before optimization, then compare the tenant’s current consumption with its contracted budget. It can defer, route, or reject work when admission would violate another tenant’s SLA.

The patent’s admission model makes proactive autoscaling part of that permission decision. If an existing cluster has enough resources, the scheduler can place the query there. Otherwise, it can trigger additional nodes or a new cluster before execution and before degradation occurs. The important distinction is whether the system responds to anticipated demand or to an SLA breach already in progress.

That decision needs more than a count of active queries. Columnar execution commonly allocates large memory blocks for decompression and vectorized operations, so a small number of queries can still create substantial pressure. Wall-clock time also fails to show how much of the shared resources the work uses. The scheduler needs CPU and memory accounting for the work that is running. Otherwise, its admission decision can look reasonable while the shared engine is already resource-starved.

Agentic workloads as a new class of scheduling pressure on multi-tenant columnar infrastructure

AI agents make those admission decisions harder because their query patterns are not bounded by human attention or UI interactions. They can probe data in parallel, with unpredictable breadth and bursts that resemble a denial-of-service event to a scheduler calibrated for human traffic. Assumptions that held for a person exploring a dashboard may fail when an agent explores autonomously.

Tenant attribution becomes harder when the same agent connects through direct SQL tools, text-to-SQL, pre-indexed retrieval, and MCP-based connections. A scheduler may treat those paths as different workload classes even though they originate from one tenant’s agent. Shared credentials make the problem more severe. With a “god credential,” every LLM-generated query can run with access to every table, while the scheduler lacks the tenant identity it needs to enforce separate budgets.

AI-generated SQL adds another gap between valid syntax and valid tenancy. A coding assistant does not know the tenant model unless explicitly told, so it can produce a query without the required tenant predicate. That omission is easy to overlook in review. Prompt injection creates a related requirement because an out-of-scope query must be caught at the database execution layer, regardless of how the model produced it. Application code and model behavior cannot be the final enforcement boundary.

The security and scheduling problems overlap, but they are distinct. Data leakage concerns what an agent can access, while SLA enforcement concerns whether its unpredictable concurrency can deprive other tenants of resources. The structural response therefore combines isolated, read-only compute over shared data with sandboxed branches for probing without touching production state. Every query also needs full logging. Those controls place responsibility in the execution and access layers rather than in an agent’s willingness to follow instructions.

Per-tenant observability as the feedback loop that makes SLA enforcement operational

Even a correctly designed scheduler needs evidence that its decisions are working. Per-tenant observability closes that loop by measuring query latency at p50, p95, and p99, together with query success rate for each tenant. Those signals show which tenant’s contract is at risk. A shared average cannot answer that question, and a tenant-wide metric can still obscure differences between workload classes with different latency budgets.

For operational teams, the lesson is to set separate SLO windows for exploratory queries and BI dashboard refreshes within each tenant. The workload classes should not be pooled simply because they share an owner. Diagnosis then needs to connect latency changes to resource pressure. Large compaction can exhaust node CPU and I/O, broad column access can spike consumption, and increased object store latency can cause the planner to miss pruning, unexpectedly extending query runtime.

Datadog announced general availability of the Datadog MCP Server on March 9, 2026. Its database monitoring toolset has 11 tools at GA for slow query analysis, wait event breakdowns, and database host performance. Agents can look at the same signals as human operators. For agentic sessions, full query logs let SLA analysis tell agent-driven load from human-driven load within the same tenant, so feedback to the scheduler shows where the demand comes from.

What a defensible SLA enforcement design looks like end to end

A defensible design starts with identity that the query cannot invent. At ingestion, every request needs a tenant identity and a workload class, including interactive, batch, exploratory, or agentic, before reaching the execution queue. The identity must be resolved server-side from a signed token or equivalent, independently of query parameters or application hints. AI-generated code can omit or spoof those hints. Classification is only useful when the system can trust what it classifies.

The next layer combines real-time resource accounting with a controller that stays inexpensive. Tracking needs to cover memory allocation and I/O consumption, rather than treating query count or elapsed time as substitutes for resource use. That is a useful distinction for implementation. Continuous knowledge of consumption does not require every control decision to run on every query’s path.

Admission control then needs authority to act on that accounting before execution. Proactive autoscaling provides a way to add compute rather than leave the admitted tenant blocked on existing capacity. Access isolation still needs its own controls through RLS or an equivalent engine-level mechanism, without relying on how the application builds its queries. Agentic work also needs isolated, read-only compute and sandboxed branches.

The feedback layer must use what happened to guide later scheduling decisions. Its minimum instrumentation includes p99 latency per tenant per workload class, query success rate per tenant, and full query logs for agentic sessions. A breach must be visible at the granularity of the contract. Otherwise, the controller cannot tell whether its admission policy is protecting the workloads it was designed to protect. The result must be a continuing control loop rather than a configuration left untouched after deployment.

Storage architecture sets the final constraint on that loop. Even with a well-designed scheduler, a managed columnar service that sends every execution through object storage cannot keep p99 latency flat as tenants store more data. Object storage on the hot path introduces latency variance that scheduling alone cannot remove. Compute-storage separation therefore needs a fast-storage- or RAM-resident cache layer for hot data. Defensible tenant SLAs require both architectures to be designed for enforcement, with scheduling governing access to resources and storage avoiding variance that defeats those decisions.