Your dashboards are only as fresh as your last successful reload. If that sentence makes you wince — because you've lived it — this article is for you.
QlikView was genuinely innovative when it launched. The associative engine, the in-memory model, the ability to click any data point and watch everything else respond instantly: it changed what people expected from business intelligence. But the architecture underneath that experience was built for a world where data lived in files and on-premise databases, where getting data into a BI tool meant extracting it first, then loading it, then hoping nothing broke overnight.
That world is gone. Most organisations with serious data operations have moved to Snowflake, BigQuery, Databricks, or Redshift. The data is already there, already fresh, already governed. The question is whether your BI layer can work natively from that foundation — or whether it still needs to pull data out, transform it in scripts, store it in QVD files, reload it on a schedule, and monitor the whole pipeline for failures. This article looks at what that choice actually costs, and where Astrato fits for teams ready to drop the extract layer entirely.
TL;DR
Astrato is the right fit if:
- Your data lives in Snowflake, BigQuery, Databricks, Redshift, or ClickHouse and you want dashboards that reflect it live — no reloads, no QVD files, no pipelines to operate
- Your business users raise tickets for every dashboard change because QlikScript is the only way to modify business logic
- You're building customer-facing analytics into a SaaS product and need white-label embedding, usage-based pricing, and multi-tenant isolation by design
- You're on QlikView and the September 2027 end-of-support deadline is making you plan a migration — and you'd rather land somewhere that won't need another migration in five years
- You want native writeback: capturing decisions, updating records, or running lightweight workflows from within dashboards
- Your BI team is the bottleneck, not because they're slow, but because every question from Finance or Marketing requires a developer to write or modify script
QlikView may still be the right call if:
- You have a large, stable QlikView deployment with well-maintained QVD layers and no immediate cloud migration pressure — the 2027 deadline is real but not every team needs to act in 2025
- Your use case is primarily read-only guided analytics for a trained internal user base that knows how to work within QlikView's model
- You have a heavy NPrinting deployment for pixel-perfect scheduled reporting and want to delay rebuilding that infrastructure
- Your organisation's data hasn't moved to the cloud and on-premise BI remains the right architecture for your environment
Quick comparison: Astrato vs QlikView
QlikView standalone licences discontinued 2021. Current release (v12.100) end-of-support: September 30, 2027.
What is Astrato?
Astrato is a warehouse-native BI platform. Every query runs live against your cloud data warehouse — Snowflake, BigQuery, Databricks, Redshift, ClickHouse, or PostgreSQL — with no extraction, no scheduled refresh, and no data copies sitting in a separate engine. When your data changes, your dashboards reflect it. No intervention required.
The shared semantic layer is where business logic lives. Metrics and dimensions are defined once by the data team and consumed everywhere: dashboards, embedded analytics, reports, and AI queries all draw from the same governed definitions. Finance and Marketing stop arguing about whose revenue number is correct because there is only one.
Astrato's three core use cases are guided self-service BI for business users who shouldn't need to write SQL, customer-facing embedded analytics for SaaS companies building data into their products, and data apps with native writeback for teams that need to act on what they see — not just view it.
What is QlikView?
QlikView is Qlik's original BI platform, launched in the 1990s and built on the QIX associative engine — a genuinely distinctive piece of technology that lets users explore data by clicking any value and instantly seeing what associates with it across every dimension in the dataset. For teams doing exploratory analysis on pre-loaded datasets, this remains compelling.
The platform is a component of Qlik's broader portfolio. Qlik itself was taken private by Thoma Bravo in 2016 and has since received a minority investment from ADIA (Abu Dhabi Investment Authority), with Thoma Bravo remaining the majority shareholder. Today, Qlik's active development focus is Qlik Cloud; QlikView is in maintenance mode. New standalone QlikView licences have not been sold since 2021, and the current release (v12.100) reaches end-of-support on September 30, 2027.
For existing QlikView customers, the practical options are migration to Qlik Cloud (which retains a reload-based architecture and its own complex pricing) or migration to a cloud-native platform that works differently from the ground up.
The extract layer: what QlikView actually costs you
Every QlikView dashboard is a snapshot. Data is extracted from source systems, transformed using QlikScript load scripts, stored in QVD files, loaded into an in-memory engine via a reload, and then served to users. What users see is the state of the data at the time of the last successful reload — not the current state of the warehouse.
That gap matters more than it sounds. A reload that runs at 2am serves correct data until noon, when a large customer account closes and the figures shift. The board deck built at 11:45am uses yesterday's numbers. Nobody knows until after the meeting. This is the invisible cost of extract-based BI: not just stale data, but stale data that looks current.
Reload failures add a different kind of cost. When a QVD pipeline breaks — because a source schema changed, a server ran out of memory, or a connection timed out — dashboards either go dark or continue showing the last successful load's data with no indication that anything is wrong. Someone on the BI team gets the alert. They fix the pipeline. They re-trigger the reload. Depending on data volume, that can take hours. This is not a hypothetical: it is a weekly operational reality for most large QlikView deployments.
Astrato removes the pipeline entirely. Queries run as pushdown SQL directly against Snowflake, BigQuery, Databricks, Redshift, ClickHouse, or PostgreSQL. The warehouse's compute handles the query. When a user opens a dashboard, they see what the warehouse knows right now — not what it knew at the last reload. There is no extract layer to operate, no QVD files to govern, no reload schedule to monitor.
For large datasets, the compute advantage is not marginal. Snowflake, BigQuery, and Databricks were purpose-built to process massive datasets at speed. Running queries against them directly means performance scales with warehouse compute — not with QlikView's server RAM or the size of what fits in memory. There is no in-memory ceiling, no server-size constraint, and no trade-off between data volume and dashboard responsiveness.
Self-service analytics: the scripting ceiling
QlikView's proposition to business users was always self-service — the ability to explore data without needing to call IT. In practice, that promise has a hard ceiling. Exploration within a pre-built app is possible. But creating a new metric, modifying a calculation, building a new chart, or changing how data is filtered requires QlikScript or Set Analysis — the proprietary scripting language that governs how data is loaded, transformed, and defined.
That means every meaningful change goes through the BI team. Marketing needs a new cohort definition. Finance needs revenue filtered by a new business unit structure. Sales needs a different time period on the pipeline dashboard. Each of these is a ticket. Each ticket joins the queue. The queue is the backlog. The backlog is the bottleneck.
New analysts joining a QlikView team typically spend months learning the scripting model before they can make meaningful contributions. That is months of ramp time before someone can change a dashboard without supervision. Astrato's no-code interface is productive from the first session — for analysts and for non-technical users in Finance, Marketing, Operations, and Sales.
Astrato's no-code builder and semantic layer were designed specifically to break that pattern. Metrics and dimensions are defined centrally by the data team — with full governance — and then made available to business users through a drag-and-drop interface that requires no SQL and no script. A Marketing analyst can build their own dashboard. A Finance manager can explore a metric they didn't know they needed. Neither of them files a ticket.
The data team's role shifts from being the people who write script for everyone else to being the people who define what can be explored and how. They set the guardrails. Users explore freely within them.
Embedded analytics: building analytics into a product, not bolting it on
QlikView was designed for internal reporting. Its embedding story reflects that. There is no native iframe or API embed path in QlikView designed for customer-facing product use cases. Organisations that need to embed QlikView dashboards into a web product must migrate to Qlik Cloud and build around Qlik's newer embedding infrastructure — iframes, the Single Integration API, or the Nebula.js framework — each of which requires real technical depth to implement and customise.
White-labelling in Qlik Cloud's OEM tier allows logo replacement and some branding adjustments, but achieving a fully custom look-and-feel requires significant development work. Multi-tenancy is possible — each customer organisation gets an isolated tenant — but provisioning tenants at scale requires custom automation that Qlik does not provide out of the box. The Qlik documentation itself notes that single-tenant multi-customer deployments are not recommended for production use cases due to PII exposure risks between customers.
Astrato was built for embedded analytics from the start. A complete dashboard, an individual chart, or an entire analytics experience embeds via a single iframe or API call. No SDK required. White-labelling covers fonts, colours, layout, and component-level styling — the Astrato interface disappears entirely into the product's design. Multi-tenancy is native: customer data isolation does not require custom automation or workarounds because the architecture assumes it from the ground up.
Pricing for embedded use cases is usage-based — no per-viewer fees as the customer base grows. A SaaS company serving 50,000 end users pays for what they use, not a licence for each viewer. Teams building customer-facing analytics on Astrato have gone from concept to live product in under 60 days.
Writeback: from dashboards that report to dashboards that act
QlikView is read-only. It was designed to surface information — not to capture what users decide to do about it. That is a reasonable design choice for a tool built in an era when BI and operational systems were separate by default. It is a meaningful constraint in 2026, when the expectation is that analytics and action live in the same place.
Consider the common scenarios: a manager reviewing a sales forecast who needs to adjust a quota. A Finance team approving budget submissions line by line. An operations lead flagging an exception and routing it to a colleague. In QlikView, all of those actions happen somewhere else — a spreadsheet, a separate application, an email. The loop between seeing the data and acting on it stays broken.
Astrato's native writeback closes that loop. Users can update records directly from a dashboard, submit decisions, capture approvals, and trigger workflows — all persisted to the cloud data warehouse in real time. The BI layer becomes operational infrastructure, not just a reporting layer. Teams that have implemented Astrato writeback describe the shift as moving from read-only visibility to genuine data ownership.
AI-powered analytics: grounded answers vs. generic ones
Both platforms have AI capabilities, but they work in fundamentally different ways. Qlik's Insight Advisor sits on top of an in-memory data model — it can surface suggested charts and answer natural language questions, but its answers are only as consistent as the underlying app's data model. Across twenty QlikView apps, the same question about revenue can return twenty different answers because the definition of revenue lives in each app's script, not in a shared layer.
Astrato's GenAI capabilities are grounded in the semantic layer. Every natural language query, every AI-generated chart summary, every measure builder suggestion draws from the same governed definitions the data team maintains. When Finance asks "what was last quarter's gross margin by product line?" and Marketing asks the same question through a different dashboard, they get the same number — because there is only one definition of gross margin.
That consistency is not a detail. It is the difference between an AI feature that creates confidence and one that creates doubt. Answers that can't be trusted don't get acted on.
Governance and security: where does the truth live?
In QlikView, row-level security is implemented through Section Access — a mechanism that filters data at the application level based on user identity. It works, and enterprise teams with QlikView expertise have built sophisticated security models with it. The limitation is where governance lives: in the BI layer, separate from the warehouse, defined and maintained per application.
Twenty QlikView apps means potentially twenty Section Access configurations to maintain. When the warehouse security model changes — a new business unit, a new data classification, a new regulatory requirement — each app needs to be updated individually. Drift is inevitable. Auditing is difficult. The people responsible for data governance in the warehouse have no direct visibility into what the BI layer is enforcing.
Astrato inherits security from the cloud data warehouse directly. Row-level security defined once in Snowflake, BigQuery, or Databricks is honoured automatically by every dashboard, every embedded chart, every report — with no duplication, no drift, and no separate configuration to maintain. The warehouse is the single source of truth for both data and access control.
Pricing: the CAL model and what comes after it
QlikView licensing stacks. A server licence covers the deployment infrastructure. Named User CALs (approximately $1,395 per user, based on community pricing data) cover individual access. Document CALs add per-document access for lower-frequency users. Session CALs and Usage CALs handle capacity-based access for anonymous or intermittent users. Annual maintenance runs approximately 20% of licence value on top. NPrinting — the scheduled reporting tool — requires a separate licence.
For a 50-person team, all-in Qlik licensing typically runs $60,000–$100,000 per year before implementation, training, or infrastructure costs. Total cost of ownership, including data engineering, typically reaches $100,000–$200,000+ annually for mid-market deployments, according to independent analyst research. Multiple reviewers note that pricing has increased meaningfully in recent years.
Astrato's per-user and usage-based pricing has no CAL layers, no stacked server licences, and no mandatory licence floor. Customers switching from QlikView consistently report 50–75% cost savings after migration. The embedded analytics pricing model — usage-based rather than per-viewer — means the cost of serving analytics to customers scales with actual consumption, not with a headcount estimate made at contract negotiation.
Migrating from QlikView: the honest picture
Migration is the word that stops most QlikView teams from acting on what they already know. It sounds like a multi-year project. In some cases, it is. But the question is not whether migration is complex — it is whether the complexity of migrating is greater than the cost of staying.
Every core QlikView concept has a direct Astrato equivalent. Set Analysis maps to Custom Measures and Object Filters. Section Access maps to passthrough authentication — security stays in the cloud data warehouse where it belongs. Streams map to Collections. NPrinting maps to Reporting and Distribution. Writeback via third-party tools maps to native writeback, built in. QVD Reloads disappear entirely, because Astrato queries live.
Astrato was built by the founding team behind Vizlib — the most widely adopted extension suite in the Qlik ecosystem, serving 1,200+ Qlik customers. The team has seen every variant of QlikView deployment and its limitations. Migration planning is built into the onboarding process, not added as a professional services engagement afterwards. Three migration paths are supported: lift-and-shift for teams that want to replicate existing apps quickly, hybrid migration for teams prioritising their highest-value dashboards first, and full redesign for teams who see the migration as an opportunity to rebuild on better foundations.
The 2027 end-of-support deadline is real. After September 30, 2027, Qlik will not provide security patches or support for QlikView. Starting a migration in 2025 or 2026 means choosing the pace. Waiting until 2027 means being forced into whatever pace the deadline allows.
When to move from QlikView to Astrato
These are signals — not a checklist. If several of them are true simultaneously, the conversation about migration is worth having now.
- Your organisation has moved data to Snowflake, BigQuery, or Databricks, but dashboards are still running on QVD refreshes that don't reflect the live warehouse
- Your BI team spends more time maintaining reload pipelines and fielding requests from business users than doing analytical work
- You're rebuilding QVD layers to handle a schema change and wondering how many times you'll do this before the 2027 deadline forces a migration anyway
- Business users in Finance, Marketing, or Operations are maintaining shadow analytics in spreadsheets because QlikView is too slow to give them what they need
- You're evaluating a product that would benefit from customer-facing analytics and QlikView's embedding story is a blocker
- The annual licence renewal conversation is getting harder to justify — especially for a product in maintenance mode with a fixed end-of-life
Frequently asked questions
What is the best QlikView alternative for cloud data teams?
Astrato is built for teams whose data lives in Snowflake, BigQuery, or Databricks and who need BI that queries that data live rather than extracting it. Unlike QlikView, Astrato requires no reload schedule, no QlikScript for self-service, and no CAL-based licensing. It delivers real-time data exploration, AI-powered analytics grounded in a semantic layer, and embedded analytics via a single iframe or API.
Why are teams leaving QlikView in 2025?
Three reasons come up consistently. First, QlikView's extract-based architecture creates ongoing operational burden — reload pipelines fail, QVD layers grow into infrastructure that nobody fully owns, and data is never truly live. Second, standalone QlikView licences were discontinued in 2021, and the product is in maintenance mode while Qlik's active development is on Qlik Cloud. Third, the September 2027 end-of-support deadline is creating urgency for migration planning. Teams leaving are choosing platforms that query data directly from cloud warehouses, without the reload overhead.
Can I migrate from QlikView to Astrato without losing my data models?
Yes. Every core QlikView concept has a direct Astrato equivalent: Set Analysis becomes Custom Measures and Object Filters; Section Access becomes passthrough authentication with security staying in the warehouse; Streams become Collections; NPrinting becomes Scheduled Reporting; and QVD Reloads disappear entirely because Astrato is live-query. Migration planning is built into the Astrato onboarding process.
Does Astrato support advanced data modelling like QlikView?
Astrato's shared semantic layer supports complex calculated measures, dimensions, multi-table joins, and business logic defined once and reused across every dashboard, report, and embedded experience. Both SQL and a no-code interface are available for building the semantic layer. Unlike QlikView, where business logic lives in individual app scripts, Astrato centralises it — one definition of revenue, one definition of margin, no reconciliation required.
Is Astrato good for embedded analytics and OEM use cases?
Embedded analytics is one of Astrato's strongest capabilities. Pixel-perfect, white-labelled dashboards embed via a single iframe or API — no SDK required. Multi-tenancy is native, with per-row security inherited from the cloud data warehouse. Teams have gone from concept to live customer-facing analytics in under 60 days. For SaaS companies that want to add interactive analytics to their product, Astrato is designed specifically for this use case.
How does Astrato handle large datasets and complex data environments?
Because Astrato uses pushdown SQL against the cloud data warehouse, it uses the warehouse's own compute for query processing. Snowflake, BigQuery, and Databricks were built to handle large datasets, complex joins, and aggregations at scale. There is no in-memory limit, no RAM ceiling, and no server-size constraint on the Astrato side. Performance scales with warehouse compute.
What does Astrato cost compared to QlikView?
Astrato offers transparent per-user, usage-based, or hybrid pricing — no stacked CAL layers, no server licences, no annual maintenance fees on top of the base cost. Customers consistently report 50–75% cost savings compared to Qlik. Exact pricing depends on deployment model and scale. The best way to compare is to book a demo — the team will walk through the numbers specific to your team size and use case.
Does Astrato support AI-powered analytics?
Astrato's GenAI capabilities are built into the platform and grounded in the semantic layer — not retrofitted. Natural language queries, chart summaries, AI-powered insights, and the measure builder all draw from the same governed definitions. That means AI answers reflect actual business logic, not generic patterns derived from the raw data. Teams get consistent, trustworthy answers without needing to configure a separate AI tool or write SQL.
What happens to QlikView after 2027?
The current QlikView release (v12.100, September 2025) reaches end-of-support on September 30, 2027. After that date, Qlik will no longer provide security patches or support. Standalone QlikView licences are already discontinued — new customers cannot purchase QlikView independently. For organisations on QlikView today, 2027 is the hard deadline. Starting a migration in 2025 or 2026 means choosing your own pace; waiting until 2027 means the timeline chooses for you.
Can QlikView connect live to Snowflake or BigQuery?
QlikView has ODBC connectors for Snowflake and BigQuery, but the primary data architecture remains extract-based. Data is still pulled into QVD files via load scripts and reloaded on a schedule. ODBC direct query is possible for some use cases but adds IT overhead and does not eliminate the reload model. Astrato's connections to Snowflake, BigQuery, and Databricks are native live-query — every dashboard query runs directly against the warehouse, every time.
What replaces Section Access from QlikView?
Astrato uses passthrough authentication — security defined in the cloud data warehouse (Snowflake, BigQuery, Databricks) is automatically honoured by Astrato without duplication or separate configuration. Row-level security defined once in the warehouse applies consistently to every dashboard, chart, report, and embedded experience. There is no separate BI-layer security model to maintain.
Final verdict
QlikView built something genuinely useful. The associative engine remains distinctive — the ability to click any value and watch everything respond is a real differentiator for exploratory analysis, and the QlikView community has spent decades developing expertise in QlikScript that has real, transferable value. For teams with stable on-premise infrastructure and no cloud migration in sight, QlikView still does what it was designed to do.
The structural problem is the architecture. QlikView was designed for a world where extracting data was the only way to work with it. Cloud data warehouses eliminated that constraint. Data that lives in Snowflake or BigQuery is already queryable, already governed, already fresh — and it doesn't need to be extracted into QVD files, reloaded on a schedule, and monitored for failures before a dashboard can show it. The reload layer is not a feature. It is overhead that cloud-native BI eliminates.
For teams on a cloud data warehouse who are facing the 2027 end-of-support deadline, evaluating customer-facing analytics, or simply exhausted by the gap between what the BI team is asked to do and what they have capacity to deliver — Astrato's architecture, semantic layer, native writeback, and embedded analytics capabilities represent a more direct path forward than migrating to Qlik Cloud and staying on an extract model with updated pricing.
Astrato is built by the team that created Vizlib, the most widely adopted Qlik extension suite, used by 1,200+ Qlik customers. The migration path from QlikView is documented, supported, and built into onboarding. The landing point is a platform on an active AI-first roadmap — not one approaching end-of-support.
Book a demo and see how Astrato runs analytics directly on your warehouse.
.avif)
