Artificial Intelligence in Business Intelligence: how Metabase Senior Software Engineer Alexander Polyankin solves the problem of analyzing databases with millions of tables

Alexander, you played a key role in the development of Metabase, one of the most popular open-source business intelligence tools, which is now used by companies worldwide. During your time, Metabase grew from 24,000 to over 41,000 stars on GitHub, and the number of users is in the millions. What attracted you to the field of business intelligence, and why is Metabase particularly valuable for the financial technology sector?

Business intelligence attracted me with the opportunity to create products that directly influence company decision-making. In Metabase, I saw the potential to democratize access to data — to make it understandable not only for technical specialists but also for people without special training. This is especially important in the FinTech sector, where information volumes are colossal, and the speed of decision-making is critical. For the financial industry, Metabase holds particular value for several reasons. Our solution allows for the quick visualization of complex financial data without the need to write complex SQL queries. We ensure a high level of security and access control, which is critically important for financial organizations. And finally, the open-source code gives companies the ability to directly implement changes to the tool to address their specific needs, which is impossible with proprietary solutions.

Before joining Metabase, you worked as an architect at Wrike, where your work on supporting enterprise clients played a significant role in the company’s acquisition by Citrix for $2.25 billion. How did this experience influence your approach to developing scalable solutions for large data volumes in your current role?

The experience working with enterprise clients at Wrike was very valuable. There, I faced challenges that arise when working with truly large volumes of data, when you have millions of tasks and users. At Wrike, we went from a startup to a company capable of serving the largest corporations, and this taught me to think about scalability from the earliest design stages. We also created a system of micro-frontends, splitting the monolithic application into over 200 independent modules, allowing the product teams to work on and release their features separately from others.

I transferred the most useful aspects of this experience to Metabase. We have a strong focus on modular architecture, which has allowed us to accelerate the pace of development significantly. We also take into account extreme usage scenarios. We redesigned the query execution mechanism so it could effectively work with databases containing millions of tables and billions of records. And, of course, you need to anticipate the needs of enterprise clients in terms of security, auditing, and access management long before you start working with this segment. This allowed us at Metabase to avoid painful architectural changes at late stages.

Recently, you led the development of Metabot AI, a chat interface for generating queries using natural language. This is particularly challenging in specialized areas like business intelligence. Could you explain the unique technical obstacles you faced when implementing artificial intelligence in this context, especially with clients who have millions of unique tables?

The development of Metabot AI presented us with a number of serious technical challenges. The main problem is that standard approaches to natural language processing work well only in simple scenarios, where the database has a few tables with clearly defined differences. But the reality for enterprise clients is completely different — it’s a different scale altogether. Some of our clients genuinely have millions of unique tables and tens of millions of fields. Traditional approaches, where all metadata about the data schema is passed in the context of the query to the language model, simply don’t work — the context window of even the most advanced models is too small for such a volume of information. Besides this, difficulties arise with specialized terminology. General-purpose language models often confuse terms that have a strictly defined meaning in business intelligence. For example, concepts like “measure,” “dimension,” “aggregation,” or “filter” in the context of BI have a specific meaning that differs from common usage.

A separate complexity is the variability of queries. Users formulate the same analytical questions in completely different ways, using terms specific to their business. For example, the query “show sales for the last quarter” and “revenue for Q1 2025” might refer to the same data but require a different contextual understanding. To solve these problems, we developed a multi-stage approach. First, we use vectorization and semantic search to identify from millions of tables precisely those that are relevant to the user’s query. Then, we apply specialized models to understand the user’s intent and transform the query into a formalized structure. Only then do we generate the final SQL query for the database. Such a cascading approach allowed us to scale the solution to databases of practically any size.

That is a very serious challenge. You also mentioned using vectorization techniques to compare user queries with information about tables. How does this approach differ from traditional natural language processing methods, and why is it more effective for business intelligence applications?

Traditional natural language processing methods usually work on the principle of “take the entire context and generate an answer.” For modern language models, this means we pass all the information about the database structure into the prompt, and then ask the model to generate an SQL query. This approach works well for small databases but is completely inapplicable at the enterprise scale. Imagine a FinTech company’s database with thousands of tables. Passing this entire structure into the context of a language model is impossible — we would simply exceed the context window limits of even the most advanced models, like GPT-4. Vector comparison solves this problem fundamentally differently. We preemptively convert descriptions of all tables and fields into vector representations — multidimensional numerical vectors that reflect the semantics of the data. When a user asks a question, we also convert it into a vector and search for the semantically closest tables and fields in the vector space.

This approach has several advantages for business intelligence: scalability, semantic understanding, and adaptability. Searching through vector representations works very quickly, even on millions of objects, allowing us to support giant databases. Vector representations capture the meaning of terms, not just textual matches. For example, we can correctly match the query “show income” with the field “revenue,” even if these words do not literally match. And unlike manually defined rules, vector representations can capture the specific terminology of a particular company or industry. For example, in FinTech, terms like “chargeback,” “credit scoring,” or “conversion” have special meanings, and our system is capable of taking this into account. Our tests showed that such an approach increases query accuracy by 40-60% compared to traditional methods, especially in complex cases with ambiguous terminology or complex data structures.

Based on your experience with server-side rendering using GraalVM, you also worked on activating key functionality, such as notifications and report distribution via email and Slack. How important is such seamless integration for FinTech companies that need to distribute critically important insights among stakeholders?

For FinTech companies, the timely delivery of analytical data is critically important. Imagine a scenario: anomalous activity is detected in transactions, which could indicate fraud, or a sudden drop in payment gateway conversion is identified. In such situations, reaction speed is measured literally in minutes, and the team must receive notification immediately, not when someone happens to open the dashboard.

Implementing server-side rendering on GraalVM has several crucial advantages for the FinTech sector. These include the automation of critically important alerts, support for regular reporting, and the integration of analytics into workflows. Financial organizations can now set up automatic sending of notifications when certain triggers are met. Also, finance directors and department heads can receive daily or weekly reports on key metrics directly in their email inbox or Slack, without spending time logging into the system and building queries. And finally, whereas analytics used to exist in isolation — one had to specifically open Metabase to get the necessary data — now analytics is integrated into the tools teams use daily: Slack, email, CRM, and other systems. This functionality is especially important for regulatory reporting, which is critical in FinTech. Automatic generation and distribution of compliance reports significantly reduce operational risks associated with the human factor.

Given the current state of large language models in business intelligence, you noted that standard language models often struggle with specialized terminology. How, in your opinion, will the relationship between domain-specific AI models and general-purpose large language models evolve in the coming years, especially for financial data analysis?

Currently, we are observing an interesting stage in the development of artificial intelligence for business intelligence. On one hand, general-purpose large language models are becoming increasingly powerful and demonstrate impressive generalization capabilities. On the other hand, financial analytics represents a very specific domain, requiring a deep understanding of domain knowledge.

I see three main directions along which this field will develop. First, general-purpose models will specialize in financial data. This process is already actively underway: models are being fine-tuned on specialized corpora of financial texts, reports, and regulatory documents. Such an approach allows preserving the breadth of knowledge of the general model while increasing its accuracy in the financial sphere.

Second, we will see the creation of narrowly specialized models, developed from scratch for specific financial analysis tasks. For example, models for credit risk analysis, market volatility forecasting, or detecting anomalies in transaction flows. These models will be significantly smaller in size but more accurate in their narrow domain.

The third and, in my opinion, most promising direction is hybrid systems, where general-purpose and specialized models work in close conjunction. The large model is responsible for understanding the context and the general direction of the analysis, while specialized modules handle specific financial concepts and operations.

It is worth noting that in the FinTech industry, the interpretability of results plays a special role. Unlike other areas where a black-box AI might be acceptable, decisions in finance must be explainable due to regulatory requirements. Therefore, the future belongs to models that not only provide an answer but also show how they arrived at it. In the next 2-3 years, I expect that we will see an explosion of specialized FinTech models that will integrate with general-purpose LLMs via APIs, creating powerful analytical ecosystems capable of working with financial data at a level inaccessible to either of these systems alone.

In conclusion, what advice would you give to FinTech companies that aspire to implement advanced business intelligence and artificial intelligence capabilities into their own products and services?

My main advice is to start with a clear understanding of the business problem, not the technology. Too often, companies approach AI and analytics from the position of “we need to implement artificial intelligence because everyone is doing it,” rather than from the position of “we have a specific problem that can be solved using data and AI.” At the same time, it is important to invest in data quality. No analytics or AI, however advanced, will yield good results on poor-quality data. In the FinTech sphere, this is especially important: cleaning, normalization, and enrichment of financial data must become the foundation of your strategy.

For effective work, use an iterative approach. Do not try to build the perfect, all-encompassing system right away. Start with a small pilot project, get quick results, gather feedback, and scale gradually. And, of course, do not forget the human in this equation. Technologies should enhance users’ capabilities, not replace them. The best solutions in FinTech analytics are those that combine the power of AI and the expertise of financial specialists.

Pay special attention to security and compliance with regulatory requirements. In FinTech, a data breach or an incorrect analytical conclusion can have catastrophic consequences. Embed mechanisms for auditing, result verification, and access control at the earliest stages of development. And lastly — perhaps most importantly: create solutions that meet the real needs of your users. We at Metabase constantly gather feedback from our millions of users, and this allows us to develop the product in the direction that truly creates value.