The default install works, but it is generic. These ten customizations shape the lakehouse around your business: how the data is modeled and partitioned, how Grafana looks, and how well the whole stack is locked down. Some take the agent minutes; a couple take an afternoon. It will tell you which is which before it starts.

1. Design a star schema for your data

“Orders table” is a fine start, but analytics gets easier on a proper model: one fact table for events like orders, plus dimensions for customers, products, and dates. The agent reviews your raw tables, proposes keys and relationships, builds the dimensional tables as Iceberg tables in the catalog, and rewrites your main queries against them. Future questions get shorter, cleaner SQL because the joins are decided once, in the model, instead of being reinvented per dashboard. Try: “Design a star schema with orders as the fact table and customers, products, and dates as dimensions, then migrate my dashboards to it.”

2. Tune partitioning and sort order

Iceberg’s hidden partitioning means you can change how data is physically grouped without rewriting a single query. If your dashboards filter by day and by customer, the agent repartitions by day, sets a sort order on customer ID, and rewrites the affected files in place. It benchmarks your slowest query before and after, so you see the win in numbers rather than promises. Try: “Repartition the events table by day instead of hour and sort by customer_id, then show me the before-and-after query times.”

3. Build a curated metrics layer

Nothing starts arguments like two people computing “revenue” two different ways. Have the agent create a set of DuckDB views — one per KPI, with filters and definitions baked in — that everyone queries instead of raw tables. Dashboards and ad-hoc questions all read the same numbers, and when a definition changes, it changes in one place. Try: “Create DuckDB views for revenue, active customers, and repeat purchase rate using our agreed definitions, and document what each one means.”

4. Brand your Grafana

The default Grafana looks like everyone else’s Grafana. The agent sets your organization name and logo, picks the default theme, sets a proper home dashboard, and hides the plugins nobody uses. These are small changes, but the tool starts feeling like yours, which matters when you show it to the team or a client. It also updates the org preferences so the branding survives a restart. Try: “Rebrand Grafana with our logo and company name, default to dark theme, and make the sales overview the home dashboard.”

5. Give each team its own space

Once more people use the dashboards, editing collisions start: someone renames a panel and three teams lose the chart they relied on. The agent creates Grafana teams and folders with editor or viewer rights per group, and scopes MinIO policies so each team reads only its own buckets. People stop being afraid they will break someone else’s work, and you stop mediating panel disputes. Try: “Set up Grafana teams so finance can edit the revenue dashboards but marketing can only view them.”

6. Put everything behind proper HTTPS

Out of the box, consoles often answer on plain HTTP, which is not how you want credentials and business data traveling across a network. The agent generates or installs TLS certificates for Grafana and the MinIO console, redirects HTTP traffic to HTTPS, and then confirms the DuckDB-to-MinIO path still works with the new endpoints. It also updates the console URLs so old bookmarks do not rot. Try: “Install proper TLS certificates on Grafana and the MinIO console and force all HTTP traffic onto HTTPS.”

7. Set retention and lifecycle rules

Raw uploads, logs, and old snapshots each deserve a different shelf life, and MinIO lifecycle rules are how you say it. The agent sets rules so raw landing files expire after 30 days, audit logs rotate on schedule, and curated tables are kept indefinitely. Storage stops growing forever, and the rule report is right there when finance asks where the disk space went. Try: “Keep raw uploads for 30 days, delete anything older in the landing bucket, and never auto-expire the curated tables.”

8. Precompute slow dashboard panels

If a panel takes 40 seconds, nobody waits for it, and the dashboard quietly stops being used. The agent finds the expensive queries behind your panels, builds nightly aggregate Iceberg tables for them, and repoints the panels at the aggregates. Your morning dashboards load in a blink because the heavy math happened at 3am, and the raw detail is still there when you need to drill down. Try: “Find the slowest panels on my main dashboard, build nightly aggregate tables for them, and switch the panels over.”

9. Turn on audit logging

When something goes missing, “who deleted it?” should have an answer. The agent enables MinIO audit logging and Grafana’s usage and access logs, ships them to a dedicated bucket with its own lifecycle rules, and writes a small helper script so you can ask it to search them in plain language later. The logs live on your server, under your control, not in a vendor’s account. Try: “Enable audit logging for MinIO and Grafana, keep the logs in a separate bucket for a year, and make sure I can search them by asking you.”

10. Write a living data catalog

A lakehouse without documentation is a filing cabinet with no labels. The agent generates a catalog page straight from the live catalog: every Iceberg table, every column, the current partitioning, with room for one-line descriptions you fill in. It adds a refresh step it re-runs whenever schemas change, so the docs never quietly rot while the tables move on. New people onboard without archaeology, and old questions have a place to start. Try: “Generate a data catalog listing every Iceberg table and its columns, let me add descriptions, and refresh it whenever a schema changes.”

See it in action

Official walkthroughs from the MinIO and DuckDB teams:

Worth a watch next:

• Storage and encryption in DuckDB — how DuckDB handles storage and encryption under the hood, the same knobs you tune when hardening the stack.
• DuckLake v1.0: Developer Discussion — a developer-level discussion of the DuckLake layer this stack builds on, for when you want the deeper customization options.

Customize in the order that hurts most: usually the data model first, then access control, then the polish. The agent can plan the whole sequence as one piece of work if you ask. Data Lakehouse (Iceberg + MinIO + DuckDB + Grafana) on OpenSysLab