Cognos Analytics or Apache Superset: when each one fits
Cognos fits best when governed, packaged enterprise reporting is the core of your analytics estate. Its strengths are Framework Manager models that control which business users can query which data, scheduled report packages, burst distribution to large recipient lists and pixel-formatted output that must match a fixed layout, such as statutory or customer-facing documents. It also fits where IBM support contracts and an in-house Cognos skill set already carry operational weight that a self-hosted project does not replace. If a renewal or per-user price change is the trigger, first check whether those report types are still in use. If they are, the cost comparison has to include the work of rebuilding them, not only the license line.
Apache Superset fits best when the main need is self-hosted, interactive dashboards over SQL datastores and the people building them are comfortable writing SQL. It is licensed under Apache-2.0 and has no paid edition, so the software line item is zero and cost moves to infrastructure, support and staff time. It connects to any SQL datastore with a Python DB-API driver and SQLAlchemy dialect, and it authenticates through database, LDAP or OAuth accounts, with group-to-role mapping through AUTH_ROLES_MAPPING. It is a weaker fit where paginated, pixel-perfect output or very large burst distributions are required. Confirm the scheduling and export features of the exact version you plan to run, currently 6.1.0, against your own report samples before you commit.
The decision turns on four things: the inventory of report types, the skills available to maintain the platform, hosting constraints and the cost of running it. Alerts, reports, async queries and thumbnails in Superset depend on a caching layer and Celery workers, so a team that wants scheduled delivery must operate Redis, workers and a PostgreSQL or MySQL metadata database. Read the Superset architecture documentation before estimating that effort. Data residency rarely decides the question alone, because Cognos can also run on your infrastructure. Ask what each option would require on your hosting, and who would carry the upgrades.
Which scenarios favor Apache Superset and which favor Cognos
This table maps common Cognos situations to the platform that fits better and the condition that would reverse the answer. Read each row against your own estate: the right choice depends on report types, network constraints and the skills your team already has.
| Scenario | Better fit | Reason and what would change the answer |
|---|---|---|
| Interactive dashboards on a SQL warehouse | Apache Superset | Superset connects to any SQL datastore with a Python DB-API driver and SQLAlchemy dialect, and dashboards are built directly on datasets. This reverses if your warehouse lacks a supported driver or you need Cognos-style governed packages across many sources. |
| Pixel-perfect, burst and bursting scheduled reports | IBM Cognos Analytics | Cognos is built for paginated, print-formatted output and bursting to recipients. Superset focuses on dashboards and alerts, so confirm whether its reports and alerts cover your output formats before committing. |
| Air-gapped or tightly isolated networks | Apache Superset | Superset runs self-hosted with no license server or vendor call-home dependency, so it can sit inside a closed network. Confirm your own install and update path, since the Apache project has no paid edition to support it for you. |
| Team with no Python or Kubernetes skills | IBM Cognos Analytics | Superset needs a metadata database, a SECRET_KEY, and optionally caching and Celery workers for alerts and thumbnails. This reverses if you engage a partner to operate it or deploy on a simpler single-host setup. |
| Estate built around Framework Manager packages | IBM Cognos Analytics | Framework Manager models, security and shared metadata do not transfer as-is. Superset rebuilds them as datasets, so this favors Cognos until the model inventory is retired or simplified. |
| Per-user licensing is the main cost pressure | Apache Superset | Superset has no paid edition and no per-user fee, so cost shifts to hosting and staff time. This reverses if staff time for building and running the platform outweighs the license savings for your user count. |
| Governed access by group or namespace | Either, with conditions | Superset supports database, LDAP and OAuth authentication and maps groups to roles via AUTH_ROLES_MAPPING. Confirm that role granularity matches your Cognos namespace and group rules before choosing. |
How Framework Manager packages map to Superset datasets
Cognos keeps business logic in one place: a Framework Manager package holds the namespaces, query subjects, relationships, calculations and security that every report and dashboard built on it inherits. Superset does not have an equivalent single artifact. Its unit of modeling is the dataset, which points at one table, view or SQL query on a database connection made through SQLAlchemy and a Python DB-API driver. Metrics and filters are defined per dataset, and charts and dashboards reuse them. A Framework Manager package that spans several subject areas will usually become several Superset datasets, and the joins between them move into SQL views or into the way each chart is built. Plan that translation before anyone opens Superset, because it determines how many places a single business rule has to be changed.
Some of the inventory can be taken from the Cognos content store and the package definitions, and some of it cannot. Package and report names, owners, schedules and the groups that can see each item are the starting list. Calculations and filters embedded in packages should be exported and documented by hand, because each one must be reproduced as a dataset metric, a SQL view column or a chart-level filter, and the result should be compared against figures Cognos already produces. Confirm with your Cognos administrators which packages are still used and which content is retired, since rebuilding unused packages is the most avoidable cost in this migration.
The governance question is the one most teams underestimate. A Superset dataset is a lighter object than a Framework Manager model. Anyone with permission to create datasets can define a metric with the same name as a governed one, and access control in Superset is applied to datasets, dashboards and roles rather than to individual subject areas or rows in a package. Decide before the build where the authoritative definitions live: in the database as views owned by a data team, in version-controlled SQL, or in Superset datasets maintained by a small group of editors. Whichever you choose, write down who approves a change to a shared metric, and check that row-level restrictions the Cognos security model enforced are reproduced in the database or in Superset's own row-level security settings and tested with accounts from each group.
Capability by capability: Cognos Analytics against Apache Superset
This table compares the main capabilities of IBM Cognos Analytics and Apache Superset that affect a migration decision. Where a Cognos detail is not covered by the public facts we hold, the cell tells you what to confirm with IBM or in your own environment. Read the Superset column as what the project documents, and the Cognos column as the questions to close before you commit.
| Capability | IBM Cognos Analytics | Apache Superset |
|---|---|---|
| Authored reports and pixel-perfect output | Confirm with IBM which report formats and layouts Cognos produces for your existing report designs. | Dashboards and charts are built in the UI. Treat pixel-formatted, page-level reports as a gap to verify before migration. |
| Scheduling and delivery | Scheduled report runs are part of Cognos; confirm burst distribution and output formats for your licence tier with IBM. | Alerts and reports run on a schedule and require the caching layer and Celery worker components. Burst-style distribution to many recipients is a gap to verify. |
| Semantic layer | Framework Manager packages model metadata. Confirm how your packages and their security rules will be exported and rebuilt. | Rebuilt as Superset datasets on top of SQL queries. There is no direct equivalent of Framework Manager packages, so model logic must be documented by hand. |
| Data source connectivity | Confirm with IBM the list of data sources supported by your Cognos version and the drivers you need. | Connects to any SQL datastore that has a Python DB-API driver and SQLAlchemy dialect. Verify the driver for each source you use. |
| Authentication | Confirm with IBM which identity options your version supports, including SSO and directory integration. | Database, LDAP and OAuth authentication through Flask-AppBuilder. OAuth2 providers such as Google and Azure are supported, and AUTH_ROLES_MAPPING maps LDAP or OAuth groups to roles. |
| Metadata storage | Cognos stores its content in a content store database. Confirm the supported database platforms and sizing with IBM. | Metadata is stored in PostgreSQL or MySQL. The SQLite default is not recommended for production. |
| Licensing and editions | Licensed per user, with editions and tiers set by IBM. Confirm current pricing and terms in your written quote. | Licensed under Apache-2.0 with no paid edition. Your cost is infrastructure and staff time, not licence fees. |
| Operating effort | IBM handles product releases, but your team still manages servers, the content store and upgrades. | You operate the application, metadata database, caching layer and workers, and follow the upgrade steps in UPDATING.md. |
Where Cognos and Superset keep data and how hosting differs
Cognos and Superset both need a place to run, a database for their own metadata and a way to reach source data. The differences sit in who operates each piece, where the metadata and query paths live, and who must produce the audit trail and compliance evidence. Review these cards before you size infrastructure or sign off on a data residency position.
Hosting model and deployment footprint
Cognos Analytics is typically deployed on-premises, in containers or as an IBM-hosted service, so the hosting decision is partly made for you by the license and the chosen deployment. Superset runs in your own cloud account or data center, and the operating team builds and patches the web application, workers and caching layer. Ask IBM which deployment options your entitlement covers, then document who owns each host, container and network segment in the target design. Confirm the hosting model before any sizing work starts.
Metadata database and its residency
Superset stores dashboards, users, charts and its own configuration in a metadata database, and the project tests PostgreSQL and MySQL for that role. Cognos keeps its content store, which holds reports, packages and schedules, in a database that IBM documents for each release. Decide where each metadata store sits, which region it lands in, who holds its backups and who can read it. The SQLite default and the Docker Compose PostgreSQL container are not recommended for production, so plan a managed or hardened database instead.
Query execution against source databases
Superset connects to source systems through Python DB-API drivers and SQLAlchemy dialects, and it sends queries to those sources at view time. Cognos reaches sources through its data source connections and, for modeled data, through packages. In both cases the warehouse or operational database executes the work, so data can stay where it is rather than being copied into a BI store. Confirm which source accounts Superset will use, what read-only grants they carry and whether caching layers would hold result sets that fall under your residency rules.
Identity integration and role mapping
Superset is built on Flask-AppBuilder and supports database, LDAP and OAuth2 authentication, with AUTH_ROLES_MAPPING translating directory groups into Superset roles. Cognos uses its own namespace and group model, which you must map to the new identity source during migration. Check that your identity provider can supply the group claims or LDAP groups Superset needs, and decide how leavers are removed from both platforms. Keep the mapping in version control so reviewers can see who gained access and why.
Audit logging and operational responsibility
Neither platform delivers a complete audit record to your SIEM by default, so you must confirm which access, export and schedule events each one logs and where those logs are retained. In a self-hosted Superset estate, your team owns the web, worker and database logs, their shipping and their retention period. Write down the events you need, such as dashboard exports, dataset changes and failed logins, and test that each one appears in the central log store before go-live.
Compliance evidence the client must produce
DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. For either platform, your organization must produce the evidence: configuration baselines, access reviews, backup restore tests, change records for upgrades and the data flow diagrams that show where each query and metadata record lives. Ask your assessor early which evidence they expect so the Superset estate is built to produce it.
Cost of ownership: Cognos licenses against Superset staff and infrastructure
The core difference in cost is where the money goes. With IBM Cognos Analytics, you pay IBM or a reseller for user licenses, usually on a recurring basis, and you also pay for the servers or containers, the content store database and the support contract that keeps them current. With Apache Superset, the Apache License 2.0 means there is no license fee, so the recurring spend shifts to infrastructure you run and to the staff who operate it. Ask your Cognos licensing contact to itemize per-user licenses by role, any capacity or processor metrics, and what the content store database requires, so you can compare each line with its Superset equivalent rather than with a single headline figure.
On the Superset side, plan for the metadata database (PostgreSQL or MySQL, using the versions listed in the configuration documentation), the optional caching layer, and the Celery worker and beat processes. The architecture documentation notes that alerts and reports, async queries and dashboard thumbnails depend on the caching and worker components, so budget for them if you plan scheduled delivery. Recurring staff time covers upgrades: back up the metadata database, run superset db upgrade and superset init, test in staging, and read UPDATING.md for breaking changes. Support is typically a retainer or internal rota, and it should be priced separately from the one-time rebuild of Framework Manager packages and reports.
One-time costs are the migration itself: inventorying content, rebuilding models as datasets, recreating dashboards and arranging a home for pixel-formatted output. Recurring costs are hosting, upgrades, monitoring and support. Cost rises with the number of reports to rebuild, the volume of scheduled deliveries, and the number of upgrade cycles you run each year. When requesting a quote from a partner, ask for the written scope and deliverables, the staff hours by role, the hosting assumptions, the upgrade and support model, and what is excluded. Any vendor or partner figure should be checked against your own inventory before you compare totals.
Running Apache Superset by deployment option
A single VM or container host suits a first production instance with a contained user group. Superset runs as application containers next to a metadata database, and alerts, reports and async queries add a caching layer and Celery worker and beat processes. The Compose PostgreSQL container and the SQLite default are useful for evaluation, but the architecture documentation does not recommend them for production, so the metadata database should be a PostgreSQL or MySQL instance your team operates.
- Metadata database: Use PostgreSQL 10 to 17 or MySQL 5.7 or 8.x, backed up and patched on a schedule. SQLite is for trials only.
- SECRET_KEY: Set a unique value in
superset_config.pybefore the first start, because Superset requires one from version 2.1.0 onward. Keep it in a secrets manager and usePREVIOUS_SECRET_KEYwhen you rotate it. - Caching and workers: Alerts and reports, async queries and dashboard thumbnails need the caching layer and Celery workers. Most installations use Redis and Celery for these, so plan them as extra containers on the host.
- Single point of failure: One host means one place for restarts, upgrades and disk failure. Document recovery steps and test them.
- Upgrades: Back up the metadata database, run
superset db upgradeandsuperset init, test in staging and read UPDATING.md first.
Before go-live, ask your team to confirm the database version against the configuration documentation and to rehearse a restore.
The Superset 6.1.0 documentation describes Kubernetes installs with the official Helm chart. The current development documentation marks that chart as deprecated, so this path fits teams that already run the chart or are standardizing on 6.1.0 for a defined period. The chart does not remove the platform work: your team still provides a reachable metadata database, secrets, persistent services for caching and the worker tier.
- Version pinning: Pin the chart and application image to the 6.1.0 release and follow the versioned Kubernetes install page for that release.
- External metadata database: Point the chart at PostgreSQL 10 to 17 or MySQL 5.7 or 8.x reachable from the cluster, with credentials stored as Kubernetes secrets.
- SECRET_KEY: Supply the key through a secret and keep it identical across pods and restarts, since Superset requires it from version 2.1.0 onward.
- Caching and workers: Enable Redis and Celery workers and beat for alerts, reports and async queries, and scale the worker tier separately from the web tier.
- Deprecation risk: Record the deprecation notice in your risk register and plan the move of values files and deployment pipelines to the operator path.
Before you commit, ask your platform team to confirm which chart versions and Kubernetes versions your cluster supports and how the project plans to handle the deprecation.
The current development documentation points new deployments to the Apache Superset Kubernetes Operator, which is the path to plan for a new build. An operator manages Superset through Kubernetes custom resources, so your platform team takes on the operator lifecycle in addition to the cluster. The same functional requirements apply: a supported metadata database, a SECRET_KEY, and caching and worker components for alerts and reports.
- Recommended path for new builds: The project's current development docs direct new deployments here, so start with the operator documentation rather than older Helm guidance.
- Metadata database and secrets: Provide PostgreSQL 10 to 17 or MySQL 5.7 or 8.x and a managed
SECRET_KEY, with rotation throughPREVIOUS_SECRET_KEY. - Workers for scheduled content: Confirm how the operator deploys Redis and Celery workers and beat for alerts, reports and thumbnails, and who sizes them.
- Operator lifecycle: Your team installs and upgrades the operator and its resources, and reviews release notes before each change.
- Ownership boundary: Ingress, TLS, network policies, backups of the metadata database and monitoring stay with your team.
Before adoption, confirm with the operator documentation which Superset releases it deploys and how it sequences the database upgrade steps.
Moving Cognos content to Apache Superset in stages
This sequence moves Cognos reports, packages and schedules into a Superset environment in controlled stages, so each group of content is inventoried, rebuilt, tested and retired on purpose rather than all at once.
Inventory reports, packages, schedules and users
The BI owner and a Cognos administrator export a list from the Cognos content store covering reports, Framework Manager packages, data sources, schedules, burst recipients and user or group memberships. Each item is tagged with its owner, last run date, consumers and business purpose. The step is done when every item has an owner and a stated purpose, and the inventory has been reviewed by the business sponsors who depend on it. The sibling export page explains what the deployment archive does and does not contain.
Retire unused and duplicate content
Working with the report owners, the team marks reports that have not run in a defined review window, duplicates of other reports, and content tied to retired systems for removal. Each retirement is recorded with the approver's name and the date. Retiring content before rebuilding keeps the Superset scope honest and avoids paying rebuild effort for reports nobody reads. The step is done when the candidate list for rebuilding is agreed and signed off in writing.
Rebuild Framework Manager models as Superset datasets
Engineers translate each in-scope Framework Manager package into Superset datasets that point at the same governed databases, using virtual datasets where SQL logic is needed. Business metrics and filters are defined once on the dataset so that dashboards share one definition. Superset connects to any SQL datastore with a Python DB-API driver and SQLAlchemy dialect, so confirm that every source has a supported driver before work starts. The step is done when reconciled totals for key metrics match the Cognos output for a agreed sample period.
Recreate dashboards and alerts
Analysts rebuild the approved reports as Superset charts and dashboards, then configure alerts and reports for the scheduled items that still matter. Alerts and reports depend on the caching layer and Celery worker components, so the team confirms those services are running before testing schedules. Test each recreated view against its Cognos original with the business owner. The step is done when every retained report has a signed-off dashboard or a documented decision to drop it.
Configure authentication and role mapping
The identity team connects Superset to the corporate directory using LDAP or an OAuth2 provider, and maps directory groups to Superset roles through AUTH_ROLES_MAPPING. Access is compared against the Cognos user and group inventory from the first step, so that each consumer keeps the data they had before. Confirm the SECRET_KEY is set explicitly, since Superset requires it to start. The step is done when test accounts for each role see only the expected datasets and dashboards.
Run the environment in staging
The platform team deploys Superset in a staging environment that mirrors production, with PostgreSQL or MySQL as the metadata database rather than the SQLite default. Before any upgrade or configuration change, the team backs up the metadata database and follows the upgrade steps in the project documentation, checking UPDATING.md for breaking changes. Business users run parallel reporting for a defined period. The step is done when staging results, performance and access tests are accepted by the business and security owners.
Plan a home for burst and pixel-perfect reports
Superset does not produce burst distribution or pixel-formatted documents such as invoices or regulatory layouts, so the team lists these outputs from the inventory and assigns each to a destination. Options include a document generation tool, a reporting service in your own infrastructure, or a fixed export process. Each option needs a named owner, a test run and a fallback. The step is done when every non-Superset output has a documented replacement that has produced a successful test output.
Cut over and decommission Cognos
The team sets a cutover date with the business sponsors, switches consumers to Superset, and keeps Cognos read-only for a documented fallback period. After the agreed period, Cognos schedules are disabled, the content store is archived under your retention policy, and licenses and servers are released. Ask your IBM contact to confirm the terms for ending the subscription in writing. The step is done when Cognos is decommissioned and the archive, access records and sign-offs are stored together.
What buyers ask before choosing Apache Superset over Cognos
What does moving from Cognos to Apache Superset actually cost?
The software itself has no license fee, because Apache Superset is released under Apache-2.0 and has no paid edition. The cost is the work around it: the effort to inventory and rebuild content, the servers and metadata database, the caching and worker components, and the staff time to run upgrades. Cognos costs are per user and recur with each renewal, while the Superset work is mostly one-time rebuilding plus recurring operations. Costs rise with the number of reports, the complexity of Framework Manager models, the number of data sources, and the availability requirements you set. Ask any quote to separate one-time migration effort, infrastructure, and recurring support as distinct line items, and to state which of your Cognos content is in scope.
How long does a Cognos to Superset migration take?
The timeline depends on what you have to move, and no duration is set by the supplied sources, so treat any figure you hear as a question to test. The main drivers are how many reports and packages are actually in use, how much of your logic lives in Framework Manager models that must be rebuilt as Superset datasets, how many dashboards depend on pixel-formatted output, and how many people must sign off on the results. Retiring unused content early shortens the work. Ask for a written scope with deliverables and milestones before work starts, so the timeline follows from what has been agreed.
Can our own staff run Apache Superset after the migration?
Often yes, but it depends on your team's existing skills in Linux, containers, Python-based services, SQL and database administration. Superset needs a metadata database (PostgreSQL or MySQL, per the supported versions in the configuration documentation), an application tier, and, for alerts, reports, async queries and thumbnails, a caching layer and Celery workers, with Redis commonly used. It also requires a user-specified SECRET_KEY to start. Before deciding, confirm whether you have on-call coverage for these components, a process for upgrades that follows the upgrade documentation (back up the metadata database, run the database and init steps, test in staging, and read UPDATING.md), and who owns each step. A fixed-scope engagement or a retainer can cover the parts your team does not want to carry.
What does our team need to provide for the project?
Plan for access and time from three groups: database administrators, identity and access owners, and the people who hold the source content. Database administrators will be needed to provision the metadata database, decide backup and high availability arrangements, and grant Superset read access to the analytical sources. Identity owners will configure authentication, whether through database login, LDAP, or OAuth2 providers such as Google or Azure, and map groups to roles with AUTH_ROLES_MAPPING. Content owners must confirm which Cognos reports, packages and schedules are still used and which business definitions are correct. Ask each vendor or implementer to list these dependencies in the written scope, along with the environments (staging and production) they expect you to provide.
Does Apache Superset replace pixel-perfect Cognos reporting?
Not in every case, and you should confirm this before committing. Superset is built for interactive dashboards, charts and SQL-driven exploration, and it supports scheduled alerts and reports. It is not a like-for-like substitute for every pixel-formatted, burst or bursting-style output that Cognos produces. Identify those reports during inventory. For each, decide whether to rebuild it in Superset, generate it from another reporting tool, or keep it on Cognos for a defined period. Ask for a written list that classifies each in-scope report by output type, so that any gap is visible in the scope rather than discovered at cutover.
Should we upgrade Cognos to 12.1 before considering Superset?
That decision belongs to your roadmap and support obligations, and the answer changes with your timing. Cognos Analytics 12.0.x moved to extended support on September 30, 2026, which is the date to check against your own contract. An upgrade to the 12.1.x line gives you a supported platform while you assess options, but it is a separate project with its own testing. Staying on extended support, upgrading, and replacing are three distinct paths. Before choosing, complete the content inventory, since it sizes all three options. Confirm your IBM support entitlement and end-of-support dates directly with IBM.
What support and security controls should we expect from the engagement?
Expect written scope, deliverables and timelines agreed before work starts, since most DeployOpen engagements are fixed-scope. On the security side, the work should cover how Superset is authenticated, how SECRET_KEY is generated and rotated (PREVIOUS_SECRET_KEY supports rotation), network placement of the metadata database, and access controls on the datasets. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications. Ongoing upgrades, support and continuous testing are available as retainers. Ask what is covered after go-live, who responds to incidents, and how upgrades are tested before they reach production.
How DeployOpen helps evaluate, implement or migrate
DeployOpen plans and implements self-hosted Apache Superset inside your own cloud accounts, data centers or air-gapped networks, starting from a written view of what your Cognos estate actually does. Teams that are still deciding can scope an evaluation first, then move to implementation only once the reports, packages and access model are understood. Each engagement is fixed-scope, with deliverables agreed in writing before work starts.
How we scope
- Inventory which Cognos reports, Framework Manager packages and schedules are still in use, and which can be retired.
- Map each package's data sources and business rules to the Superset datasets, metrics and access roles needed.
- Record in the written scope which burst or pixel-formatted outputs Superset will not produce and need another home.
How we build
- Deploy Superset with PostgreSQL or MySQL as the metadata database, following the supported versions in the configuration documentation.
- Add the caching layer and Celery workers needed for alerts, reports, async queries and dashboard thumbnails.
- Connect your identity provider through OAuth, LDAP or database authentication, and map groups to roles with AUTH_ROLES_MAPPING.
How we hand over
- Deliver the deployment record, configuration, secret key handling and backup procedure for the metadata database.
- Document the rebuilt dashboards, datasets and permission model so your team can maintain them without us.
- Provide an upgrade runbook covering the database upgrade steps, staging tests and the UPDATING.md review for each release.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover staged upgrades of Superset and its metadata database as new releases are published.
- Security testing of the deployed Superset instance can be scheduled separately, with findings tracked against the agreed scope.
