AI as an Alternative to BI – Case Study

Problem: the company has data, but no conversation with it

In theory, company data is organized. There are tables, keys, relationships, statuses, dates, contractors, invoices, products, orders and change history. In practice, for many business users an SQL database is a black box. The knowledge exists, but access to it goes through a bottleneck: an analyst, a developer, a scheduled report or a BI panel that has to be designed first.

That means a simple question can turn into a process. Someone wants to know which products are selling worse than last month. Someone else asks which customers have a growing churn risk. Management needs an answer here and now, but the reporting system only shows what was prepared earlier.

This is exactly where the gap between data and decision appears. SQL is excellent for technical users, but it is not the natural working language of a salesperson, operations manager or business owner. BI is convenient when questions repeat, but it is weaker at exploration: “check this variant too”, “what if we exclude cancelled orders”, “show only premium-segment customers”.

Why you do not always need to start with Big Data or classic BI

Big Data and BI are useful, but they are not the answer to every case. If a company stores data in a relational database and the main questions involve filtering, aggregation, comparisons, trends and record retrieval, the first problem is usually not the lack of a warehouse. The problem is the lack of a simple way to ask questions.

Classic BI works well where metrics, KPIs and dashboards are repeatable. An AI agent adds something different: flexibility. The user does not need to know which table contains a column or how customers are joined with transactions. They can start with intent.

Technical goal of the project

The goal was not to build another dashboard. The goal was to launch a private environment where a non-technical person can ask a question about data, and an AI agent can translate that intent into a safe query against an SQL database.

In practice, the project had to meet several conditions at once: the database must not be public, the admin panel must not hang on the internet, the user should work through a simple chat interface, and the agent should operate in tool mode instead of guessing an answer from model memory.

Architecture: a private system for talking to an SQL database

The design assumes that the whole setup runs on a Hetzner server with Ubuntu 24. The public internet is needed only during bootstrap. The target access path to panels, applications and services goes through Tailscale, a private network based on WireGuard. This matters because a database should not be exposed publicly just because an AI agent needs to use it.

Coolify acts as the container manager. Dify, OpenWebUI, Microsoft SQL Server, Redis, PostgreSQL, Qdrant and the plugin daemon run in one private Docker network. The important point is that Dify connects to MSSQL by container name in internal DNS, not through a public IP address.

The simplest description of the architecture is this: the user enters OpenWebUI through Tailscale, OpenWebUI talks to Dify, Dify runs the agent and calls the SQL tool, and the SQL tool queries MSSQL inside the private container network. The answer returns along the same path, but the user sees it as a normal conversation.

Component roles: what each layer does

In a project like this it is easy to throw several technology names into one bucket, even though each one is responsible for something different. Technically, each layer has a separate function, and only the combination creates a useful system.

What was implemented: from server to agent

1. Hetzner and basic server hardening

The first stage was system updates, a minimal firewall and VPS preparation. Public SSH is needed only at the beginning. After enabling Tailscale it should be closed, and incoming traffic should be limited to the private network interface. This turns the server from a classic public admin panel into a private node in the tailnet.

2. Tailscale as the only access gateway

Tailscale changes the character of the deployment. Instead of exposing Coolify, OpenWebUI, Dify and MSSQL to the internet, the system is available only to devices inside the tailnet. It is a simple decision that reduces the attack surface and the number of operational problems.

3. Coolify as the container panel

Coolify makes it possible to manage Docker applications without manually maintaining the full command stack. After installation, it should also not remain public on the administration port. Access through the Tailscale address is enough.

4. Microsoft SQL Server as the source of truth

The MSSQL database stores the data the agent queries. It is important not to map port 1433 publicly unless there is a real need. Dify should see the database through the private container network. From a security perspective, the agent should use a separate technical user with limited permissions.

5. Dify in agent mode

Dify is responsible for the agent logic: it accepts the user intent, selects a tool, builds the query, interprets the result and returns an answer that a human can understand. This is where the main value appears: the agent can use an SQL tool, but the user does not need to write SQL.

Dify is also the place where system instructions, limits and the data schema description can be added.

6. OpenWebUI as the business front end

OpenWebUI connects to Dify through an OpenAI V1-compatible endpoint. For the end user it looks like a conversation with an assistant. Under the hood, however, the assistant has access to a tool that lets it query a specific database.

How the agent understands the database if it does not know it in advance

A language model should not guess the database structure. If the user asks about “active customers”, the agent must know whether activity means a login, an order, a payment, a sales contact or no overdue balance. This is not a model problem. It is a data dictionary problem.

That is why an AI + SQL implementation should include a context layer: descriptions of tables, relationships, columns, statuses, filters and metric definitions. Without it, the agent may generate SQL that is syntactically correct but wrong from a business perspective.

What a data question looks like in practice

The user does not ask the database: SELECT ... GROUP BY .... The user asks the way they would ask an analyst:

• “Which products had the largest sales drop in the last 30 days?”
• “Show customers who have not ordered for 60 days but were active before.”
• “Compare this week’s revenue with the previous week and point out the biggest differences.”
• “Find overdue invoices and group them by salesperson.”

The agent turns the question into a plan: it recognizes entities, selects tables, creates a query, executes it through the SQL tool and then describes the result. A good implementation does not stop at “here is the table”. It should also explain how it understands the result, what matters most and where follow-up questions are useful.

Example answer: “The largest drop appears in three categories. Two of them have fewer orders but a similar average basket value. The third has both fewer orders and a lower transaction value, so it needs separate analysis.”

Flow of one question

End-to-end example: from question to answer

The easiest way to evaluate this kind of system is to follow one concrete run. The example below is simplified and uses fictional table names, but it shows the correct mechanism: the user asks a business question, the agent builds a controlled query, and the answer comes back in a human-readable form.

Example SQL generated by the agent

WITH sales AS (
  SELECT
    p.product_name,
    SUM(CASE
      WHEN o.order_date >= DATEADD(DAY, -30, CAST(GETDATE() AS date))
      THEN oi.quantity * oi.unit_price ELSE 0
    END) AS current_period,
    SUM(CASE
      WHEN o.order_date >= DATEADD(DAY, -60, CAST(GETDATE() AS date))
       AND o.order_date < DATEADD(DAY, -30, CAST(GETDATE() AS date))
      THEN oi.quantity * oi.unit_price ELSE 0
    END) AS previous_period
  FROM orders o
  JOIN order_items oi ON oi.order_id = o.id
  JOIN products p ON p.id = oi.product_id
  WHERE o.status <> 'cancelled'
    AND o.order_date >= DATEADD(DAY, -60, CAST(GETDATE() AS date))
  GROUP BY p.product_name
)
SELECT TOP (5)
  product_name,
  current_period,
  previous_period,
  current_period - previous_period AS change_value
FROM sales
WHERE previous_period > 0
ORDER BY change_value ASC;

Answer visible to the user

The agent should not finish with the table alone. A good answer says what was calculated, which filters were applied and where it is worth asking more. For example: “The largest sales drop is visible in products A, B and C. The result compares the last 30 days with the previous 30 days and excludes cancelled orders. In two products the number of transactions dropped, and in one product the average order value dropped, so it is worth checking stock availability and salesperson activity separately.”

Guardrails: what must be refined for this to be useful

Connecting a model to a database is not enough. The biggest difference between a prototype and a production tool lies in limits, context and validation. The AI agent must have freedom to ask questions about data, but it cannot have freedom to do everything.

The safest start is read-only mode, a limited table scope and a set of test questions. Only after passing tests should permissions, data sources and automations be expanded.

• Separate database user for the agent.
• Access only to tables needed in the pilot.
• Read-only access by default.
• Limit on the number of returned records.
• Timeout for computationally expensive queries.
• Logging of the user question and generated SQL.
• Blocking of data-modifying operations.
• Allowlist of tables and columns available to the agent.
• Rejection of instructions that try to change system rules or bypass limits.
• Test-question list compared with manual SQL results.

Security: why the private network is part of the product

In this project, security is not an add-on at the end. It is part of the architecture. Public ports for Coolify, OpenWebUI, Dify and MSSQL should be closed after deployment, and access should go through Tailscale. This is especially important in a system that connects an AI model with client data.

CrowdSec can make sense as additional log monitoring and brute-force detection, but if traffic is not public, its role is supportive. The biggest benefit comes from reducing exposure: fewer public services, fewer entry points and fewer things to watch.

In a classic deployment, an application panel often sits behind a public reverse proxy, the database has a mapped port, and protection relies on passwords and firewall configuration. Here the priority is different: administrative services and the database should be invisible from the public internet. Tailscale becomes the gateway, not an add-on.

Acceptance tests: how we know the system works

In a technical case study it is worth clearly separating “we installed the containers” from “the system meets the goal”. A working deployment does not only mean green statuses in Docker. It means the full flow from user to database and back is controlled, repeatable and verifiable.

• The user connects to the tailnet and sees the private environment.
• Coolify is available through a Tailscale address, not a public port.
• OpenWebUI connects to Dify through an OpenAI-compatible endpoint.
• Dify runs in agent mode and has the SQL tool configured.
• Dify sees MSSQL by container name or private network, not by public address.
• The agent answers a set of test questions consistently with manually checked SQL.
• The database is not accessible from the public internet.
• The logs can reconstruct the user question, SQL query and answer.

The most important test is simple: a non-technical person asks a business question, the system executes the correct database query, and the answer is understandable without reading SQL. If this works on real questions, the pilot makes sense.

State after deployment: what the company actually gets

After a correct launch, the user connects through Tailscale, enters OpenWebUI and talks to the agent. Through Dify, the agent uses the SQL tool and queries Microsoft SQL Server inside the private container network. This is not yet a full enterprise analytics platform, but it is a very practical bridge between the database and everyday business questions.

The greatest value appears in three places:

• Answer speed. An ad hoc question does not have to wait for a new dashboard.
• Data availability. Non-technical people can explore information on their own.
• Lower entry barrier. The company can validate the value of AI over data before investing in heavier BI or Big Data architecture.

Limitations: what this system does not promise

A good technical case study should also show the boundaries of the solution. AI + SQL does not make data automatically correct, consistent or well described. If the database contains wrong statuses, unclear definitions or historical exceptions, the agent can only inherit them.

FAQ: common questions about AI + SQL