SQL Editor architecture — Classic mode
The Classic path in SQL Lab is a workspace-scoped browser experience backed by Superset and Trino. The browser sends query work through the workspace BFF; Superset prepares and submits it to the Trino gateway; Trino applies catalog and Ranger policy controls before reading data. Several controls on the same page take a different path or remain entirely in the browser.
This is a source-derived current-state architecture supplemented by one
safe page-level runtime pass in realm gj76anadpsc, workspace w-t5e2kcxjd.
That pass confirmed that the tested Classic browser path worked through the
workspace BFF. It did not independently
trace every internal service hop or establish behavior for other roles, modes,
scale boundaries, or failure conditions. Ownership and operational review are
still pending.
Scope and evidence basis
This page covers /admin/sql with the Classic execution path selected. It
includes catalog exploration, query execution, browser-held results, and the
embedded history, save, rename, format, share, visualization, download, and
dashboard-handoff controls. Nitro or accelerated execution is recorded only far
enough to make routing and support boundaries explicit. The separate
/admin/queries page is covered only for the observed Query preview handoff
back into Classic SQL Lab.
SQL Editor reuses the Catalog feature's discovery state and therefore inherits its connection-versus-catalog and Ranger-scoping boundary. Oqullus currently labels Superset database connections as catalogs even though Superset supports real Trino catalog discovery. The canonical analysis and restricted-user scenario are documented in Catalog architecture and CAT-S015. This page owns the subsequent SQL execution and effective-query-identity assessment; it does not duplicate the discovery finding.
SQL Editor selector contract
For the current Trino-only scope, the controls mean Catalog, Schema, and
Mode. delta, default, and Classic are the values observed in the
assessed deployment, not hard-coded catalog or schema requirements. The
Superset database connection is hidden infrastructure. Its numeric database ID
may be carried internally to route Superset API calls, but it must not be
conflated with the selected Trino catalog or used as its user-facing identity.
Populate Catalog from Superset's catalog-aware Trino API. Restore a prior catalog only while it remains authorized; otherwise choose an authorized server default, then fall back to the first authorized catalog in stable order. Populate Schema from that catalog using the same rule. If compute isolation is introduced later, Compute is a separate selector rather than another name for Catalog.
| Source | Snapshot reviewed | Architectural evidence used |
|---|---|---|
Cogrion UI (oqullus) | 363355f968fed665a8c7b6cb23045049ec6bbfe9 | Page composition, browser state, request paths, and embedded-control boundaries |
| BFF API | ef1ea8de0679ef58e8def9483eba07c214dd1e0c | Authentication, token exchange, direct Superset path, and dashboard-access path |
| Platform stacks KCL | a71390d124638bc7a91926e7cdd2de7b6684a8ee | Query-cluster profiles, worker count and autoscaling, gateway registration and scaling, dependencies, identity configuration, storage, and telemetry |
| Live page observation | 31 August 2026; admin in workspace w-t5e2kcxjd (visible name alicloud01) | Workspace BFF request paths, success and error behavior, browser state, and embedded-control handoffs |
| Deployment identity | Keycloak realm gj76anadpsc; workspace w-t5e2kcxjd; Kubernetes context dev-north-alicloud | Environment boundary for subsequent deployed-configuration evidence |
The platform-stacks assessment was refreshed from its tracking branch on 3
September 2026. The deployed workspace reported
Superset 4.1.2, BFF image public.ecr.aws/quantdata/sparqd/bff-api:a85f78b, and
Trino 483. The deployed UI revision and complete KCL value set were not tied to
the reviewed commits.
System context
The diagram shows logical responsibility, not every network call. In particular, the browser uses the workspace-specific BFF selected from its active workspace context; it does not query Trino directly.
Component responsibilities
| Component | Responsibility in the Classic path | Current boundary |
|---|---|---|
| Cogrion UI | Hosts SQL Lab, query tabs, editor state, result rendering, local visualization, and page-level controls. | Browser and control-plane boundary |
| BFF API | Validates the caller, selects workspace services, exchanges credentials for direct Superset requests, and proxies SQL Lab traffic. | Per-workspace public API boundary |
| Keycloak | Validates workspace identity and issues audience-specific credentials. | Identity trust boundary |
| Dashboard Access Management | Mediates the history and saved-query branch exposed through the BFF. | Workspace authorization and metadata boundary |
| Superset | Provides SQL Lab APIs, database metadata, query records, formatting and estimation, and submits SQL to Trino. | SQL application and metadata boundary |
| Trino | Routes and executes SQL across a registered cluster and its catalogs. | Distributed query-engine boundary |
| Ranger | Supplies Trino data-access policy decisions. | Data-authorization boundary |
| Hive Metastore | Supplies table and schema metadata for the configured catalogs. | Catalog-metadata boundary |
| Object storage | Holds table data and platform-managed query storage where configured. | Persistent data boundary |
Classic query flow
The Classic client explicitly asks for synchronous execution. With
SQLLAB_BACKEND_PERSISTENCE enabled, Superset 4.1.2 executes that SQL, writes
the successful result to RESULTS_BACKEND under a new UUID, and also returns
the rows in the synchronous response. Responses in realm gj76anadpsc,
workspace w-t5e2kcxjd, for executions 177 and 178 each included a different
resultsKey, confirming that this storage
path was active. It persists results for retrieval or export; it does not look
up an earlier result by SQL before execution.
Classic execution does not poll. One Run handler call invokes executeQuery
once, which submits one POST through useHttpTemp. That shared client path uses
withRetry with two retries and classifies HTTP 500 as retryable, waiting 500
ms and then 1,000 ms. Therefore a final HTTP 500 can produce three complete BFF
POSTs. The BFF SQL Lab route forwards each incoming POST to Superset once and
does not add a polling or retry loop. Live tests showed both invalid syntax and
a Trino INVALID_CAST_ARGUMENT represented as HTTP 500. The cast test produced
three distinct Trino query IDs from one Run action, proving that the generic
client policy repeated engine execution rather than polling. OOM was not
injected; any OOM or infrastructure failure returned as HTTP 500 would meet the
same client retry condition.
The intended identity chain is user identity to workspace BFF, a Superset-audience credential to Superset, and an effective user plus JWT from Superset to Trino. Superset is configured to fall back to a service credential when a usable user credential is unavailable. The effective principal, impersonation behavior, and Ranger decision for each role must therefore be verified end to end rather than inferred from route visibility.
Mode-specific routing status
| Mode or adjacent path | Source-derived route | Result and state behavior | Evidence state |
|---|---|---|---|
| Classic | Browser → workspace BFF /superset/api/v1/sqllab/execute/ → Superset SQL Lab → Trino gateway → Trino | Synchronous response is assigned to the active tab, retained in browser memory and IndexedDB, and followed by a separate estimate request. | Observed working in realm gj76anadpsc for one admin in workspace w-t5e2kcxjd (alicloud01); coverage is partial |
| Accelerated or Nitro | Browser → workspace BFF /ltap/query → LTAP backend | Client qualifies bare table references, sends offset 0 and the selected limit, normalizes object or positional rows, and omits Classic estimate fields. | Source only; runtime and environment availability were not tested; authorization, history, cancellation, failure, and scale are not confirmed |
| Classic history and saved work | Browser → workspace BFF query routes → Dashboard Access Management → Superset query or saved-query metadata | Lists and mutations are held in Query context separately from the active execution request. | Partly observed for inline history and one create/delete cycle; preview handoff is covered below; update, failure, ownership, and retention were not tested |
| Query preview | Queries page → browser-held selected saved/history record → preview modal; Open in SQL Lab adds a tab and navigates to /admin/sql | Preview itself does not execute SQL. History can display user SQL and executed SQL as separate tabs. | Observed for one history record: SQL loaded into a Ready tab with no result and no execute request |
The UI contains a comment that LTAP is available only through an environment-restricted BFF, but the reviewed selector remains visible and the platform deployment source contains LTAP components. Those source signals do not establish which deployed environments are intended or ready. Classic is the only mode observed live.
Result completion and partial-output boundary
The Classic client assigns result rows only after the synchronous execute call returns successfully. Its error path records an error but does not clear the previous tab result or estimate. The result panel checks Visualization before the error branch, so a failed run can leave a prior visualization visible. No partial-result flag, stream-completion marker, result-to-run identifier, or client contract distinguishing complete, incomplete, restored, and stale results was identified.
Stop is different: the client aborts the browser request, clears the active tab's local result and estimate, and resets its local executed state. This does not prove that Superset, the gateway, or Trino stopped upstream work. An end-to-end cancellation claim therefore requires correlated engine-side cancellation and completion evidence.
State ownership and persistence
| State | Owner and store | Assessment implication |
|---|---|---|
| Open tabs, SQL text, names, catalog, and schema | Browser local storage | SQL is serialized on every editor change; rename and metadata changes also write locally. This is browser draft persistence, not backend autosave. A new tab uses a local UUID. After Save, the same tab.id is replaced with the backend saved-query ID rather than stored as an explicit resource reference, and that returned ID is not immediately written locally. Live switching and reload preserved distinct tab state, but source keys include user identity and not workspace identity. |
| Active tab selection | Browser local storage | Clicking a tab writes a user-scoped active-tab key. addTab and the active-tab fallback in closeTab call the raw state setter instead, so they do not update that key. Live reload returned from a newly created active tab to the previously clicked tab. |
| Current execution, elapsed time, error, and request cancellation | Browser memory per tab | These fields are not persisted. Live reload preserved SQL and results but reset Succeeded to Ready. Cancelling the browser request does not prove cancellation of upstream Trino work. |
| Query results | Browser memory plus a custom Oqullus wrapper around browser-native IndexedDB | sqlLabStorage.ts stores rows in sqlLabResultsDB/tabResults under ${userId}__${tabId}. Live switching, reload, and in-app navigation preserved results. The copy is browser-profile-local, can disappear with cleared site data, can become stale, lacks workspace identity in its key, and duplicates the Superset backend result. Retention, quota, sensitive-data handling, and cross-workspace isolation need validation. |
| Superset result payloads | Object-storage RESULTS_BACKEND, keyed by a new UUID for each completed query | Realm gj76anadpsc, workspace w-t5e2kcxjd, returned distinct result keys for two identical Classic Runs. This supports later retrieval/export, not same-SQL reuse. Backend retention and cleanup were not measured. |
| SQL Lab query history | Superset query metadata reached through Dashboard Access Management | Live history refreshed when SQL Lab remounted, not when the panel opened. This is distinct from the Trino gateway's operational query history. |
| Saved queries | Superset metadata reached through Dashboard Access Management | Save/Ctrl+S is the only query-definition mutation: a local UUID selects POST/create and a numeric tab.id selects PUT/update. Run does not save the definition. Live Save created a record immediately and cleanup deleted it. Update, immediate-reload identity recovery, failure, ownership, sharing, and retention were not live-tested. Source shows save failures are swallowed before the progress caller and can therefore finish the progress indicator despite failure. |
| Dashboard-access state | Dashboard Access Management database | The service has a workspace database and mediates saved-work authorization; exact record ownership needs owner confirmation. |
| Superset application metadata | Superset database | Holds application metadata independently of browser-held results. Backup and recovery evidence is pending. |
| Gateway routing and operational history | Trino Gateway database | Source configuration declares a 72-hour gateway history retention; deployed value and operational use are Unverified. |
| Schemas and tables | Hive Metastore | Catalog availability depends on this service even when the editor itself is healthy. |
| Table data | Workspace object storage | Data remains subject to Trino catalog and Ranger controls. |
| Access policy | Ranger and its database | Effective policies depend on role synchronization and service configuration. Audit destination and retention are Unverified. |
The workspace boundary is weaker than the source comments imply. Tab metadata
is keyed by user only, result records are keyed by user and tab only, and the
exported clearAllTabResults helper has no caller. The initialization effect
claims to reset for a workspace change but resets its guard only when there is
no active workspace; a direct switch between two populated workspaces does not
meet that condition. Cross-workspace behavior was not exercised from workspace
w-t5e2kcxjd,
so disclosure or accidental execution is a source-backed risk rather than a
demonstrated incident.
Caching and repeat execution
No requirement was found for an explicit Run to reuse a previous final result. Executing again is a reasonable default for freshness and nondeterministic SQL, so the observed repeat behavior is documented here rather than classified as a finding.
| Layer | What exists | Classic repeat-query implication |
|---|---|---|
| Browser | Oqullus custom code uses browser-native IndexedDB to store the latest rows by user and tab. This is separate from Superset caching. | Same-browser persistence only. Run does not read IndexedDB before sending SQL, and clearing site data removes the copy. |
| SQL Editor | Every Classic Run sends a synchronous execute POST with runAsync: false. | No client-side SQL/result cache or cache-hit branch was identified. |
| Workspace BFF | SQL Lab execute is a direct authenticated proxy to Superset. A separate catalog service has a five-minute Valkey query cache for catalog and FAQ paths. | The catalog cache is not called by /superset/api/v1/sqllab/execute. |
| Superset | Deployment source enables SQLLAB_BACKEND_PERSISTENCE and configures object-storage RESULTS_BACKEND. In Superset 4.1.2, a successful synchronous run is executed first and then stored under a fresh UUID. Live responses contained distinct result keys. | Result caching/persistence is active, but it is not keyed by normalized SQL and is not consulted before execution. |
| Native Superset versus Oqullus | Native SQL Lab retains resultsKey, can fetch /api/v1/sqllab/results, restores backend tab state, uses asynchronous execution when the database allows it, and sends a server-side stop request by client_id. Oqullus forces synchronous execution, ignores resultsKey, restores rows from IndexedDB, and only aborts its browser request. | Repeat execution is equivalent, but Oqullus uses less of Superset's recovery, large-query, cross-browser, and cancellation lifecycle. |
| Trino and storage | Deployment source declares five-minute Delta metadata and filesystem caches. Additional JVM, operating-system, object-store, and metastore warming can occur. | Repeated scans may become faster, but these facilities do not reuse the final SQL result in the browser. Deployed cache state and hit metrics were not inspected. |
| Live exact-repeat probe | The same SQL ran twice with HTTP 200, distinct execution records (177, 178), Superset result keys, timestamps, and UUIDs. The UI reported 1.20 and 0.65 seconds. | Both outputs were cached separately after execution; the second Run did not reuse the first result. The timing improvement alone cannot identify which lower layer warmed. |
Trust and deployment boundaries
- The Cogrion UI crosses into a workspace through the workspace-specific BFF ingress. A route's candidate-role list is a navigation gate, not proof of data authorization.
- Direct SQL Lab traffic is authenticated by the BFF and uses an exchanged Superset-audience credential. The BFF caches exchanged credentials in its workspace Valkey instance; cache lifetime and revocation behavior need runtime evidence.
- History and saved-query traffic follows a separate BFF route to Dashboard Access Management using the original caller credential. That service owns its own validation and downstream Superset access.
- Superset reaches the in-cluster Trino gateway over TLS. Trino's Ranger plugin is the data-policy enforcement point; successful page access must not be treated as permission to query every visible object.
- The deployment separates the main services across
qd-system,superset,trino,ranger, and Hive Metastore namespaces. All are composed for a workspace, but the exact network-policy boundary forw-t5e2kcxjdis Unverified. - BFF and Superset stack dependencies require the Trino foundation, not proof that a query cluster is registered and ready. The BFF also has no explicit deployment dependency on Dashboard Access Management. Feature readiness can therefore differ between direct execution and saved-work controls.
For the intended authorization model, see Data Access and Authorization and Superset, Trino, and Ranger security.
Data-access enforcement
| Layer | Intended control identified in source | Evidence gap |
|---|---|---|
| UI route and navigation | Candidate roles determine whether SQL navigation is exposed. | Navigation is not a data-authorization control; only one admin account was observed. |
| Workspace BFF | Validates the caller and workspace context and exchanges an audience-specific credential before forwarding direct Superset or LTAP traffic. | Invalid, expired, cross-workspace, and revoked credentials were not exercised; token-cache revocation is Unverified. |
| Dashboard Access Management | Mediates history and saved-query operations using caller context. | Saved-query ownership, update/delete authorization, sharing, Run as owner/viewer, and audit records are Unverified. |
| Superset | Receives an exchanged credential and submits SQL with effective identity configuration; source also permits a service-credential fallback. | Effective principal and fallback conditions for each role are Unverified. |
| Trino and Ranger | Trino is the data-policy enforcement point and consults Ranger before data access. | No restricted-role denial, row/column masking, policy outage, redaction, or audit evidence was collected. |
| Metastore and object storage | Supply metadata and data only after the query reaches the engine. | Storage IAM, encryption, tenant boundaries, and the relationship between catalog visibility and effective data permission remain Unverified. |
The assessment must not infer query authorization from a visible catalog, schema, table, column, route, or sharing option. Scenario SQLC-S021 requires an approved restricted identity and protected object so denial and redaction can be demonstrated without probing unauthorized data.
Embedded-control paths
| Control | Architectural path | Boundary of this assessment |
|---|---|---|
| Format SQL | Browser → BFF → Superset | Valid formatting was observed and did not execute Trino SQL. |
| Query estimate | Browser → BFF → Superset after execution | Estimates were observed after success; a failed later query retained the prior estimate footer. |
| Past Execution | Browser → BFF → Dashboard Access Management → Superset metadata | Inline history was observed to refresh on page remount rather than panel open. Separate history pages remain out of scope except cleanup. |
| Save query | Browser → BFF → Dashboard Access Management → Superset metadata | One click created a record without confirmation or visible success; the assessment record was deleted. Update and failure remain Unverified. |
| Rename tab | Browser state | A non-blank rename and restoration were observed. Source updates only local tab state and local storage; it does not rename a saved query or call a backend. |
| Result sorting, search, paging, and visualization | Browser-held result | Search, sort, cell viewing, and Bar visualization operate on returned client data without a new SQL Lab execution. A 10,000-row table paged and searched successfully. The first 10,000-category chart was blank, 100 categories rendered, and returning to 10,000 categories produced an unreadably compressed chart. Source has no independent point or cardinality budget. |
| CSV, TSV, Excel, PNG, and PDF export | Browser-generated download | Bar PNG and PDF were verified and deleted. Raw-result CSV, TSV, and Excel remain unverified. |
| Create Dashboard | Browser session handoff to Dashboard Builder | The handoff produced one unsaved Bar Chart and a separate catalog query request. No dashboard was created. |
| Share | Browser obtains candidate users and groups from the control plane | Saved queries have numeric backend IDs, but Share does not bind to the ID. The editor routes are static and cannot load a query from a URL, the modal uses only the active tab name, and access selections remain local state with no mutation. Copy link is inert because no canonical share target or resolver contract exists. |
| Schedule | Visible but disabled in source and live page | No active scheduling architecture is claimed. |
Failure propagation and recovery
| Failure | Expected architectural effect | Evidence still required |
|---|---|---|
| Missing or stale workspace context | The UI cannot resolve a trustworthy workspace BFF target. | Redirect, error, and state-isolation behavior |
| Invalid user credential or failed exchange | Direct Superset requests fail before query execution. | Status mapping, reauthentication, cache revocation, and user message |
| Superset unavailable | Metadata, format, estimate, and execution fail; local SQL should remain recoverable. | Retry behavior, timeout, alerts, and recovery objective |
| Dashboard Access Management unavailable | History and saved work fail independently while direct execution may remain available. | Failure isolation and page messaging |
| No healthy Trino backend | Superset can be reachable while execution fails at the gateway. | Readiness gating, routing error, and recovery behavior |
| Ranger denial or policy-service failure | Trino rejects or cannot authorize access. | Deny behavior, error redaction, fallback behavior, and audit record |
| Metastore or object-storage failure | Planning or data read fails after the request reaches Trino. The assessed HMS deployment has redundant service pods but a single PostgreSQL replica, so metadata-database failure can affect all Trino and Spark consumers. | Error classification, bounded retry safety, database failover, backup restore, and operational correlation |
| Estimate failure after query success | Results may be valid while estimate fields are unavailable. | Page state and error-isolation behavior |
| Browser persistence unavailable or full | Local continuity or retained results fail even if the query succeeds. | Visible warning, cleanup, quota, and fallback behavior |
| Malformed or incompatible visualization data | A chart should reject or normalize invalid rows and show a chart-local fallback while preserving SQL, Raw Result, and result controls. The reviewed source instead relies on an error boundary around the entire SQL Editor. | Result-shape contract, chart compatibility policy, panel-level recovery, and fault-injection evidence |
| Oversized or high-cardinality visualization data | Client chart work should be capped, aggregated, sampled, or refused before it can exhaust browser CPU, memory, or canvas limits. The 10,000-row raw table worked, while a 10,000-category Bar chart was blank on first render, rendered after an axis toggle only as a compressed chart, and later delayed browser inspection on remount. | Approved row, point, cardinality, label-size, and recovery budgets; current workaround is SQL aggregation or Raw Result |
| Untrusted result text reaches a chart tooltip | Returned labels and values must remain inert text. Tooltip construction must encode untrusted content rather than interpolating it into active HTML. | Security review and browser evidence with approved inert fixtures |
| User selects Stop | The browser aborts its active request and clears local running state. | Whether Superset, gateway, and Trino work is actually cancelled |
Observability and audit boundary
| Signal or record | Source-identified purpose | Assessment limitation |
|---|---|---|
| SQL Editor status, timer, toast, and error detail | User-visible request state in the browser | Not durable operational evidence; restored state and stale estimate behavior can be ambiguous |
| Browser network log and Playwright trace | Assessment evidence for browser-to-BFF requests | Collected only for one safe pass and still stored temporarily; no realm-wide or workspace-wide coverage |
| BFF application logging | Possible proxy and downstream error evidence | Deployed log destination, retention, redaction, correlation IDs, dashboards, and alerts are Unverified |
| Superset query and saved-query metadata | User-facing Classic history and saved work | Freshness, retention, ownership, deletion, backup, and use during incident response are Unverified |
| Trino gateway query history | Source declares gateway lifecycle history and 72-hour retention | Deployed retention, completeness, user visibility, and correlation to browser and Superset IDs are Unverified |
| Trino JMX and Prometheus integration | Possible engine health, workload, and capacity signals | Environment dashboards, thresholds, alerts, SLOs, and reviewed incidents were not supplied |
| Ranger policy and audit path | Intended authorization decision and audit evidence | Audit destination, fail-closed behavior, retention, redaction, and role-specific evidence remain Unverified |
| Distributed tracing across UI, BFF, Superset, gateway, Trino, and storage | Needed to prove routing, latency, retry, cancellation, timeout, and recovery | No end-to-end trace or shared request identifier was demonstrated |
Scale, performance, and cost boundaries
| Boundary | Current source or live evidence | Observed boundary |
|---|---|---|
| Requested row limit | UI offers 10, 100, 1,000, 10,000, and 100,000. A generated 10,000-row query with limit 10,000 returned all rows. | 10,000 rows worked for one bounded shape; server enforcement and larger limits were not tested. |
| Classic response model | Client requests synchronous execution and receives one result payload before assigning rows. | Streaming and partial output are not implemented in this path; payload, proxy-timeout, and memory limits were not tested. |
| Result table | Client holds the complete returned set, displays 50 rows per page, and performs client-side search and sort. Live evidence showed 10,000 rows and found row-10000 through client search. | Pagination reduces visible rows, not retained payload or client work; 100,000 rows and browser-memory limits were not tested. |
| Visualization | Client transforms and renders the complete returned set; no separate point, category, label, or memory budget or downsampling path was identified. Live evidence showed unstable 10,000-category rendering while 100 categories rendered. | High-cardinality use is unsafe to rely on. Aggregate to low-cardinality categories or use Raw Result; the maximum usable cardinality was not measured. |
| Browser export | CSV, TSV, Excel, PNG, and PDF are generated client-side; raw export slices to the selected query limit. | File size, memory, encoding, formula/content safety, and browser limits were not tested. |
| Concurrency | Source keys execution and abort state per tab. A live bounded pass showed the quick tab enter Executing while a generated-sequence aggregate still had its running spinner; both Classic execute requests returned HTTP 200 and retained independent results. | Two overlapping read-only queries worked; sustained or higher-width concurrency, failure isolation, limits, fairness, queuing, and cost controls were not tested. |
| Timeout and cancellation | Stop aborts the browser request. | Upstream cancellation, timeout classification, retry safety, and compute-cost termination were not tested. |
| Browser persistence | Live switching, reload, and in-app navigation preserved distinct tab SQL and results. Source uses local storage for tab metadata and IndexedDB for results. | A newly added active tab failed to remain selected after reload; quota, eviction, workspace partitioning, sensitive-data retention, and long-term recovery were not tested. |
| Query and infrastructure cost | Trino planning, scans, exchange, workers, gateway, Superset, and retained metadata are material cost drivers. | Attribution, budgets, guardrails, idle cost, chargeback, and cost-based query controls were not evidenced |
| Query-cluster capacity | Source configures a fixed capacity profile and worker count and disables query-worker autoscaling. On 3 September 2026, the assessed deployment had one coordinator and one worker; only the gateway had a horizontal autoscaler. | The gateway does not add query execution capacity. Saturation, queueing, fairness, worker scale-out, safe scale-in, and recovery were not tested. See PERF-SQL-001. |
| Compute isolation and lifecycle | Source can deploy and register a named additional Trino cluster, but the current flavor and deployed workspace use one defaultcluster; no managed product lifecycle or SQL Editor Compute selector was identified. | Multi-cluster deployment is an operator primitive, not a supported create, route, resize, stop, recover, and delete lifecycle. See ARCH-SQL-003. |
| Shared metadata capacity | HMS had two fixed replicas behind one Service, while its backend had one fixed PostgreSQL replica with 20 GiB storage and small resource limits. HMS used the direct primary database port rather than the available pooled port. | Metadata-heavy planning, aggregate connection use, HPA behavior, database failover, backup restore, storage exhaustion, and multi-compute pressure were not tested. See PERF-SQL-002. |
Managed SQL compute
SQL compute and data access are separate planes. A Trino cluster supplies query capacity; Catalog and Schema identify data; Ranger evaluates the effective user's data access. Multiple computes can therefore share authorized catalogs and Ranger policies without making Catalog a compute selector.
| Concern | Current state | Target direction |
|---|---|---|
| Query capacity | One fixed coordinator and worker were observed; query-worker autoscaling is disabled. | Admit work before saturation, then scale workers from measured query pressure within explicit minimum, maximum, stabilization, cost, and safe-scale-down limits. |
| Workload control | No active query resource-group or equivalent admission policy was evidenced. | Define concurrency, queue, memory, fairness, timeout, and rejection policy by trusted workload identity; surface Queued, Throttled, and Capacity unavailable distinctly. |
| Gateway | Gateway replicas can auto-scale and route to registered clusters. | Treat gateway health and scale as routing-plane capacity, not evidence of query-compute capacity. |
| Cluster lifecycle | Platform stacks can deploy and register a named cluster, while the default flavor and current product path use one defaultcluster. | If isolation is needed, manage logical compute identity, create, readiness, routing, resize, start, stop, degradation, recovery, and deletion through a reconciled platform lifecycle. |
| User choice | SQL Editor exposes Catalog, Schema, and Mode, not Compute. | Keep raw worker, pod, and JVM controls internal. Expose Interactive, Batch, or an approved named compute only when the lifecycle and permissions exist. |
| Data access | Catalog configuration and Ranger policy are independent of the current compute deployment and routing. | Preserve one catalog and policy plane across computes; verify the effective user and authorization do not change when routing changes. |
| Shared metadata plane | Two fixed HMS replicas serve a single small PostgreSQL replica. Source exposes an installer-facing HMS Size preset, but it does not jointly size the database tier. Trino clusters and Spark consumers share this dependency. | Provide an administrator-facing metadata capacity profile covering HMS, database, pooling, storage, HA, and resize state. Add managed HMS autoscaling only when reliable signals and database headroom make it safe. |
The smallest reliable step is admission and truthful queue feedback on the existing default compute. A larger fixed cluster raises the ceiling but does not define fairness. Multi-cluster lifecycle is justified when workload, team, availability, or cost isolation requires it; it should not be introduced by renaming Catalog or exposing Kubernetes settings.
HMS scaling is an end-to-end metadata concern rather than another user-facing SQL Editor control. Apache Hive's 3.0+ metastore high-availability guidance describes the remote service as stateless and suitable for multiple instances. The current Kubernetes Service already distributes requests across two ready HMS pods. Increasing that replica count alone is insufficient, however: each instance can add database connections while all instances still depend on one PostgreSQL replica. The capacity unit therefore includes request rate, partition cardinality, HMS threads and pools, total database connections, database latency and storage, backup recovery, and the number of Trino and Spark consumers.
The existing installer Size selector is the right starting point when managed autoscaling is unavailable. It should remain a logical administrator control, not a set of raw Kubernetes or JVM fields, and it must resize the metadata chain rather than only the HMS pods. The interface needs current and recommended tier, documented capacity assumptions, expected disruption, progress, failure, and rollback state.
Delivery and lifecycle boundary
The UI, BFF, and KCL commits reviewed for this assessment are immutable source
references. Platform stacks was refreshed from its tracking branch on 3
September 2026. The deployed workspace exposed Superset 4.1.2, BFF image
a85f78b, and Trino 483,
but no deployed-version manifest tied the UI or KCL observation to the reviewed
commits.
No SQL Editor-focused unit, integration, API-contract, end-to-end, failure, scale, authorization, migration, deployment-verification, rollback, or recovery test evidence was found. Shared chart utilities have limited happy-path tests, which do not establish malformed-data or page-containment behavior. Artifact provenance, dependency versions, upgrade cadence, promotion approvals, rollback ownership, and retain, replace, or retire decisions remain Unverified.
Operations and capacity
The platform source configures health checks and autoscaling for the BFF and gateway, separate Superset web and worker workloads, fixed profile-driven Trino coordinator and worker capacity, Trino JMX metrics, Prometheus monitoring, and query lifecycle events. HMS JMX monitoring is configured, but HMS autoscaling and disruption controls were not evidenced; the single PostgreSQL replica had its exporter disabled. Query-worker autoscaling and workload admission were also not evidenced. The SQL stack depends on the platform observability capability described in Observability.
Those integrations establish possible signals, not an operating model. The review has not yet found environment-specific dashboards, alerts, SLOs, capacity limits, trace correlation, incident evidence, or a Classic SQL Editor runbook. The deployed replica and worker topology was recorded, but usable capacity, concurrency, upper row limits, visualization point and cardinality budgets, timeouts, and recovery objectives were not measured. HMS and PostgreSQL request, connection, failover, backup, restore, storage-growth, and exhaustion boundaries were also not measured. The 10,000-row table probe is evidence for one payload, not metadata scalability.
Architecture questions still open
- Are browser-persisted tabs and results intentionally keyed without a workspace identifier, and what prevents state disclosure or accidental execution after a workspace change?
- Does Stop propagate cancellation to Superset, the gateway, and the Trino cluster, or only disconnect the browser request?
- Which end-user principal and credential reach Trino for every supported role, including the Superset service-credential fallback?
- What is the supported product contract for DDL or DML when the underlying Superset data source permits write capabilities? This assessment assumes read-only use until an owner decides otherwise.
- Which result data is retained outside the browser for synchronous Classic execution, for how long, and under which deletion and backup policies?
- Which Ranger behavior applies if policy synchronization, policy lookup, or service seeding fails? A safe fail-closed outcome needs runtime evidence.
- What gates feature readiness when the gateway is healthy but no Trino cluster is registered, or when Dashboard Access Management is not ready?
- What is the canonical workspace-scoped saved-query URL, how is a query loaded and authorized by ID, and how are sharing changes persisted? Until that identity and routing contract exists, should Share be removed?
- What deployed values govern row count, payload size, execution timeout, concurrency, browser storage, and downloads?
- Which dashboards, alerts, runbooks, owners, and recovery exercises support this path in each environment?
- What independent limits and downsampling rules govern visualization rows, rendered points, category cardinality, label length, and browser memory?
- Is visualization failure intentionally isolated from the editor and Raw Result, and what encoding contract guarantees that result values remain inert in labels, legends, and HTML-rendered tooltips?
- Which environments and roles support Classic and Nitro, why is the Nitro selector exposed where backend availability is described as environment-restricted, and which owner controls that feature gate?
- What run identifier and state contract distinguishes current, restored, stale, complete, partial, failed, cancelled, and timed-out results and estimates across the browser, Superset, gateway, and Trino?
- Which deployed-version record, test gates, trace correlation, rollback process, cost budgets, and lifecycle owner establish that the reviewed path is the path currently supported in each environment?
- What workload identities and policies should govern admission, queueing, memory, fairness, and overload feedback on the default query compute?
- Is one default compute the intended product boundary, or must the platform manage multiple logical computes? If multiple are required, what lifecycle, routing, permission, quota, and recovery contract applies?
- What metadata request, partition-cardinality, HMS thread, connection-pool, PostgreSQL connection, latency, and storage budgets apply as Trino and Spark consumers scale?
- What HMS disruption, PostgreSQL failover, backup, restore, schema-upgrade, and storage-exhaustion behavior meets the metadata availability objective?
- Can the existing HMS Size selector safely resize a deployed environment, and how will each tier jointly size HMS, database, pooling, storage, HA, and connection headroom with observable progress and rollback?
The corresponding feature and scenario inventory is in SQL Editor — Classic mode. The first runtime pass is recorded in SQL Editor live evidence — Classic mode. Remaining live and owner evidence is required before statements about untested conditions are changed to confirmed.