We've heard it all. BI and dashboards are dead. But every time, only to rediscover its power and resurrection whenever we need grounded data analysis in any enterprise and startup space. Benn Stancil was writing about it in 2021, drawing parallels to the Salesforce "End of Software" declaration in 2000. We compare the parallels with today, as it's very interesting, as it's almost the same statement today with AI, that no more software developers are needed. But is BI dead today? It depends on what you mean by it. If you mean ad-hoc creation of a visualization, probably yes. But if you mean a well-crafted operational dashboard, where you can see your whole company performing in a split second by looking at a single, highly dense dashboard with individual charts and visualizations tailored to convey information about each sub-area in the best possible way. Probably not. However, BI was never just about dashboards. Many need the extracts BI provides from your large SAP system, linked to the right customers in the CRM, enhancing decision-making even further. It's the primitives behind the dashboards that matter more: speed, metrics, and the semantics behind them. The hard work of aligning the business, verifying the numbers are correct, and joining and aggregating at the right granularity. Data projects need governance and implementation of best practices. Otherwise, we are back to the same old way of using local Excel files, where everyone is doing their own thing with no alignment, governance, or broader verification. But most importantly, who is maintaining it all with the explosion of dashboard creation? What's the solution? In this new article, we look at how BI evolved, how dashboards are actually used today, and what remains relevant. There's a good approach that we know works well, which involves the same old ingredient that we use in the software domain: artifacts can be versioned, recoverable, and declared. BI needs trustworthy metrics, semantics, AND ownership. This can be achieved with some version of BI-as-Code, and with that, we can also generate safer visualizations. After all, the hard part was never generating visualizations; it was having metrics and a strong backend. Having a unified data interface that has an agent with access to source, ETL, and dashboard. And Amdahl's Law still applies: 50x faster generation of BI charts, but if the tools it depends on were designed for human speed with slow query APIs, no CLI support, and unversioned metrics, the overall gain collapses to 2-3x. So, the future with AI reveals why BI still matters, and it's most likely not the dashboards themself. Read more in the full article at rilldata.com/blog/ai-reveals….

Really great article by @NishantBangarwa, about the history of metrics and how «Metrics SQL», a SQL-based semantic layer that is integrated into Rill. It really goes into the details of `SQL -> Parser -> Query Compiler -> Executor -> OLAP Engine`, and how Metrics SQL is the interface to it. Worth a read.

Times are shifting rapidly toward CLI-first development. You know that's true when even email and calendar get their own Google CLIs. So why not bring that same CLI-first, developer-friendly approach to your business metrics? If you're a data engineer or analytics engineer building with agents, this one's for you. With the stack of DuckDB+MotherDuck and Rill as an agent-friendly, local-first frontend, that's exactly what's needed these days to work with agents. Especially to retrieve context from local specification of metrics and dashboard definition - getting exact context through SQL and YAML. Focusing on developer workflow with the use of Claude Code, Codex, and Cursor that can instantly update your dashboard, update metrics in the unified layer for all visualizations to pick up, or just adding new columns to the database with the DuckDB CLI, whether the data is locally or in the cloud with serverless MotherDuck. To any data engineer, this is a joy to work in, and the iteration cycles from `ambiguous prompts -> verifiable configs -> shipping visualizations` is so fast. Increasing quality by allowing domain-experts who know the business best to own more of the data stack, while everything is still versioned in git, automatable, and easy to work with. In this new essay about «Building an Agent-Friendly, Local-First Analytics Stack», we look into general data engineering workflows and working with new agent tooling, why you'd use MotherDuck, and how Rill can help you in this stack. We look at Conversational BI, where Rill turns dashboards into code (and code into agent-readable context), serving as the code abstraction layer in most cases. What I explore more: →We discuss what's next with agentic coding, no more dashboards needed? →We analyze natural language interfaces as they are convenient, but inaccurate? →Does self-serve with BI-as-Code providing the context we need? →How the language we choose matters. Looking at SQL, YAML, and how people choose languages based on Agent use (not human familiarity). And we check limitations the future holds due to the imprecise way of natural language, e.g., "give me the analytics for this week?" Did you mean "from today until last week"? Or how data workloads need to be deterministic and reproducible to backfill faulty data, but AI agents aren't that. We explore three open-source examples in the article: 1. Stack Overflow Developer Survey with zero-pipeline analytics 2. Updated Multi-Cloud Cost Analyzer to add MotherDuck with `DLT_DESTINATION=motherduck` 3. Including a real-world setup from Salomon Vaisberg from Drio Tech, how he uses Airbyte/dlt + BigQuery/MotherDuck/dbt + Rill. If you like this, read the full article at: rilldata.com/blog/building-a…. What do you think, and which agent-friendly, local-first analytics stack do you prefer these days?

I spent years working with data warehouse automation tools before the modern data stack existed. The biggest lesson? There are two approaches to generating pipelines: Parametric - you define parameters, the tool generates SQL Template-based - you write SQL templates with variables Most modern tools like dbt took the template approach. It's more flexible but requires more SQL knowledge. The automation tools took the parametric approach. Less flexible but faster for common patterns. Neither is wrong - they optimize for different teams. ssp.sh/blog/designing-a-decl…

Why are hyperscalers racing to offer managed Iceberg? Because whoever controls the catalog controls the ecosystem. If your tables are in a managed Iceberg service, you can query them from any engine - Spark, Trino, DuckDB, whatever. But your metadata stays with that provider. It's a smart strategy. Give away the format, keep the control plane. ssp.sh/blog/open-table-forma…

Today, I dig into the details of #StarRocks and how it is gaining traction in the real-time database world, with DWH-like joins and fast retrieval from a Lakehouse-native data architecture, without additional data engineering work to persist and ingest data. I look at how data can be colocated to avoid network shuffling or broadcast overhead, enabling sub-second responses for dashboards and real-time analytics. I interviewed two heavy users of StarRocks to get real-world feedback on the pros and potential cons (thank you, Eric Sun and Anton Borisov). We analyze how Coinbase, Pinterest, Fresha, and others use StarRocks in production, and why they chose it over other open-source OLAP solutions. Things that stood out to me were: Joins are the differentiator → Every person I spoke with chose StarRocks because joins actually work at speed without heavy pre-denormalization in Flink or Spark. Coinbase ran TPC-H 1TB benchmarks, in which ClickHouse failed 12 of 22 queries. Colocated joins are surprisingly simple in concept → Tables that need to join share the same bucket key, bucket count, and replica placement. Rows with the same `customer_id` always land on the same node. The join becomes local, no network shuffle. Pinterest cut p90 query latency by 50% while using only 32% of their previous Druid infrastructure. → That's roughly a 3x improvement in cost-performance. Cold S3 data still returns in 3-5 seconds → when Iceberg metadata is well-sorted and prepared with e.g., Apache Puffins. You still need good data modeling. → StarRocks doesn't eliminate architecture thinking. Colocated joins require upfront planning across tables. Partition key choices matter. #Tradeoffs: The smaller community compared to ClickHouse is one tradeoff you make. Eric mentioned that most engineers in the Bay Area haven't heard of StarRocks, which affects adoption and hiring. There's much more in the article, full interview questions, a guideline on when to use StarRocks vs. ClickHouse based on use case, how the multi-tier caching might replace traditional ETL ingestion, and how real-time updates work without merge-on-read overhead. The full article is at ssp.sh/blog/starrocks-lakeho….

Amazing talk about AI and the future of data visualization. Mike argues why dashboards won't go away (can condense so much information you'd need 10 prompts) and also certain numbers you don't want to constantly prompt. E.g. speed on your car, you don't want to ask every 10 seconds 🙂 youtube.com/watch?v=tEIQGgS4… There are many more great insights, but I'll let you discover them yourself. Thanks for sharing, Joe.