+2 from me on this idea...! Having The One UI To Rule Them All -
integrating the "best of" features from the 19001 and 19006 UIs - would
be terrific. Some thoughts starting from Calvin's input:
1. Totally agree about variables. My recollection is that the API and
SQL++ already have a way of supporting them, so the new UI just needs to
exploit that. SUPER important for embeddings.
2. Totally agree about enhancing plans with the timing info - and it
would be nice for that to be a two-level expandable timed plan view -
one with aggregate timings and then the ability to drill down into
individual partitions' performance (to look for outliers, etc.).
3. It would be worth looking at Couchbase's console for Capella
Analytics to borrow more ideas from, and improve on, related to viewing
various metadata and related information (inferred schemas, estimated
cardinalities, dates and maybe data size at sample time for samples, etc.).
4. It would be nice to integrate this with the load management work
(APE) from Santa Clara so that one could do UI-based job management of
multi-class workloads.
Cheers,
Mike
On 3/6/26 11:37 AM, Calvin Dani wrote:
Hi,
This looks exciting. I had two feature suggestions that might help.
*1. Reusable variables for large embeddings in the UI*
When working with high-dimensional embeddings, it becomes difficult to
navigate queries in the UI because the vectors are very large. It would be
helpful if the UI allowed defining variables that store large embeddings
and can be reused across queries instead of repeatedly pasting the full
vector into the query editor.
One idea is to allow a *UI-only variable syntax*, for example using a $
prefix (e.g., $query_embedding). The UI could substitute the variable
before execution, so this would not require any change to *SQL++* itself.
*2. Profile option with execution plan and timing*
It would also be helpful to have a *Profile* option in the UI that shows
the execution plan with profiled timing. Currently we run profiling through
curl.
In the *old UI (:19004)* there was also a *string-only plan view*, which
does not appear to be present in the new UI.
Just some suggestions!
Regards
Calvin Dani
On Wed, Feb 18, 2026 at 11:22 AM Suryaa Charan Shivakumar <
[email protected]> wrote:
Hi everyone,
Hope you are doing well. I wanted to start a discussion about the AsterixDB
dashboard and whether it might be time to rethink it. The current
dashboard is Angular-based and has quite a bit of tightly coupled
integration with the Maven build. Since most of our team works primarily in
Java, needing Angular expertise for even small changes has become a
long-term maintainability issue. On top of that, the codebase itself feels
dated and likely hasn’t seen much active maintenance in a few years, which
could introduce dependency or security concerns as well. It might be worth
considering a fresh dashboard that is easier for a Java-heavy team to
maintain and integrates more naturally with the Maven lifecycle.
I’ve been experimenting with a small prototype using Vaadin. So far it has
been nice to work with mostly Java, fewer files, and much simpler to
extend. It also feels very LLM-friendly and easier to maintain than the
current setup. The only real concern I see with Vaadin is that it’s
server-side rendered, which may be unnecessary for our use case and could
be slightly heavy compared to lighter approaches. Because of that, I
wanted to open up a broader discussion on direction. Some possible options
could be Vaadin, a J2CL-based approach, or even something lightweight like
HTMX.
The main goal would be long-term maintainability and smooth integration
with our existing Java/Maven workflow. This also feels like a good
opportunity to improve the overall UX of AsterixDB. Many useful APIs we
already have are either undocumented or not easily accessible from a UI,
which makes day-to-day development harder than it should be.
A refreshed dashboard could expose things like running requests across the
cluster, killing queries via clientContextID, storage stats, feeds, make it
easier to deploy and manage UDFs, async queries, multi-statement execution,
query profiling, DOT plan rendering, warnings, etc improving Admin
observability and Developer experience. I use many of these regularly via
APIs and having them visible in one place would be very helpful. Would
love to hear your thoughts: Should we consider replacing the current
dashboard? Any strong opinions on framework direction? What features would
you want in a modern AsterixDB UI?
Eventually the UI should also evolve to support upcoming AI-driven
features, helping developers write better queries and explore plans without
constantly switching tabs to ChatGPT… assuming developers are actually the
ones using the dashboard xD
Hoping this thread can also serve as a place to collect ideas and improve
the overall developer/admin/user experience around AsterixDB.
Best,
Suryaa
