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 >
