Hi Yong, I agree with you regarding Docker Compose. The primary advantage of a standalone Docker image is that it can be pulled in a single step from a repository. I am also considering providing an archive that users can run without requiring Docker.
Regarding the CLI, thank you again for your excellent work. It has improved significantly, and I agree we can continue to refine the user experience. I believe the CLI is a vital alternative to an MCP server, as tools like Claude Code can leverage it directly without needing a local MCP server. I think improving the CLI is an important initiative. For bootstrapping, I am considering a "response file" with default entries that the server, CLI, or Console can use to set up a default catalog. The goal is to get users up and running in seconds. To clarify on the Helm Chart, I haven't heard of specific issues; it's simply that a full Helm deployment is often overkill for users who just want to test or evaluate Polaris. Regards, JB On Wed, Apr 15, 2026 at 9:33 AM Yong Zheng <[email protected]> wrote: > Hello JB, > > Thanks for bring this up. For sure I had been seeing many people reported > some basic stuff in the slack over time (maybe due to docs are hard to > follow?). > > Having an all-in-one docker file will solve the usability problem, > however, this docker image will be large large in size as spark itself is > 600-800MB already and Trino is in similar size range if I recalled). In > this case, this will no not much difference compare to a docker compose I > think? > > Regarding the CLI, we are currently using the custom parser (it works but > a bit different compared to more standard things such as click library). I > paused the better UI/UX work a bit for CLI as I also felt this is a bit > hard to maintain and wondering if we should make more refactor on this. I > haven’t get a chance to review the last community sync due to conflict of > time and work. I will catch up on those over weekends. Any feedback on this > regarding CLI if we should move towards to more standard libraries etc and > better UX (start with plaintext first). > > Regarding multiple entries had to be created before system been useable, > one possibility solution is define the basic scopes then have a config file > then just provide one liner instruction to “bootstrap” it via setup > command? But I am not sure how useful this basic setup would be. Taking > airflow RBAC as an example, out of box, there is no accounts created after > enabled RBAC and users would need to run the commands to create those > entries regardless. Thus, I am not sure about how useful the default > entities would be. > > Regarding helm chart piece, I am assuming users are compliant about the > length of values files? If that is the case, we can always give them > reference for the overwrite value file while the length one will be > packaged with the chart. > > Thanks, > Yong Zheng > > > On Apr 15, 2026, at 12:28 AM, Jean-Baptiste Onofré <[email protected]> > wrote: > > > > Hi folks, > > > > During last week’s Iceberg Summit, I had several discussions regarding > > Apache Polaris. While users are generally satisfied with its features and > > performance, a recurring piece of feedback is that Polaris is difficult > to > > get started with compared to other catalogs. Specific pain points > include: > > > > - The CLI is not intuitive. > > - There is no UI by default. > > - Multiple entities (catalogs, roles, etc.) must be created before the > > system is ready. > > - The Helm Chart is suitable for production but overkill for evaluation. > > - The Docker image is currently insufficient for quick starts. > > - The Getting Started guide and documentation are difficult to follow for > > new users. > > > > I previously started a proposal to address this (last year, "[PROPOSAL] > > User onboard..."). While we have since improved the CLI and introduced > the > > Polaris Console, I believe we need to push further on this initiative. > > > > I have a follow-up proposal with two main points: > > > > 1. I will move forward with the Polaris Console release. > > 2. I propose creating a "standalone" Docker image (e.g. > > polaris-standalone). This would be a ready-to-use image including > > PostgreSQL, Polaris Server, Polaris Console, Polaris CLI, and > potentially a > > notebook and query engine/Spark. > > > > The goal is to provide an easy-to-start image that works for small > > production environments and allows users to evolve their deployment > > incrementally. > > > > What are your thoughts? > > > > Regards, > > JB >
