Author: Ajay Sahoo

Air-Gapped AI Analytics: Apache Superset with Local LLMs (Ollama and vLLM)

Posted on by Ajay Sahoo
Somebody senior has seen a demo. A business user types “which branches had the worst collection efficiency last quarter” and a chart appears. Now they want it in your bank, your ministry or your hospital. The demo used a public model API. Your network does not allow that. Your regulator would not accept it, and your security team stopped reading at the word “OpenAI”.The blocker is narrower than it looks. AI analytics is not impossible in a closed network; one specific payload, the prompt, has to stay inside. This post describes how we design for that. Apache Superset does what it already does well, with a text-to-SQL service in front of it. In addition, a model server you run yourself exposes the same API shape the public providers use.

Why the prompt is the blocker

A text-to-SQL request is not just the user’s question. To write SQL that runs, the model needs to know what exists. For example, the model needs table and column names, types, and which columns are measures or dimensions. It often also needs metric definitions and the conversation so far. For a regulated organisation every part of that is sensitive:

  • The question. “Show NPA movement for accounts linked to customer group X” names a customer group. Questions leak intent, investigations and names.
  • The schema. Column names such as aadhaar_hash or diagnosis_code describe what you hold and how you process it. Outsourcing and data-protection reviews treat that as information about personal data processing, not harmless metadata.
  • Sample values. If the AI layer sends distinct values so the model can match “Bhubaneswar” to a branch code, it is sending data.
  • Results. Some designs send query results back to the model to write a narrative. If those are row-level, that is a data transfer.

Good design shrinks the payload: send aggregates rather than rows, never send sample values from sensitive columns. It does not take it to zero. The question and a schema description always have to reach the model. As a result, for many regulated teams, that means a model inside the perimeter and no path to any public AI endpoint.

The reference architecture

Three components, each with one job.

Apache Superset is the governed execution layer. It holds the database connections, datasets, roles, row-level security rules, query timeouts and cache. Every SQL statement runs through Superset’s permissions as the user who asked. Therefore, it does not matter whether a person wrote it or a model did. This is the most important design choice in the stack: the model never gets a database connection of its own.

The AI service sits between the user and Superset. It works out which datasets are relevant, builds the prompt from a schema description and calls the model. It then validates the returned SQL (read-only, within allowed datasets, row-limited) and submits it for execution. Finally, it asks the model to choose a chart and explain the aggregated result. It also keeps conversation state so follow-ups inherit the previous filters.

The model server runs the model on your hardware and exposes an OpenAI-compatible HTTP API. That property matters more than which server you choose. If the AI service speaks the OpenAI chat completions protocol, switching model servers needs no code. Moving from a hosted provider to a local server is just a change of base URL and model name. Similarly, switching between local servers works the same way.

How one question flows through the stack

The request path for one question:

  • The user asks a question, authenticated through the same identity provider as Superset.
  • The AI service selects candidate datasets the user’s role can already see and builds a prompt from the question and their description.
  • The prompt goes to the local model server over the internal network.
  • The returned SQL is parsed, checked, and executed through Superset under the user’s permissions, so row-level security applies.
  • The aggregated result, not raw rows, goes back to the model to pick the visual and draft the insight.
  • Chart and text return to the user. Nothing crosses the perimeter.

Steps 2 and 4 are where governance lives. Suppose the model is only offered datasets the user is entitled to, and Superset enforces the same entitlements at execution. Then a cleverly worded question cannot reach data the user could not query by hand. If your role model is not yet trustworthy enough for that, fix it first; our notes on RBAC design for a 500-user enterprise are a reasonable start.

Ollama or vLLM

Both are open-source, both run offline once the weights are present, and both expose OpenAI-compatible endpoints. Ollama serves /v1/chat/completions, /v1/completions, /v1/embeddings and /v1/models on port 11434. vLLM’s vllm serve starts an OpenAI-compatible server on port 8000 with chat completions, completions, embeddings and more. The AI service can talk to either; the differences are in what each is optimised for.

Ollama vLLM
Design goal Simple local model running on a workstation or single server High-throughput serving
OpenAI-compatible API Yes, /v1 on port 11434 Yes, /v1 on port 8000
Default bind 127.0.0.1 (change with OLLAMA_HOST) localhost (change with --host, --port)
Concurrency OLLAMA_NUM_PARALLEL per model, default 1 Continuous batching, with PagedAttention managing KV-cache memory
Hardware GPU or CPU NVIDIA and AMD GPUs, x86/ARM/PowerPC CPUs, plugins for other accelerators
Multi-GPU scaling Not its focus Tensor, pipeline, data and expert parallelism
Model import Local GGUF or Safetensors via a Modelfile and ollama create Local model directory; quantised formats include GPTQ, AWQ and GGUF
API authentication Local server ignores the API key --api-key covers /v1, /v2 and /inference paths only
Container image ollama/ollama vllm/vllm-openai

Which one to start with

Ollama is the right first step. A pilot with a handful of analysts or a department of a few dozen users on one server fits it well. Importing a model from local files is a Modelfile and one command. Before anyone else uses it, bind it to an internal interface with OLLAMA_HOST, and raise OLLAMA_NUM_PARALLEL deliberately: its documentation notes that required memory scales with parallel requests times context length.

vLLM is the production answer once concurrency matters. When a branch network starts asking questions at 09:30 on a Monday, continuous batching is what keeps the server busy and the queue moving, and multi-GPU parallelism handles models that do not fit on one card.

Authentication is your job in both cases. Ollama’s local server does not check keys, and vLLM’s documentation says --api-key should not be relied on alone. Put the model server on a private segment reachable only from the AI service, behind a reverse proxy that terminates TLS, enforces authentication and logs requests. Treat it like a database port.

Sizing: the considerations, not a benchmark

We will not quote tokens per second for a model on a card. Those numbers depend on model, quantisation, context length, concurrency, driver and server version, and they go stale within months. How to reason about memory does not.

Weights. Roughly parameter count times bytes per parameter: two bytes at 16-bit, half that at 8-bit, about half again at 4-bit. That arithmetic tells you quickly whether a model fits on the GPUs you have.

KV cache and context. Each concurrent request holds attention state that grows with context length, and text-to-SQL prompts are long because schema descriptions are long. Ollama defaults to a 4,096-token context; a prompt describing a dozen wide tables can exceed it, and a truncated schema produces confident, wrong SQL. Measure real prompt sizes from the AI service, set the context to fit, then size memory for that context at your expected concurrency.

Capability versus size. Larger models generally write better SQL against unfamiliar schemas, but a curated semantic layer narrows the gap. Clear dataset and column descriptions and certified metrics in Superset help every model. Before buying hardware for a bigger one, check whether the smaller one fails because your schema is ambiguous.

Latency budget. One question means at least two model calls (SQL, then chart and explanation) plus the warehouse query. Decide what end-to-end time users will accept and work backwards.

The practical step is a short sizing exercise on your own hardware: a few candidate models at a couple of quantisation levels, run against your question set at expected concurrency, measured end to end. It takes days, and the numbers are yours.

Offline packaging: nothing calls home

An air gap is a property of the whole install, not the model server. Everything normally pulled from the internet has to come through your transfer process, and everything that reaches out has to be found and disabled.

Images. Pull every image on a connected build machine (Superset, its metadata database and Redis, the AI service, the model server), scan, sign and push to the internal registry. Pin versions and digests.

Model weights. Download on the connected side, record checksums, verify on arrival. For Ollama, build the model from a local GGUF file or Safetensors directory with ollama create, and point OLLAMA_MODELS at the volume where models should live. For vLLM, serve from a local directory path and set HF_HUB_OFFLINE=1 so it does not try to resolve anything from the Hugging Face Hub.

Superset outbound calls and dependencies

Superset’s own outbound calls. Superset’s FAQ states that it uses Scarf by default to collect basic telemetry through three channels: the Scarf Gateway for container images, the scarf-js npm package, and a page-view pixel. SCARF_ANALYTICS=false disables the pixel at runtime on the pre-built images; the documentation is explicit that the other two channels are opted out separately. Pulling images from your own registry removes the gateway path, and building the frontend yourself is where you control the npm package. Mapbox-based map charts need a MAPBOX_API_KEY for the external Mapbox service, so disable them or plan an internal alternative.

Dependencies. If you build any image yourself, mirror the Python and npm indexes internally. A build that fails in the air gap is the good outcome; one that succeeds because someone allowed an exception is the bad one.

Prove it. Run the full stack in a staging segment with default-deny egress and log every blocked connection for a week of real use. The list should be empty. Each entry is a setting to change or a component to replace.

Where DashboardGPT fits

DashboardGPT is the product we built on this architecture. It is managed Apache Superset 6.0 hosting with an AI layer: users ask questions in plain English, Superset runs the query, and the answer comes back as a chart with a written explanation. The default is a managed cloud workspace. For regulated teams, the on-premise edition installs with Docker Compose on a single host or on Kubernetes for larger rollouts, and the air-gapped option ships as an offline bundle and licence file, with the language model on your own GPUs and no outbound calls.

It makes the design choices described above. Only the question and a description of the relevant schema go to the model; row-level data does not, because the query runs in the analytics layer and only aggregates come back. On-premise installs point at Ollama, vLLM or any OpenAI-compatible endpoint, so the server choice stays yours. It is its own Superset workspace rather than a plugin for an existing instance: teams already running Superset often keep it for governed dashboards and use DashboardGPT for ad-hoc questions.

From the Andolasoft team: DashboardGPT

Plain-English analytics that stays inside your network

DashboardGPT’s on-premise edition installs with Docker Compose or Kubernetes, and air-gapped installs use your own models through OpenAI-compatible APIs such as Ollama or vLLM, so no prompt leaves your network.

Try DashboardGPT freeBook a demo

Evaluation and updates inside an air gap

A model that writes good SQL in January can write worse SQL after an upgrade, and in an air gap you cannot try the new version in production and roll back tomorrow. Treat models as versioned dependencies.

Build a question set early. Collect 100 to 200 real questions from pilot users, each with an answer an analyst agrees is correct. Include relative dates (“last quarter”, “month to date”), ambiguous terms your metric definitions resolve, questions that should be refused because they reach outside the user’s datasets, and follow-ups that depend on the previous answer.

Score on results, not text. Two correct SQL statements rarely match character for character. Execute both against a fixed data snapshot and compare results. Track pass rate, correct refusals, invalid SQL and latency. The harness runs inside the air gap, because the questions and snapshot are sensitive.

Promote like software. A new model, quantisation, Ollama or vLLM release, or prompt template change is a release: transferred, checksummed, evaluated in staging, promoted only if it matches or beats the current version. Keep the previous weights and image so rollback is a configuration change. Because the AI service talks to an OpenAI-compatible endpoint, old and new models can run side by side under different names.

Fix the semantic layer first. When the model gets a question wrong, the fix is often a better column description, a certified metric or a clearer dataset name, not a bigger model. Those fixes help every model you will ever run.

Agree the cadence. Quarterly model and server updates are common; security patches to Superset, the model server or base images follow your emergency change process.

Frequently Asked Questions

Can Apache Superset use a local LLM for text-to-SQL?

Yes, through a text-to-SQL service in front of Superset that calls a model server you run yourself. Superset remains the execution layer, enforcing roles and row-level security on every query. The model server, typically Ollama or vLLM, exposes an OpenAI-compatible API, so the AI service calls it as it would a hosted provider, with a different base URL and no internet access.

Should we use Ollama or vLLM for an air-gapped deployment?

Ollama is simpler for pilots and smaller groups on one server. vLLM is built for high-throughput serving, with continuous batching and multi-GPU parallelism, which matters once many users ask questions at once. Both expose OpenAI-compatible endpoints, so teams can start on Ollama and move to vLLM without changing the AI service.

What does a text-to-SQL prompt actually contain?

At minimum the user’s question and a description of the relevant schema: table and column names and types, often metric definitions and the conversation so far. Some designs also send sample values or query results. In a regulated environment all of that is sensitive, which is why the model needs to run inside the network.

Does Apache Superset make outbound calls that need to be disabled?

By default Superset collects basic telemetry through Scarf: the container image gateway, the scarf-js npm package and a page-view pixel. SCARF_ANALYTICS=false disables the pixel, and pulling images from your internal registry avoids the gateway. Mapbox-based map charts depend on the external Mapbox service. Test in a default-deny egress segment before calling the stack air-gapped.

Build It With Andolasoft

We design and run Apache Superset for organisations that cannot put their data, or their questions about it, on the public internet. A Superset Architecture Review covers what this post depends on: your role and row-level security model, the semantic layer the model will read, egress and telemetry settings, and where an AI service and model server would sit in your network. Our AI services team handles model selection, the evaluation harness and the sizing exercise on your hardware, and Superset Managed Support can run the update and promotion cycle afterwards.

If you have been asked for AI analytics and your answer so far has been “not on a public API”, talk to us. We will work out what a local-model deployment looks like in your environment, and whether DashboardGPT’s on-premise edition or a custom AI service alongside your existing Superset is the better fit.

Natural-Language Querying on Apache Superset: Build Text-to-SQL Yourself or Use a Managed AI Layer

Posted on by Ajay Sahoo
The question usually arrives in a steering meeting, phrased as if it were small: now that everyone has used a chatbot, can people not just ask Superset a question and get the chart? The honest answer is yes, but the Friday demo is not what you can give four hundred people on Monday. Turning “revenue by region last quarter” into SQL is an afternoon’s work. A layer that picks the right dataset, respects every permission you have built, refuses what it cannot answer, and stays accurate after someone renames a column is a small product with an owner.This post breaks the layer into its parts, describes what building each on Apache Superset involves, and explains where a managed option fits. We build Superset platforms and also a managed AI product on Superset, so we state that product’s limits as plainly as its strengths.

What a text-to-SQL layer actually needs

Nine parts, each of which a demo can skip and production cannot.

1. Schema and semantic context

The model can only pick the right column if names mean something; amt_2 means nothing to it. The layer needs, per dataset: business names for columns, which are measures, dimensions and dates, how metrics are defined (is revenue gross or net), and the values a filter is likely to need (“EMEA”, not “Europe”).

In Superset much of this lives on the dataset already (column labels, descriptions, temporal flags, saved metrics), and in most deployments it is half filled in. Expect the first real cost to be curating the semantic layer you thought you had.

2. Dataset selection

Three hundred datasets will not fit in every prompt, so the layer must choose candidates first, through retrieval over descriptions, a curated allow-list of “askable” datasets, or both. A wrong choice produces valid SQL against the wrong table, which is the hardest error to spot. A short allow-list of well-described, certified datasets beats retrieval over everything.

3. SQL or query generation

There are two designs, and the choice shapes everything downstream.

  • Generate raw SQL. Most expressive: joins, window functions, anything the dialect supports. Also the hardest to govern, because the output is arbitrary text that you must check before it runs.
  • Generate a structured query. The model fills in a constrained object (dataset, metrics, group-by columns, filters, time range, row limit) and your code turns it into a query. Less expressive, far easier to validate, and it maps directly onto how Superset charts already query datasets.

4. Validation and guardrails

Before execution: parse the SQL, reject anything but a single read-only statement, check every referenced table is in the selected set, and enforce a row limit and timeout. After execution: catch empty or implausible results, and know when to answer “I can’t answer that from this data” instead of drawing a confident chart. Treat user text and column values as untrusted input that cannot change what the layer may do.

5. Execution through Superset’s datasets and permissions

If generated SQL runs on a service account with broad warehouse access, it bypasses every role, dataset grant and row-level security rule you have built. The query has to run as the asking user, through Superset, so its permission checks and RLS predicates apply.

6. Chart-type selection

A correct number in the wrong chart still reads as a wrong answer: trends want lines, single values want a big-number tile, wide results want a table. Use rules on the result’s shape, or a model choice constrained to the Superset visualization types you support, so you can save the answer as a real chart.

7. Follow-up context

Questions come in threads: “revenue by region last quarter”, then “just EMEA”, then “compare with last year”. Passing the whole chat history to the model is expensive and unreliable; keeping an explicit query state (dataset, filters, measures, time range) and letting the model edit it works.

8. Cost and latency

One question can mean several model calls (selection, generation, a repair after a failed validation, a summary) plus warehouse time. Cache repeated questions, keep schema context short, use a smaller model for routing, and decide who pays the model bill.

9. Evaluation

The part internal projects skip. Keep a test set of real questions with known-correct answers and run it on every prompt, model and schema change, or you will learn that last week’s column rename broke the finance questions when someone presents a wrong number. Log real questions from day one.

What building it in-house on Superset involves

Superset gives you the execution and permission half of the problem. The language half is yours.

The REST API path

Superset’s REST API (documented at /swagger/v1 on your own instance and in the official API reference) has the endpoints an in-house layer needs:

Need Endpoint Notes
Read dataset context GET /api/v1/dataset/ and GET /api/v1/dataset/{id_or_uuid} Columns, metrics and descriptions to build the schema prompt
Run a structured query on a dataset POST /api/v1/chart/data Takes a query context (dataset, metrics, columns, filters, time range); runs through the dataset with RLS applied
Run raw SQL POST /api/v1/sqllab/execute/ Requires SQL Lab permission; RLS applies here only when the RLS_IN_SQLLAB feature flag is on
Save the answer as a chart POST /api/v1/chart/ Creates a chart with a viz_type and params users can open in Explore

The design consequences follow directly from that table:

  • The structured path is the safer default. POST /api/v1/chart/data executes against a dataset the way a chart does, so dataset permissions and row-level security rules apply without extra work. The dataset limits what you can ask, which is exactly the constraint you want for business users.
  • The raw SQL path needs more care. SQL Lab execution means the user (or the account the layer calls with) needs SQL Lab access, and per the Superset security docs Superset enforces RLS in SQL Lab only when you enable RLS_IN_SQLLAB. Keep the database’s Allow DML setting off for any connection the layer can reach, and still validate SQL yourself.
  • Call as the user, not as a service account. Whatever authenticates your layer to Superset decides whose permissions apply. If it is one powerful account, you have rebuilt the bypass described above. Your role model and, for embedded or multi-tenant setups, your row-level security design are only as good as this choice.

The MCP server path

Superset 6.1 added a built-in Model Context Protocol server. Per the official MCP server docs, it runs as a separate process (superset mcp run --host 127.0.0.1 --port 5008), exposes tools such as list_datasets, get_dataset_info, query_dataset, execute_sql, generate_chart and get_chart_data, and respects Superset’s role-based access control, so each authenticated user reaches only what their roles allow. Those docs cover the next Superset version, so check what the release you run ships before designing around it.

It is a real shortcut for the plumbing, but dataset curation, guardrails beyond RBAC, follow-up state, chart choice, model cost and evaluation are still yours. Treat it as a well-governed tool interface, not a finished natural-language feature.

The front end and the operating work

Business users will not live in a developer’s MCP client. Someone builds the question box, the answer view, the “show me the SQL” toggle analysts insist on, and the feedback button that feeds the test set. Then someone runs it: prompt and model changes, provider outages, the eval suite, the cost report. Plan for a small team over a few months for the first version and part of one person’s time to keep it accurate.

Where a managed AI layer fits

A managed option trades control for time: someone else has built the profiling, generation, guardrails, chart selection, follow-ups and front end, and keeps them working. DashboardGPT, built by Andolasoft, is one such option.

What DashboardGPT does

What it is. DashboardGPT is Apache Superset 6.0 hosting that we manage, with an AI layer on top. Business users ask questions in plain English and get charts, with the visual type matched to the answer and a written insight explaining the result and the numbers behind it. Query execution and chart rendering run on Superset 6.0. The platform profiles columns automatically into dimensions, measures and time grains, so a dataset is askable without writing a semantic model first. Selecting an answer on the canvas and asking a follow-up carries its filters, measures and time range into the next question. Answers sit on an infinite canvas as movable nodes rather than grid tiles.

How data gets in. CSV and Excel upload with no schema definition, and warehouse connections on paid tiers.

Data privacy and deployment

What goes to the model. Per the DashboardGPT security page, the question and a description of the relevant schema go to the configured AI provider. DashboardGPT does not send row-level data to the model: the query runs in the analytics layer, which returns only aggregates. You can bring your own AI provider key, held encrypted and scoped to the workspace. We use TLS for traffic and encrypt stored data at rest.

Deployment. Managed cloud by default, on-premise through Docker Compose or Kubernetes, and air-gapped installs that point at local models through OpenAI-compatible APIs such as Ollama or vLLM.

Limits to weigh before you choose

The limits, stated plainly.

  • It does not connect to your existing Superset instance. It is a separate managed Superset 6.0 workspace. Your current dashboards, datasets, roles and RLS rules do not carry over automatically, and it is not a plugin for the Superset you already run.
  • It does not inherit your governance. Access runs through its own workspaces and workspace roles, so questions that depend on your existing row-level rules argue for building.
  • It is an early-stage product. It describes the controls it has today and holds no formal certifications. If your procurement requires SOC 2 or ISO 27001 from day one, that rules it out for now.

For a team already on Superset, two patterns make sense: keep your Superset for governed dashboards and use DashboardGPT for the ad-hoc questions that now become analyst tickets, or, if you were already weighing whether to keep self-hosting, move to managed hosting and get the AI layer with it.

From the Andolasoft team: DashboardGPT

Test plain-English questions before committing to a build

DashboardGPT is a managed Apache Superset 6.0 workspace with an AI layer. Upload a CSV on the free Explore plan, ask your users’ real questions, and see how far a managed layer gets before you staff a project.

Try DashboardGPT freeBook a demo

Build vs buy: the decision table

Factor Build on your Superset Managed AI layer (e.g. DashboardGPT)
Time to first useful answer Weeks for a pilot, months for production Same day on uploaded data
Uses your existing datasets, roles and RLS Yes, if queries run as the user through Superset No; separate workspace with its own roles
Semantic context Your dataset metadata, which you curate Automatic profiling of columns
Guardrails, follow-ups, chart choice, UI You design, build and maintain them Included
Evaluation and accuracy upkeep Your test set, your team Vendor’s product work, plus your own spot checks
Data sent to the model Whatever your design sends Question plus schema description; aggregates only, no row-level data
Model choice and cost Fully yours Bring your own key; local models on on-premise installs
Deployment Wherever your Superset runs Managed cloud, on-premise, or air-gapped
Compliance evidence Inherits your platform’s No formal certifications yet
Ongoing ownership A product with a part-time owner A subscription and a workspace admin

A short way to read it:

  • Build if the answers must respect governance that only exists in your current Superset, if the questions span a complex model, or if you have a team that wants to own an AI feature for years.
  • Buy if the main demand is ad-hoc questions on a bounded set of data, if speed matters more than reusing existing rules, or if no one on the team should become the owner of an LLM pipeline.
  • Pilot both cheaply if unsure: run fifty real questions on a managed workspace with an extract, and prototype the structured-query path on two or three of your best datasets. The test set is useful either way.

Frequently Asked Questions

Does Apache Superset have built-in natural-language querying?

Not as a finished end-user feature. Superset 6.1 adds a built-in MCP server that lets AI assistants query datasets and create charts within the user’s permissions. Curation, guardrails, follow-ups, a business-user interface and evaluation are still yours to build or buy.

Is it safe to let an LLM write SQL against our warehouse?

Only with the right execution path. Run generated queries through Superset as the asking user so dataset permissions and RLS apply, prefer structured queries against datasets over raw SQL, keep DML disabled on reachable connections, enforce row limits and timeouts, and validate statements before execution. Never give the layer a service account with broader access than the person asking.

Can DashboardGPT add AI to our existing Superset deployment?

No. DashboardGPT is its own managed Apache Superset 6.0 workspace and does not connect to an existing Superset instance. Teams already on Superset typically keep their deployment for governed dashboards and use DashboardGPT for ad-hoc questions, or move to managed hosting altogether.

How do we measure whether text-to-SQL answers are accurate?

Keep a test set of real questions with verified answers, run it on every prompt, model and schema change, and track the pass rate. Add failed production questions to the set as users flag them.

Build It With Andolasoft

We help teams decide this and then do whichever half they choose. Through Superset Consulting we curate the datasets and metadata a natural-language layer depends on, design the execution path so it runs inside your roles and RLS, and build the generation, guardrail and evaluation pieces on Superset’s API or MCP server. Our AI services team handles model selection and self-hosted model setups, and an architecture review is the quickest way to find out whether your permissions are ready to sit under an AI layer. If you would rather not own any of it, DashboardGPT is the managed route, and Managed Support keeps your existing Superset running alongside it.

If someone has asked whether users can just ask questions and need an answer you can defend, talk to us. We will look at your datasets, your permission model and the questions people actually ask, and tell you which route fits.

How to Set Up Keycloak SSO for Apache Superset (OpenID Connect)

Posted on by Ajay Sahoo
Keycloak shows up wherever an organisation wants to own its identity layer: on-premise deployments, regulated environments, platforms that broker several upstream directories into one login, or simply teams that prefer open source end to end. Superset fits that stack naturally, and Flask-AppBuilder ships a Keycloak handler so the integration is configuration rather than code.

There is one trap that catches almost everyone. FAB’s Keycloak handler reads a groups claim from the user info endpoint to decide which Superset roles to assign, and a fresh Keycloak client does not include that claim. Logins succeed, everyone gets the default role, and the failure is silent. This guide fixes that in Step 1 so you never see it.

For the general mechanics of Superset authentication, reverse-proxy settings and the break-glass procedure, see our Okta guide; they apply here unchanged. This post covers what is specific to Keycloak. Written against Superset 4.x and Keycloak 24, applicable to Keycloak 17 and later (the versions without the /auth URL prefix).

Step 1: Create the Keycloak client

In the Keycloak admin console, inside the realm your users live in:

  • Go to Clients and choose Create client.
  • Client type: OpenID Connect. Client ID: superset. Give it a name and description. Next.
  • Client authentication: On (this makes it a confidential client with a secret). Authorization: Off. Under Authentication flow, keep Standard flow ticked and untick everything else; Superset only needs the authorization-code flow. Next.
  • Root URL: https://superset.example.com. Valid redirect URIs: https://superset.example.com/oauth-authorized/keycloak. Valid post logout redirect URIs: https://superset.example.com/login/. Web origins: https://superset.example.com. Save.
  • Open the Credentials tab and copy the Client secret.

The last segment of the redirect URI, keycloak, must match the provider name in superset_config.py.

Add the groups mapper

This is the step that makes role mapping work.

  • On the client, open Client scopes and click the dedicated scope named superset-dedicated.
  • Choose Add mapper, then By configuration, then Group Membership.
  • Name: groups. Token Claim Name: groups. Full group path: Off (so the claim contains superset-admins, not /bi/superset-admins). Add to ID token: On. Add to access token: On. Add to userinfo: On. Save.

FAB reads groups from the userinfo endpoint, so “Add to userinfo” is the one that matters. Turning the other two on costs nothing and helps debugging.

If you prefer Keycloak realm roles or client roles to groups, add a User Realm Role or User Client Role mapper instead, with Token Claim Name set to groups so FAB picks it up without a custom security manager. The mapping keys in Superset then become role names rather than group names.

Create groups and assign users

Under Groups, create superset-admins, superset-analysts and superset-viewers, and add users. If Keycloak brokers an upstream directory (LDAP, Active Directory, another OIDC provider), map the upstream groups into these through the identity provider’s mappers, so the Superset-facing group names stay stable even if the upstream changes.

Optionally, restrict who can log in at all: under the client’s Advanced tab, or through a client policy, require membership of a superset-users group. Users outside it are refused by Keycloak, which is preferable to being created in Superset with no useful role.

Step 2: Configure Superset

python
import os
from flask_appbuilder.security.manager import AUTH_OAUTH

KEYCLOAK_BASE_URL = os.environ["KEYCLOAK_BASE_URL"]   # e.g. https://sso.example.com
KEYCLOAK_REALM = os.environ["KEYCLOAK_REALM"]         # e.g. corp
KEYCLOAK_REALM_URL = f"{KEYCLOAK_BASE_URL}/realms/{KEYCLOAK_REALM}"

AUTH_TYPE = AUTH_OAUTH

OAUTH_PROVIDERS = [
    {
        "name": "keycloak",
        "icon": "fa-key",
        "token_key": "access_token",
        "remote_app": {
            "client_id": "superset",
            "client_secret": os.environ["KEYCLOAK_CLIENT_SECRET"],
            "client_kwargs": {"scope": "openid email profile"},
            "api_base_url": f"{KEYCLOAK_REALM_URL}/protocol/",
            "server_metadata_url": f"{KEYCLOAK_REALM_URL}/.well-known/openid-configuration",
            "access_token_url": f"{KEYCLOAK_REALM_URL}/protocol/openid-connect/token",
            "authorize_url": f"{KEYCLOAK_REALM_URL}/protocol/openid-connect/auth",
            "request_token_url": None,
        },
    }
]

AUTH_USER_REGISTRATION = True
AUTH_USER_REGISTRATION_ROLE = "Gamma"

# Keycloak group (or role) name -> Superset roles
AUTH_ROLES_MAPPING = {
    "superset-admins": ["Admin"],
    "superset-analysts": ["Alpha", "sql_lab"],
    "superset-viewers": ["Gamma"],
}
AUTH_ROLES_SYNC_AT_LOGIN = True

ENABLE_PROXY_FIX = True
SESSION_COOKIE_SECURE = True
SESSION_COOKIE_SAMESITE = "Lax"

Details worth knowing:

  • The provider name keycloak selects FAB’s handler for Keycloak 17 and later. For Keycloak 16 and earlier, whose URLs include /auth/realms/..., use the provider name keycloak_before_17 and add the /auth prefix to every URL.
  • api_base_url ends at /protocol/ because FAB’s handler requests openid-connect/userinfo relative to it. Get this wrong and the login completes but the profile fetch 404s.
  • The scope does not need groups; the mapper puts groups into userinfo regardless of scope. If you configured the mapper on a separate client scope rather than the dedicated one, add that scope’s name here.
  • FAB’s Keycloak handler returns preferred_username as the Superset username. Keycloak usernames are stable, so this is a safe default.

Realm roles mapped — now what governs dashboards?

OIDC gets people logged in; role sync, token lifetime, and RBAC design decide what they can see once they’re in. A Superset Architecture Review covers the part after the login screen.

Book a Superset Architecture Review

Step 3: Test

Restart Superset and open the login page. You should see a single “Sign in with keycloak” button.

  • Log in as a member of superset-admins. Check Settings, List Users: the user should exist with the Admin role.
  • Confirm the groups claim is actually arriving. In Keycloak, open Clients, superset, Client scopes, Evaluate, pick a user and look at Generated user info. The groups array should be present. If it is not, the mapper is on the wrong scope or “Add to userinfo” is off.
  • Log in as a viewer from a private window and confirm the restricted view.
  • Move a user between groups, sign out and in, and confirm the role changes.

Troubleshooting

Symptom Cause Fix
Every user gets the Gamma role only No groups claim in userinfo Add the Group Membership mapper with “Add to userinfo” on; check with Client scopes, Evaluate
Group names in the claim look like /bi/superset-admins Full group path is on Turn it off, or use the full path as the key in AUTH_ROLES_MAPPING
Invalid parameter: redirect_uri from Keycloak Redirect URI not in the client’s valid list, or scheme mismatch Add the exact URI; enable ENABLE_PROXY_FIX
404 after login, log mentions userinfo api_base_url wrong, usually missing /protocol/ or using the pre-17 /auth prefix Correct the URL or switch to keycloak_before_17
invalid_client Client authentication off (public client), or wrong secret Turn client authentication on and copy the secret from Credentials
mismatching_state Session cookie not sent on callback SESSION_COOKIE_SAMESITE = "Lax", SESSION_COOKIE_SECURE matching the scheme
Login loops back to Keycloak Keycloak requires a consent or a required action (update password, verify email) the user has not completed Complete the action in Keycloak, or disable consent required on the client
Works for local Keycloak users, not for brokered users Upstream identity provider mappers do not populate the groups Add identity provider mappers to place brokered users into the Superset groups

Operational notes

  • Realm boundaries. Superset can only authenticate users from the realm in its URLs. If different business units live in different realms, either broker them into one realm or configure one provider entry per realm in OAUTH_PROVIDERS; the login page then shows one button per realm.
  • Session length. Keycloak’s SSO session settings and Superset’s PERMANENT_SESSION_LIFETIME are independent. Disabling a user in Keycloak stops new Superset logins but not the current session; keep Superset’s lifetime short.
  • Back-channel logout. Keycloak can notify clients when a user logs out centrally. FAB does not consume that notification, so central logout does not end the Superset session. Rely on session lifetime instead.
  • Secret rotation. Regenerate the client secret in Keycloak and update Superset’s environment in one change window. There is no grace period for two valid secrets on a single client.
  • Air-gapped deployments. Everything here works without internet access. Both Superset and Keycloak must resolve each other’s hostnames, and Superset must trust the certificate Keycloak presents. Mount your internal CA bundle into the Superset container and point REQUESTS_CA_BUNDLE at it.

Frequently Asked Questions

Why does every Superset user get the Gamma role after Keycloak SSO?

Because the groups claim is missing from the userinfo response. A fresh Keycloak client does not emit it, Flask-AppBuilder finds no role keys, nothing matches AUTH_ROLES_MAPPING, and AUTH_USER_REGISTRATION_ROLE applies to everyone. Add the Group Membership mapper to the client’s dedicated scope with Add to userinfo turned on, then confirm it under Clients, superset, Client scopes, Evaluate before changing anything in Superset.

Which provider name should I use for Keycloak in OAUTH_PROVIDERS?

Use keycloak for Keycloak 17 and later, whose URLs are /realms/<realm>/.... For Keycloak 16 and earlier, use keycloak_before_17 and add the /auth prefix to every URL. The provider name also has to match the last segment of the redirect URI registered on the client, so changing one means changing the other.

Can Superset authenticate users from more than one Keycloak realm?

Not through a single provider entry, because the realm is baked into the URLs. Either broker the other directories into one realm through Keycloak’s identity provider mappers, which is the cleaner option, or add one entry per realm to OAUTH_PROVIDERS. The second approach puts one sign-in button per realm on the Superset login page, which users find confusing beyond two.

Does Keycloak back-channel logout end the Superset session?

No. Keycloak can notify clients when a user logs out centrally, but Flask-AppBuilder does not consume that notification, so a central logout leaves the Superset session running until it expires. The same applies to disabling a user: new logins stop immediately, the current session does not. Keep PERMANENT_SESSION_LIFETIME to a working day or less and treat it as the real revocation window.

Build It With Andolasoft

Once Superset trusts Keycloak, the role mapping above becomes the front door to everything else: which roles reach which datasets, how row-level security narrows them, and who gets SQL Lab. A Superset Architecture Review looks at authentication, RBAC and RLS together, alongside caching, async queries and upgrade readiness, and delivers a written report in five working days. For a self-hosted platform that stays patched and monitored without your team on call, air-gapped deployments included, see Managed Support, and for the wider set of controls, our post on governance and security for Superset deployments.

If you are running Keycloak in front of a self-hosted Superset and the group mapping has never quite been right, talk to us. We will trace a real login end to end, show you where the claim is being lost, and give you a fixed-scope plan for the role model behind it.

5 Signs You Need a Successful Digital Strategy & Transformation

Posted on by Ajay Sahoo
⚡ TL;DR — Signs Your Business Need Digital Strategy & Transformation

  • Businesses without a clear digital strategy risk losing customers to faster, more digitally advanced competitors offering better customer experiences.
  • Manual processes, disconnected systems, and operational inefficiencies slow business growth and reduce overall productivity.
  • Data-driven businesses make faster and smarter decisions using real-time analytics, dashboards, and predictive insights instead of manual reporting.
  • Aging IT infrastructure, outdated software, and poor scalability increase security risks, downtime, and operational costs.
  • Successful digital transformation requires not only technology upgrades but also a strong digital culture, innovation mindset, and employee adoption.
  • Andolasoft helps businesses modernize operations through cloud migration, intelligent automation, enterprise integration, data analytics, and agile product development services.

In today’s hyper-competitive landscape, digital strategy and transformation is no longer a luxury reserved for large enterprises. It is a survival imperative for startups, SMEs, and SaaS businesses alike. Every month you delay, a digitally agile competitor gains ground — faster, smarter, and at a fraction of your cost.

According to McKinsey Digital, companies that successfully execute digital transformation are 1.5x more likely to achieve sustained revenue growth above 10% per year. Yet, a staggering 70% of digital transformation efforts fail — not because the technology is wrong, but because businesses lack a clear, actionable digital strategy.

At Andolasoft, we have spent over a decade helping SMEs, SaaS companies, and growing enterprises build winning digital strategies. From intelligent automation to application modernization, we know exactly what it takes to transform a business for the digital age.

In this blog, we break down the 5 critical signs that your organization urgently needs a digital strategy and transformation — and what steps you can take right now.

Sign #1: You Are Losing Customers to Digitally Advanced Competitors

One of the clearest warning signs is customer churn. When your buyers start choosing competitors not because of price, but because of experience — faster delivery, self-service portals, mobile apps, personalized journeys — you have a digital strategy problem.

Today’s customers expect seamless omnichannel experiences. They want to interact with your brand on mobile, web, chat, and social — all connected, all instant. If your business cannot deliver that, they will simply move on.

A robust digital strategy and transformation puts the customer experience at the center. It aligns your technology, processes, and people around what your customers actually need.

6 warning signs you’re losing to digital competitors:

  • Your website takes more than 3 seconds to load on mobile devices.
  • You do not offer a self-service customer portal or 24/7 digital support.
  • Customers complain about inconsistent experiences across channels.
  • Your NPS (Net Promoter Score) has declined for two or more consecutive quarters.
  • Competitor apps and platforms are attracting your target demographic away.
  • You rely on phone and email for support while rivals offer AI-powered chat and instant resolution.

With autonomous AI assistants and digital governance solutions, Andolasoft helps you build customer-first digital experiences that convert, retain, and delight.

Sign #2: Your Internal Processes Are Slow, Manual, and Disconnected

Are your employees still working across disconnected spreadsheets? Is data siloed across departments, making collaboration difficult and reporting a nightmare? These are textbook signs of a business that has not yet embraced digital operations.

Manual, repetitive processes not only drain time and money — they introduce errors, slow down decision-making, and frustrate your best talent. When operations cannot scale, growth becomes impossible.

This is where intelligent automation and enterprise integration become game-changers. By connecting your systems and automating repetitive workflows, you free your teams to focus on strategic, high-value work.

6 signs your operations need digital transformation:

  • Employees spend more than 30% of their time on manual data entry or reporting.
  • Approvals and workflows take days instead of minutes due to email-based bottlenecks.
  • Different departments use incompatible tools with no single source of truth.
  • Onboarding new employees takes weeks because processes are not documented digitally.
  • You cannot get a real-time view of business performance without pulling data manually.
  • Errors, duplicate records, and miscommunication are common due to disconnected systems.

Andolasoft’s enterprise integration services connect your CRM, ERP, HRMS, and marketing tools into one unified ecosystem. Paired with intelligent automation, you can eliminate hours of manual work every single day.

Sign #3: You Are Making Business Decisions Without Data Insights

If your leadership team is still relying on gut feel, weekly Excel reports, or end-of-month summaries to make strategic decisions — your business is operating blind. In 2026, data is the new oil. Businesses that harness it grow faster, waste less, and pivot smarter.

According to Gartner, by 2026, organizations that are data-driven are 3x more likely to report significant improvements in decision-making compared to their peers. The question is: are you one of them?

Andolasoft’s data analytics and Superset BI services give your leadership real-time dashboards, predictive analytics, and actionable business intelligence — so you stop reacting and start leading.

6 signs your business lacks data intelligence:

  • Your monthly reports take 3–5 days to compile and are outdated by the time they’re ready.
  • You lack visibility into which products, campaigns, or customers drive the most revenue.
  • Forecasting is done manually or based on historical averages, not real trend analysis.
  • Your team debates over which data source is “correct” due to multiple disconnected tools.
  • You cannot track KPIs in real time or drill down into operational performance instantly.
  • Customer behavior, churn risk, and sales pipeline data are unavailable or difficult to access.

With AI framework services from Andolasoft, you can build predictive models and machine learning pipelines that turn raw data into competitive advantage. Our loan analytics systems and BFSI dashboards are live proof of this capability.

Sign #4: Your IT Infrastructure Is Aging and Cannot Scale

Legacy IT systems are the biggest silent killer of business growth. When your software is outdated, your servers are on-premise, your security patches lag, and your development cycles take months — you are not just slow. You are vulnerable.

As your business grows, your IT infrastructure must scale with it. If every spike in demand crashes your systems or requires expensive emergency maintenance, you have outgrown your technology stack. A successful digital strategy and transformation starts with modernizing this foundation.

Andolasoft’s cloud infrastructure services and application modernization expertise help you migrate from costly legacy systems to secure, scalable cloud-native architectures — with zero business disruption.

6 signs your IT infrastructure needs urgent modernization:

  • Your on-premise servers require expensive annual maintenance contracts and frequent downtime.
  • Deploying new software features takes weeks or months due to rigid, monolithic architecture.
  • Your business experienced a security breach or compliance failure in the last 24 months.
  • Remote work or multi-location teams struggle with access, performance, and connectivity issues.
  • Your current tools do not integrate with modern SaaS platforms, APIs, or third-party services.
  • Your IT team spends more time firefighting outages than building new capabilities.

Our enterprise IT security team ensures your transformation is protected end-to-end. Combined with software quality assurance, every system we modernize is tested, secure, and production-ready from day one.

Sign #5: Your Team Lacks Digital Skills and an Innovation Mindset

Technology alone does not drive digital transformation — people do. If your leadership team does not prioritize digital innovation, if your employees resist new tools, or if your organization does not have a culture of experimentation, your transformation will stall before it starts.

According to a Harvard Business Review study, 62% of digital transformation failures are caused by cultural resistance, not technology limitations. Building digital fluency and a growth mindset across your organization is just as important as deploying the right tools.

A strong digital strategy includes a people transformation component. This means upskilling, change management, and embedding innovation into your R&D culture so that growth becomes self-sustaining.

6 signs your team needs a digital culture reset:

  • Employees resist new software tools and revert to old habits within weeks of training.
  • Your leadership team does not include a Chief Digital Officer or technology advocate.
  • There is no budget allocated for R&D, innovation labs, or technology pilots.
  • Cross-functional digital projects consistently fail due to poor collaboration and ownership.
  • Hiring for technical roles (developers, data scientists, UX designers) is extremely difficult.
  • Your organization has not launched a new digital product, feature, or initiative in 12+ months.

Andolasoft’s Innovation & Product R&D services help you build a roadmap for sustainable digital growth. Our ReactJS development and Python development teams embed directly into your workflows to accelerate delivery and build internal digital capability.

How Andolasoft Powers Your Digital Strategy and Transformation

Recognizing these signs is the first step. Acting on them is what separates businesses that thrive from those that get left behind. At Andolasoft, we do not just consult — we execute.

Our end-to-end digital strategy and transformation services include:

  • Digital Roadmap Design — We assess your current state and build a phased transformation plan aligned to your business goals.
  • Cloud Migration & Infrastructure Modernization — Move from legacy to cloud-native with zero business disruption via our cloud infrastructure services.
  • Intelligent Process Automation — Eliminate manual bottlenecks with AI-powered intelligent automation workflows.
  • Data & BI Implementation — Build real-time dashboards and AI-driven insights with our data analytics and Superset BI services.
  • Security & Compliance — Protect your digital assets end-to-end with enterprise IT security.
  • Agile Product Development — Build and launch digital products fast with our expert ReactJS and Python development teams.

Conclusion: The Right Time to Transform Is Now

Digital strategy and transformation is not a future project — it is today’s competitive necessity. If your business shows even two or three of the five signs outlined in this blog, you are already behind the curve. The longer you wait, the costlier the catch-up becomes.

Andolasoft has helped businesses across industries — from BFSI and NBFC to SaaS and retail — build and execute digital strategies that deliver measurable results. Whether you need to modernize legacy systems, automate operations, harness data, or build a digital-first culture, we have the expertise and the track record to make it happen.

Don’t let your competition define your digital future. Partner with Andolasoft to build a digital strategy that works — and transformation that lasts.

Frequently Asked Questions

Q1: What is digital strategy and transformation?

Digital strategy and transformation is the process of integrating digital technology into all areas of a business — fundamentally changing how it operates and delivers value to customers. It goes beyond simply adopting new tools; it’s about rethinking business models, processes, and culture for the digital age.

Q2: How long does digital transformation take for an SME?

The timeline varies by scope and readiness, but most SMEs see initial results within 3–6 months of starting a focused digital transformation initiative. A full enterprise-wide transformation typically spans 12–36 months, implemented in phased stages to minimize disruption.

Q3: What is the biggest risk of not having a digital strategy?

The biggest risk is competitive irrelevance. Without a digital strategy, businesses lose customers to more agile competitors, struggle to scale operations, and face mounting technical debt. Over time, this translates into shrinking market share, higher operational costs, and an inability to attract top talent.

Q4: How much does digital transformation cost for a small or mid-sized business?

Costs depend on the scope of transformation. A phased approach — starting with process automation or cloud migration — can begin at a relatively modest investment. The key is to start with high-ROI initiatives and expand from there. Andolasoft offers flexible engagement models tailored to SME budgets.

Q5: Where should a business start with digital transformation?

Start with a digital readiness assessment to identify your biggest pain points and opportunities. Focus first on areas that directly impact customer experience or operational efficiency — such as automating manual workflows, migrating to cloud infrastructure, or implementing a BI dashboard for real-time decision-making.

How To Scale SaaS Applications Without Performance Bottlenecks

Posted on by Ajay Sahoo

Introduction: Why SaaS Scaling Is More Critical Than Ever

Every SaaS company dreams of rapid growth. But when thousands of new users flood your platform overnight, can your application keep up? Scaling SaaS applications without performance bottlenecks is no longer optional — it is the difference between retaining customers and losing them forever.

In 2025, the global SaaS market crossed $317 billion, and competition is fierce. Users expect sub-second load times, 99.99% uptime, and seamless experiences across devices. One slow API response or a database timeout can cost you thousands in churned subscriptions.

The good news? Bottlenecks are preventable. With the right cloud infrastructure strategy and architecture decisions, your SaaS platform can scale smoothly — from 100 users to 10 million.

This guide covers proven, battle-tested techniques to help startups, SMEs, and SaaS companies eliminate performance problems before they happen. Let’s dive in.

SaaS Scaling Without Bottlenecks (2026)

  • SaaS growth demands high performance, uptime, and seamless user experience
  • Bottlenecks often originate from databases, monolithic systems, and inefficient APIs
  • Auto-scaling and load balancing handle unpredictable traffic spikes
  • Database optimization, caching, and async processing improve performance significantly
  • Monitoring and CI/CD pipelines ensure continuous performance improvements
  • AI-driven automation enhances scalability and reduces downtime

What Are SaaS Performance Bottlenecks?

A performance bottleneck is any point in your system that slows down the entire application when load increases. Think of it like a traffic jam on a highway — a single lane restriction can back up miles of traffic.

Common SaaS bottlenecks include overloaded databases struggling with concurrent queries, monolithic codebases that can’t scale individual features independently, insufficient server resources during traffic spikes, inefficient API endpoints making redundant calls, no caching layer forcing every request to hit the database, and poorly optimized front-end assets slowing page loads.

Identifying these early is the first step. Our application modernization services help businesses diagnose legacy bottlenecks and re-architect systems for scale.

1. Adopt a Microservices Architecture

The single biggest architectural decision that enables SaaS scalability is moving from a monolith to microservices. In a monolithic application, every feature runs in a single codebase. When one service gets overwhelmed, the entire application slows down.

Microservices break your application into small, independently deployable services. Your billing module, user authentication, notification engine, and analytics dashboard can each scale independently — without impacting each other.

Real-World Example

A fast-growing HR SaaS company we worked with at Andolasoft processed payroll for 500 clients. During payroll run day, their monolith crashed repeatedly. After migrating to microservices using our AI framework services, their payroll service scaled to 10x load independently — without affecting other modules.

Key benefits of microservices for SaaS include independent scaling of high-demand modules, faster deployment cycles, improved fault isolation, and better team autonomy for engineering squads. Combine this with our intelligent automation solutions to auto-deploy and manage microservices efficiently.

2. Implement Auto-Scaling and Load Balancing

Auto-scaling is the ability of your infrastructure to automatically spin up new server instances when traffic spikes and remove them when load drops. Load balancing distributes incoming requests evenly across these instances.

Together, they ensure your SaaS application never gets overwhelmed — even during viral growth moments or marketing campaigns that bring unexpected surges.

Horizontal scaling adds more servers to handle load. This is preferred for SaaS because it avoids single points of failure. Vertical scaling upgrades existing servers — useful for databases but has a ceiling.

Use cloud-native auto-scaling tools like AWS Auto Scaling Groups, Google Cloud Autoscaler, or Azure VMSS. Configure scale-out triggers based on CPU usage, memory, and request count thresholds. Our cloud and infrastructure services team designs auto-scaling policies tailored for SaaS workloads.

3. Optimize Your Database for High-Traffic SaaS

The database is the most common performance bottleneck in SaaS applications. As your user base grows, poorly structured queries and missing indexes can bring your entire platform to its knees.

Read replicas distribute read queries across multiple database instances, freeing your primary database for writes. This alone can reduce database load by 60–70% for read-heavy SaaS apps. Database sharding partitions data horizontally across multiple instances for dramatically improved query performance at scale.

Connection pooling with tools like PgBouncer prevents connection exhaustion under high concurrency. Query optimization — regularly run EXPLAIN ANALYZE on slow queries, add composite indexes for frequent query patterns, and avoid N+1 query problems with eager loading in your ORM.

Our data and analytics experts help SaaS teams redesign data models for massive scale. We specialize in NBFC data analytics and BFSI analytics platforms that handle millions of transactions daily.

4. Use Caching Aggressively at Every Layer

Caching is one of the most powerful tools to eliminate performance bottlenecks. Instead of recomputing the same result on every request, you store and return pre-computed results instantly.

Application-level caching using Redis or Memcached stores session data and frequently accessed objects in memory — dropping response times from hundreds of milliseconds to under 5ms. Database query caching stores the results of expensive queries so repeated requests don’t hit the database. CDN caching for static assets serves files from edge nodes closest to the user, reducing Time to First Byte (TTFB) by up to 80%.

A well-designed caching strategy, implemented alongside our application modernization process, reduces infrastructure costs while boosting performance significantly.

5. Build for Asynchronous Processing

Not every task needs to happen in real time. Sending welcome emails, generating PDF invoices, processing video uploads — these can all happen asynchronously without blocking the user experience.

Use message queues like RabbitMQ, Apache Kafka, or AWS SQS to offload background jobs. Your main application handles user requests instantly and pushes heavy tasks to background workers.

Our enterprise integration services team builds robust queue-based architectures that handle millions of background tasks without impacting front-end performance.

Use Case: SaaS Reporting Engine

An Andolasoft client’s analytics SaaS was timing out when users requested large reports. We implemented async report generation with Kafka queues. Users now receive an email with their report link — generated in the background. Zero timeouts. Zero frustrated users.

6. Optimize Your React and Python Backends

Your front-end and back-end code directly impacts SaaS performance. Poorly written React components re-render unnecessarily. Python endpoints without async support block under concurrency.

For React performance, use React.memo() and useMemo() to prevent unnecessary re-renders, implement code splitting and lazy loading for large components, virtualize long lists with react-window, and optimize bundle size with tree shaking. Our React.js development team specializes in building high-performance SaaS front-ends that score 90+ on Core Web Vitals.

For Python backend optimization, use FastAPI over Flask for async-native APIs, implement connection pooling with SQLAlchemy async sessions, profile with cProfile and py-spy to find CPU bottlenecks, and use Celery for distributed task processing. Our Python development experts build scalable, async-first backends that handle thousands of concurrent users efficiently.

7. Set Up Monitoring, Observability and Alerting

You can’t fix what you can’t see. Comprehensive monitoring is the foundation of a scalable SaaS architecture. Without it, bottlenecks hide in plain sight until they cause outages.

APM (Application Performance Monitoring) tools like Datadog, New Relic, or Dynatrace give end-to-end visibility into every transaction — showing exactly which database query, API call, or service is causing slowdowns. Distributed tracing with OpenTelemetry tracks a single user request across all microservices. Real User Monitoring (RUM) captures performance data from actual users’ browsers, identifying geographic performance issues and JavaScript errors in production.

Our enterprise IT security team integrates monitoring with security alerting, detecting both performance issues and threats simultaneously. Combine this with our software quality assurance processes for continuous performance testing in CI/CD pipelines.

8. Implement a Robust CI/CD Pipeline

Slow, manual deployments create bottlenecks in your engineering workflow — and risky big-bang releases cause performance regressions. A CI/CD pipeline automates testing, building, and deployment so your team ships fast and safe.

Key practices for SaaS CI/CD: run automated load tests on every PR using k6 or Locust, use blue-green deployments for zero-downtime shipping, implement feature flags for gradual rollouts, and containerize with Docker and Kubernetes for consistent scaling. Our innovation and product R&D team builds CI/CD pipelines that reduce deployment risk while accelerating release velocity.

9. Leverage AI and Intelligent Automation

Modern SaaS scaling goes beyond infrastructure. AI-driven autoscaling predicts traffic spikes before they happen. Intelligent automation handles repetitive operational tasks — freeing your team to focus on growth.

Our autonomous AI assistants monitor your SaaS platform, automatically trigger scaling events, and generate incident reports without human intervention — dramatically reducing Mean Time To Recovery (MTTR).

Our digital strategy and transformation services help SaaS companies build AI-first scaling strategies aligned with long-term business goals.

How Andolasoft Helps You Scale SaaS Without Limits

Andolasoft has been helping startups and SMEs build and scale SaaS platforms for over 15 years. Our full-stack expertise spans cloud infrastructure, application modernization, AI automation, and data analytics — everything you need to grow without bottlenecks.

Whether you need to re-architect a legacy monolith, set up auto-scaling infrastructure, or optimize a slow database, our team has done it before — for clients in BFSI, NBFC, healthcare, HR tech, and e-commerce. Explore our core SaaS scaling capabilities:

Conclusion: Scale Smart, Scale Fast

Scaling SaaS applications without performance bottlenecks is a systematic effort — not a one-time fix. It requires the right architecture, smart infrastructure choices, proactive monitoring, and continuous optimization.

Start with the highest-impact changes: move to microservices, implement auto-scaling, add a caching layer, and set up APM monitoring. Then layer in async processing, CI/CD automation, and AI-driven operations as you grow.

The companies that win in SaaS are the ones that treat scalability as a core product feature — not an afterthought. Andolasoft is here to help you build that foundation. Explore our blog for more SaaS engineering best practices, or speak to our digital governance team to audit your current architecture..

Frequently Asked Questions

1.  How do I identify performance bottlenecks in my SaaS application?

Use APM tools like Datadog or New Relic to trace slow transactions. Enable slow query logging in your database. Run load tests with k6 or Locust to simulate high traffic and identify breaking points before they affect real users.

2. When should a SaaS company move to microservices?

Move to microservices when your monolith’s deployment cycles slow your team down, specific modules experience uneven load, or different parts of your app need independent scaling. For early-stage startups, a well-structured monolith is still fine.

3. What is the best database for high-scale SaaS?

PostgreSQL with read replicas works for most SaaS applications. For extremely high-read workloads, add Redis for caching. For massive write throughput, explore distributed databases like CockroachDB or Amazon Aurora.

4. How much does it cost to scale a SaaS application?

Costs vary widely. Proper auto-scaling can reduce costs by 30–50% compared to over-provisioned static infrastructure. The key is right-sizing your resources with intelligent auto-scaling policies.

5. What is horizontal vs. vertical scaling for SaaS?

Horizontal scaling adds more servers to handle load — preferred for SaaS as it avoids single points of failure. Vertical scaling upgrades a single server’s resources — simpler but limited by hardware constraints and single points of failure.

Why NBFCs Fail Without Smart Digital Transformation In 2026?

Posted on by Ajay Sahoo

The financial services landscape has changed dramatically. Yet many Non-Banking Financial Companies (NBFCs) still cling to legacy systems, paper-based workflows, and outdated processes. The result? They lose customers, fall behind competitors, and face regulatory challenges they simply cannot manage. NBFC digital transformation is no longer optional — it is the difference between survival and failure in 2026.

If you run or manage an NBFC, you need to understand why digital transformation matters — and what happens when you ignore it. This guide breaks down the real reasons NBFCs fail without smart digital adoption, and how the right technology stack can turn things around fast. Furthermore, you will discover practical steps you can take starting today.

What Is Digital Transformation for NBFCs?

NBFC digital transformation refers to the integration of modern technologies — AI, cloud computing, automation, and data analytics — into every layer of an NBFC’s operations. It covers everything from loan origination and credit scoring to customer onboarding, compliance, and collections.

According to a 2025 RBI report, over 63% of NBFCs that failed regulatory audits had outdated digital infrastructure. Meanwhile, digitally mature NBFCs reported a 47% reduction in NPAs and a 58% increase in loan processing speed. The data is clear: digital transformation drives measurable results.

At Andolasoft, we help NBFCs modernize their tech stack through our comprehensive Digital Strategy and Transformation services — built specifically for financial institutions navigating today’s complex landscape.

Top Reasons NBFCs Fail Without Digital Transformation

1. Slow Loan Processing Kills Customer Trust

Customers expect loan approvals within hours — not days. Traditional NBFCs using manual workflows take 5–7 days on average to process a single loan application. Digital-first NBFCs complete the same process in under 4 hours. That speed gap is fatal in a competitive market.

Slow processing drives customers directly to fintech competitors. They rarely come back. Without intelligent automation, NBFCs simply cannot match the speed modern borrowers demand. Additionally, manual processing creates errors that delay approvals further and erode trust.

  • Manual data entry leads to errors and costly rework
  • Duplicate verification steps waste time and staff resources
  • Customers abandon applications mid-process due to friction
  • No real-time status updates frustrate borrowers and trigger support calls

2. Poor Credit Risk Assessment Leads to High NPAs

Legacy credit scoring models rely on outdated data. They miss critical signals — social behavior, transaction history, digital footprint — that modern AI systems use to predict risk accurately. This gap leads to bad loans and rising non-performing assets (NPAs).

AI-powered credit assessment tools analyze thousands of data points in real time. They reduce default risk by up to 35%, according to industry benchmarks. Our AI Framework Services help NBFCs build smarter underwriting engines that make accurate, lightning-fast decisions.

Furthermore, AI models continuously learn from new data. They get better over time — something no traditional credit bureau model can match.

3. Regulatory Non-Compliance Creates Existential Risk

RBI regulations for NBFCs tighten every year. Manual compliance tracking fails to keep up with changing norms. NBFCs that cannot demonstrate real-time compliance reporting face heavy penalties — or worse, license cancellation.

Our Digital Governance Solutions automate compliance monitoring and reporting, ensuring NBFCs stay audit-ready at all times. As a result, compliance becomes a strength rather than a vulnerability.

  • Automated regulatory reporting reduces manual errors by 80%
  • Real-time dashboards flag compliance gaps before audits happen
  • Audit trails are maintained automatically with tamper-proof logs
  • Policy change alerts ensure your team is always up to date

4. Data Silos Block Smart Decision-Making

Most traditional NBFCs store data across disconnected systems — spreadsheets, legacy ERPs, and paper files. This fragmentation prevents leaders from getting a unified view of their portfolio. Consequently, they make reactive decisions instead of proactive ones.

Without integrated data analytics, NBFCs miss early warning signs of portfolio stress. Our Data & Analytics services and specialized NBFC analytics solutions break down silos and give leadership teams real-time intelligence to act decisively.

5. Outdated Customer Experience Drives Churn

Borrowers today expect digital-first experiences. Mobile loan applications, instant e-KYC, digital repayment — these are baseline expectations in 2026. NBFCs without modern customer portals see 3x higher churn rates than their digital counterparts.

Moreover, poor UX damages your brand reputation online. Negative reviews on Google and social platforms deter new borrowers. Our ReactJS Development team builds high-performance borrower portals and mobile apps that delight users and drive retention.

6. Security Vulnerabilities Invite Fraud and Data Breaches

Financial data is a prime target for cybercriminals. NBFCs running outdated infrastructure are easy targets. A single data breach can cost an NBFC crores in fines, litigation, and reputational damage — sometimes permanently.

Our Enterprise IT Security services implement multi-layered security frameworks — from end-to-end encryption to 24/7 threat monitoring — keeping NBFC data safe around the clock. Therefore, security becomes a competitive advantage, not a liability.

7. Inability to Scale Limits Growth Opportunities

When loan volumes surge during festive seasons or economic booms, traditional NBFCs struggle to scale operations. Infrastructure bottlenecks cause system crashes. Manual processes create backlogs that last weeks. The inability to scale fast means lost business.

Cloud infrastructure solves this entirely. Our Cloud & Infrastructure Services help NBFCs build elastic, scalable platforms that grow with demand — without downtime or performance degradation. As a result, you capture demand spikes instead of losing them.

  • Auto-scaling handles traffic spikes during peak lending seasons
  • Cloud-first infrastructure reduces operational costs by up to 40%
  • Built-in disaster recovery ensures zero data loss during outages
  • Pay-as-you-grow models align costs with actual business volume

8. Legacy Systems Are Expensive and Fragile

Old systems break often. They require expensive, specialized support staff. Security patches are costly and risky to apply. Every rupee spent maintaining legacy infrastructure is a rupee not invested in growth or customer experience.

Application modernization replaces aging systems with modern, maintainable platforms. Our Application Modernization practice migrates NBFCs from monolithic legacy stacks to cloud-native microservices — faster, cheaper, and significantly more reliable. In addition, modern systems integrate easily with new fintech partners and payment rails.

9. Poor System Integration Creates Operational Chaos

Disconnected loan management systems, CRMs, accounting software, and payment gateways create operational chaos. Staff waste hours every day reconciling data manually. Errors multiply. Customer experience suffers directly as a result.

Our Enterprise Integration services connect all your NBFC systems into a seamless, unified workflow — eliminating manual handoffs and data mismatches entirely. Furthermore, integrated systems reduce your operational headcount requirements significantly.

10. Missed Innovation Opportunities Erode Market Share

Digital transformation isn’t just about fixing what’s broken. It is about building what’s next. NBFCs that embrace innovation launch new financial products faster, enter new markets sooner, and attract better talent — creating a compounding competitive advantage.

Our Innovation & Product R&D team helps NBFCs ideate, prototype, and launch new financial products — from embedded finance to BNPL (Buy Now, Pay Later) solutions — faster than competitors can respond.

How Andolasoft Helps NBFCs Transform Digitally

Andolasoft has partnered with NBFC clients across India and Southeast Asia for over a decade. We understand the regulatory environment, the operational challenges, and the customer expectations specific to this sector better than most.

Our end-to-end NBFC transformation stack includes:

We also integrate with leading project management platforms like Orangescrum and payroll systems like INDPayroll to fully streamline NBFC back-office operations end to end.

Real-World NBFC Digital Transformation Results

One mid-sized NBFC in Bengaluru reduced their loan processing time from 6 days to just 8 hours after implementing our intelligent automation and cloud migration solutions. Their NPA ratio dropped from 9.2% to 5.7% within 18 months of going live. Their customer satisfaction score jumped by 41%.

Another NBFC in Mumbai onboarded 3x more customers in their first digital quarter by deploying our AI-powered e-KYC and credit scoring platform — with zero increase in headcount. The ROI was visible within 90 days of deployment.

These results aren’t exceptions. They are what consistently happens when NBFCs commit to smart digital transformation with the right technology partner.

Key Technologies Driving NBFC Transformation in 2026

  • AI & Machine Learning — for credit scoring, fraud detection, and customer personalization at scale
  • Cloud Computing — for scalable, cost-efficient infrastructure that grows with your loan book
  • Robotic Process Automation (RPA) — for automating repetitive back-office tasks without adding headcount
  • Blockchain — for secure, tamper-proof loan records, KYC data, and smart contracts
  • API-First Architecture — for seamless integration with fintech partners, payment gateways, and credit bureaus
  • Advanced BI & Analytics — for real-time portfolio monitoring, risk heat maps, and executive dashboards

The Cost of Inaction: What Happens Without Transformation

The cost of not transforming is far higher than the cost of transformation. NBFCs that delay digital adoption face a cascade of compounding problems. Moreover, once competitors establish a digital lead, it becomes increasingly difficult to close the gap.

  • Rising customer acquisition costs as digital competitors undercut them on speed and experience
  • Regulatory penalties for non-compliant manual processes and insufficient audit trails
  • Talent drain — top finance and tech professionals want to work with modern platforms
  • Inability to access institutional funding, which increasingly demands proven digital maturity
  • Market share erosion as neobanks and fintech lenders capture the digital-native borrower segment
  • Increased fraud exposure due to inadequate real-time transaction monitoring

How to Start Your NBFC Digital Transformation Journey

Starting a digital transformation doesn’t mean replacing everything overnight. Smart NBFCs follow a proven, phased approach that delivers quick wins while building toward long-term transformation.

  1. Audit your current state — Map existing systems, processes, and the costliest pain points
  2. Define your digital goals — Faster lending? Better compliance? Lower NPAs? Clearer targets drive better outcomes
  3. Prioritize quick wins — Automate the highest-friction processes first to build momentum and ROI proof
  4. Build a scalable foundation — Move to cloud, integrate data, and modernize core lending systems
  5. Continuously iterate — Use data analytics to measure impact, learn fast, and improve relentlessly

Andolasoft guides NBFCs through every stage of this journey. Explore our full Digital Strategy and Transformation framework to see exactly how we can accelerate your NBFC’s modernization.

Conclusion: Transform Now or Fall Behind

The question is no longer whether NBFCs should transform digitally — it is how fast they can do it. In 2026, every month of delay costs market share, regulatory goodwill, and hard-won customer trust. The NBFCs that will lead the market five years from now are already investing in AI, automation, analytics, and cloud today.

Andolasoft brings the expertise, experience, and technology stack to make your NBFC’s digital transformation successful. From loan analytics to AI assistants, from cloud infrastructure to enterprise security — we are your end-to-end NBFC transformation partner.

Frequently Asked Questions

1. What is NBFC digital transformation?

NBFC digital transformation is the process of integrating modern technologies — AI, cloud computing, automation, and data analytics — into an NBFC’s core operations. The goal is to improve efficiency, ensure compliance, reduce NPAs, and deliver better borrower experiences.

2. Why do NBFCs fail without digital transformation?

NBFCs fail without digital transformation because they cannot match the speed, compliance standards, and customer experience of digital-first competitors. They also face rising NPAs due to outdated credit models, security vulnerabilities, and inability to scale during peak demand.

3. How does AI help NBFCs reduce NPAs?

AI-powered credit scoring tools analyze thousands of data points — including behavioral, transactional, and social signals — to predict default risk far more accurately than traditional bureau models. This reduces NPAs by up to 35%, according to leading industry benchmarks.

4. What technologies are critical for NBFC digital transformation in 2026?

Key technologies include AI and machine learning for credit scoring and fraud detection, cloud computing for elastic scalability, RPA for process automation, blockchain for secure records, and advanced BI tools for real-time portfolio analytics and risk monitoring.

5. How long does NBFC digital transformation take?

It depends on the scope and complexity. Quick wins like automating loan processing can be achieved in 4–8 weeks. Full-scale core system transformation typically takes 12–18 months for a mid-sized NBFC, depending on legacy infrastructure complexity.

6. Is digital transformation affordable for small NBFCs?

Yes. Cloud-based SaaS solutions make NBFC digital transformation accessible for organizations of all sizes. Andolasoft offers phased transformation plans that fit different budget sizes and timelines, with clear ROI milestones at each stage.

7. How does Andolasoft help NBFCs with digital transformation?

Andolasoft provides end-to-end NBFC digital transformation services — from AI-powered credit platforms and cloud infrastructure to Superset BI analytics, loan monitoring systems, enterprise security solutions, and autonomous AI customer assistants.

8. What are the biggest risks of not transforming your NBFC digitally?

The biggest risks include regulatory penalties for non-compliance, rising NPAs from inaccurate credit models, customer churn to faster digital lenders, talent drain, inability to scale, cyber fraud exposure, and ultimately permanent loss of market share.

9. Can NBFCs transform digitally without disrupting ongoing operations?

Yes. A phased transformation approach minimizes operational disruption. Andolasoft uses a parallel-run methodology — deploying new systems alongside legacy ones and switching over only after thorough testing. This ensures zero downtime and business continuity throughout the process.

10. What is the first step for NBFC digital transformation?

The first step is a thorough digital readiness audit — mapping your current systems, identifying the costliest process bottlenecks, and defining clear transformation goals. From there, you prioritize high-impact quick wins. Contact Andolasoft to get your free NBFC digital readiness assessment today.