Multi-Engine Query Routing
LakeOps connects Trino, Spark, Snowflake, Athena, DuckDB, and Flink to one intelligent routing layer. Queries are automatically routed to the optimal engine based on cost, latency, or throughput — without changing application code.
Why query routing?
Different workloads have different requirements: BI dashboards need sub-second latency, ETL pipelines need cost efficiency, and ad-hoc exploration needs flexibility. Without routing, applications hard-code engine connections and can't adapt to load, cost, or availability changes.
- •Decouple applications from engines — connect once, route anywhere
- •Optimize cost and performance — automatically pick the best engine for each query
- •Zero-downtime failover — reroute instantly when an engine goes down
- •One endpoint for AI agents — agents connect to a single URL, routing handles the rest
How routing works
LakeOps exposes routing groups that your applications, BI tools, and AI agents connect to using standard SQL interfaces. When a query arrives:
- •The routing layer identifies the target routing group from the endpoint URL
- •It evaluates each eligible engine based on the group's routing strategy
- •Factors include engine availability, current load, cost per query, table locality, and historical latency
- •The query is dispatched to the selected engine and results returned to the client
- •The routing decision is logged for observability and auditing
Routing strategies
Each routing group uses one of three strategies:
Cost
Routes queries to the cheapest engine that can execute them within acceptable latency bounds. Best for batch ETL, scheduled reports, and background processing.
Cost is calculated from engine-specific pricing (compute time, data scanned, etc.)
Latency
Routes queries to the fastest engine for the given query pattern and data size. Best for BI dashboards, interactive analytics, and AI agent queries that need near-instant responses.
Uses historical P50 latency per engine for similar query shapes
Throughput (Balanced)
Balances queries across engines to maximize overall throughput and prevent any single engine from becoming a bottleneck. Best for mixed workloads with varying query patterns.
Distributes load based on current engine utilization and capacity
Query routing screen
Navigate to Routing > Overview in the sidebar. This screen provides a high-level summary of your routing infrastructure:
- •Summary cards — active groups, engines in use, total routed queries
- •Queries this week — daily bar chart showing routing volume trends
- •Active sessions — currently connected users with their roles and query counts
- •Engine mix — percentage of queries routed to each engine
- •Query shapes — breakdown by operation type (SELECT, JOIN, AGGREGATE, INSERT, UPDATE, DELETE)
Three quick-link tiles provide direct access to routing groups, performance metrics, and global settings.
Routing groups
Navigate to Routing > Endpoints to manage routing groups. Each group is a named configuration that maps workloads to engine pools.
Group properties
| Property | Description |
|---|---|
| Name | Descriptive name (e.g. Analytics, BI, Data-Team ETL, Reports) |
| Status | Active (passing traffic) or Inactive (paused) |
| Endpoint URL | Unique URL clients connect to (e.g. e1fa3c3c.lakeops.dev) |
| Engines | Which engines are eligible for this group (e.g. Trino + DuckDB) |
| Query types | Which SQL operations this group handles (SELECT, INSERT, UPDATE, etc.) |
| Priority | High, Medium, or Low — affects queue ordering |
Summary stats
The Endpoints screen shows four stat cards: total groups, active groups, inactive groups, and total publicly available endpoints. Below are routing group cards with Edit and Delete actions.
Performance Metrics
Navigate to Routing > Metrics for real-time routing analytics:
Key metrics
Visualizations
- •Routing volume by group — stacked bar chart showing daily load distribution across groups (Analytics, Transactional, ETL, Reporting)
- •Engine load distribution — horizontal bar chart showing query percentage per engine
- •Query shapes — operation mix breakdown (SELECT, JOIN, AGGREGATE, INSERT, UPDATE, DELETE)
Global Settings
Navigate to Routing > Settings to configure system-wide routing behavior. Click Save Settings to persist, or Reset Defaults to revert.
Automatic Failover
When enabled, LakeOps automatically redirects queries to another engine when the target becomes unavailable. Configure the Failover Delay slider to control how quickly failover triggers.
Default Query Timeout
Maximum time (in seconds) before a query is terminated. Default: 300 seconds. Applies to all queries unless overridden at the routing group level.
Default Load Balancing Strategy
The strategy used when no specific routing group is matched. The default is Balanced.
Advanced Settings
Three toggle switches for fine-grained control:
- • Cache Query Results — cache frequently accessed results for faster responses
- • Retry Failed Queries — automatically retry on transient engine errors
- • Log All Routing Decisions — full audit trail of every routing decision
Query Queue Priority
Configure priority levels for different query categories:
| Category | Default Priority | Use case |
|---|---|---|
| Interactive Queries | High (80%) | Immediate execution needs |
| Batch Queries | Medium (50%) | Scheduled reports, background processing |
| Background Jobs | Low (20%) | Maintenance tasks, low-priority processing |
Wire compatibility
Routing endpoints are compatible with standard database protocols. Your applications connect as if talking to a regular database:
PostgreSQL wire protocol
Compatible with any Postgres client, psql, JDBC/ODBC drivers
MySQL wire protocol
Compatible with MySQL clients and connectors
Arrow Flight
High-performance columnar data transfer for analytics workloads