Where self-hosted Apache Superset costs less than Cognos Analytics, and where it costs more
If a Cognos renewal or per-user quote is forcing a cost review, start from this fact: Apache Superset carries no license fee. It is an Apache Software Foundation project released under Apache-2.0 with no paid edition, so the comparison moves away from software licensing and toward infrastructure, migration, support and staff time. Cognos per-user figures are not supplied for this page, so take the Standard and Premium prices from IBM or your reseller, in writing, against the same user counts and growth you expect over the next several years.
Superset costs more in the first year mainly because the work is front-loaded. You pay for servers and a metadata database in PostgreSQL or MySQL, which Superset is tested with and which the architecture documentation says the SQLite default and the Docker Compose PostgreSQL container are not suited for in production. If alerts, reports, async queries or dashboard thumbnails matter to your users, you also run a caching layer and Celery workers. Then comes the largest line: rebuilding Framework Manager packages as Superset datasets and recreating reports. Ask your implementation partner to price these by inventoried report and package, not by a flat estimate.
Recurring costs are where the comparison settles. Each Superset upgrade needs a metadata database backup, superset db upgrade, superset init, a staging test and a review of UPDATING.md for breaking changes, and someone must own that cycle. Confirm who carries it: your platform team, a retainer with a partner, or both. Ask the partner for a written quote covering build, hosting, upgrades and support as separate lines, and compare it with three years of per-user Cognos fees plus the Cognos infrastructure you can retire.
Which cost components sit on the Cognos side and which on the Superset side
This table sets each cost component of a Cognos estate beside its counterpart in a self-hosted Apache Superset deployment, and marks whether it is one-time or recurring. Use it to build your own cost model, then request written quotes that match each row. The main takeaway is that the Cognos side is mostly recurring per-user fees, while the Superset side moves the cost into infrastructure, migration and internal skills that you control.
| Cost component | IBM Cognos Analytics side | Apache Superset side | One-time or recurring |
|---|---|---|---|
| License or subscription | Per-user licensing for Standard and Premium editions, confirmed in the current IBM quote for your user counts and edition | No license fee, since Superset is Apache-2.0 licensed with no paid edition | Cognos: recurring. Superset: none |
| Servers and virtualization | Application tier servers, gateway and any dispatcher nodes sized to your concurrency and report load | Web and query nodes sized to your user count and cache needs, hosted in your own cloud or data center | Both recurring, driven by hardware or cloud capacity |
| Content store or metadata database | Cognos content store database, licensed and administered under the database vendor's terms | PostgreSQL or MySQL metadata database in a supported version, typically a managed or self-run instance | Both recurring, with database licensing applying only on the Cognos side if commercial |
| Caching, alerts and workers | Scheduling and burst output handled inside the Cognos server components | Redis-style caching and Celery workers for alerts, reports and async queries, per the architecture documentation | Recurring infrastructure on the Superset side |
| Implementation and setup | Vendor or partner effort for installation, configuration and integration with identity | Internal or partner effort for deployment, authentication through Flask-AppBuilder and environment hardening | One-time |
| Report and content migration | Inventory of packages, reports, schedules and Framework Manager models before any move | Rebuilding models as datasets and recreating dashboards, with burst and pixel-formatted reports needing a separate plan | One-time, usually the largest project cost |
| Support and upgrades | Vendor support subscription and periodic upgrade projects tied to the product lifecycle | Community support or a paid retainer you choose, plus staged upgrades that follow the upgrade guide and backups | Cognos: recurring. Superset: recurring if you buy support |
| Internal skills and operations | Cognos administrator and report author skills, largely already in place in many estates | Staff for Python, SQL, Kubernetes or VM operations, backups and monitoring | Recurring staff time on the Superset side |
What moves the comparison most: users, data volume, editions and skills
Five inputs decide whether a Cognos to Superset move saves money or just shifts cost. Some hit the license line, some hit the one-time rebuild, and some hit the servers and staff you carry afterwards, so size each one before you ask for quotes.
Named and concurrent user counts
Cognos pricing is tied to the number of users and the edition, so the user count sets the recurring license line more than any other input. Export the real login history for the last 12 months and separate named authors from occasional viewers, since the license terms for each group may differ. Ask IBM or your reseller to price the exact counts in writing rather than the headcount on an org chart. This is a recurring cost that scales with every user you add.
Volume of reports and packages
The number of reports, packages, data modules and schedules sets the one-time rebuild effort, which is the largest up-front cost in any migration. Count how many items have run in the last year, because many older reports are never opened and should be retired rather than rebuilt. Each package that depends on a Framework Manager model adds mapping work when it moves to Superset datasets. This cost is one-time, but it recurs if you rebuild the same content twice.
Availability and high-availability servers
A single Superset host is cheap to run, but production use often needs redundant web nodes, a managed PostgreSQL or MySQL metadata database, and a cache and Celery workers for alerts, reports and async queries. Decide the recovery targets with the business before sizing hardware, since each redundant tier adds servers, licenses for the OS and monitoring, and on-call load. Infrastructure is a recurring cost. Ask your team to price each tier separately so you can see which one drives the total.
Number of data sources and dialects
Superset reaches any SQL datastore that has a Python DB-API driver and a SQLAlchemy dialect, but each source still needs a driver to be installed, tested and patched. Count the distinct databases behind your Cognos packages, including the ones that only feed one report. Sources that lack a maintained dialect may need a custom connector or a staging copy, which adds one-time engineering. Driver upgrades are a recurring task, so include them in the staff estimate.
In-house Python and operations skills
Superset is a Python and Flask application, so the cost of running it depends on whether your team already manages Python services, containers and database upgrades. A team with no such skills will pay for training, a partner retainer or a longer learning curve, all recurring until the skills are in place. Check who will own the upgrade path, since Superset upgrades require a database backup, schema commands and staging tests. Staff time is the cost most often left out of comparisons, so write it into the model as a line item.
How to build the comparison with your own numbers
This sequence turns the Cognos renewal, your staff time and your hosting bills into one comparison that you can change line by line. Each step ends with a document you can hand to finance and to the Cognos account team.
Export the user list by role from Cognos
Ask the Cognos administrator to export the active user list from the content store or the admin console, with each user's role, group membership and last sign-in date. Count users by the access level your contract uses, because Standard and Premium are priced per user and the split between them drives the renewal line. Remove accounts that have not signed in for a period your governance policy defines, and record that count separately. The output is a role-by-role user count with a note on how many accounts are inactive, which you can later compare with the quoted seat count.
Inventory reports, packages and schedules
Export the content inventory from Cognos, covering reports, dashboards, Framework Manager packages, data modules and scheduled jobs, with owner and last-run date for each. Mark items that no one has opened in your review window, and flag burst, pixel-formatted or scheduled output that Superset does not produce. Count the remaining items by type, since rebuild effort follows the number and complexity of reports, not the number of users. The output is a sheet that separates content to rebuild, content to retire and content that needs a different output path.
Price the Cognos renewal from the written quote
Request a written renewal quote from IBM or your IBM partner that lists each product line, the metric used (per user or per capacity), the term, support and any add-ons, and the currency and tax treatment. Keep the quoted figures in their own line items, one per product and term, so you can see what each one costs per year. Also ask what happens to pricing at the next renewal and whether the quote covers the non-production environments you run. The output is a recurring cost line for the current contract that you can update when the quote changes.
Size the Superset metadata database, cache and worker hosts
Superset needs a metadata database, which the project tests with PostgreSQL and MySQL, and it needs a caching layer and Celery workers for alerts and reports, async queries and dashboard thumbnails. Your architecture team sizes these hosts from your own infrastructure, using the instance prices, storage rates and managed database costs in your cloud or data center bills. Record production, staging and disaster recovery environments as separate rows, since a single-node SQLite setup is not suitable for production. The output is a hosting cost table with one row per component and environment, each priced from a current bill.
Add rebuild, support and staff time as separate lines
Estimate the effort to migrate the content you marked for rebuild, then record it as a one-time line, using your internal rates or the rates in a fixed-scope written proposal from a services provider. Record recurring lines for platform operations, upgrades, backup testing and support, and state who carries each one: your staff, a retainer or a vendor. Metabase and Superset both document upgrade steps that include backing up the metadata database and testing in staging, so include that testing time. The output is a one-time total and an annual recurring total, each traceable to a named assumption.
Keep each assumption in its own line
Place quotes, internal labor rates, cloud bills and license terms in separate tabs of the same workbook, and link each total to the assumption it uses rather than typing the figure into the summary. Label the source and date of every input, and add a column for the person who owns it. When a quote changes or a cloud bill moves, update one input and the comparison recalculates. The output is a model where any single assumption, such as the seat count or the staff rate, can be changed and the difference in total cost is visible at once.
What it costs to rebuild Cognos content as Superset datasets and dashboards
The rebuild is usually the largest one-time labor item in a Cognos to Superset move, and it is driven by content inventory rather than by software. Framework Manager packages do not convert into Superset datasets automatically. Each package's query subjects, joins, calculations, security filters and naming conventions must be re-expressed as Superset datasets, virtual datasets built from SQL, metrics and filters, and then checked against the figures Cognos currently returns. Plan validation as a separate line item: for each rebuilt dataset, have a business owner reconcile totals and key breakdowns with the Cognos report they replace. Ask any services provider to price that reconciliation explicitly, since it is where discrepancies surface.
Dashboards are recreated, not exported. Cognos reports, dashboards and their prompts, drill-throughs and conditional formatting have no direct Superset equivalent, so each one needs a design decision: keep it as a Superset dashboard with charts and native filters, consolidate it with others, or retire it. Use the content store inventory and the usage data for each report to decide which items are worth rebuilding. Cost rises with the number of reports that are still in use, the number of distinct packages behind them and how much bespoke formatting the business expects to keep.
Some outputs will not have a home in Superset. Burst reports, which are generated per recipient from a single report definition, and pixel-perfect formatted documents, such as statements or regulatory returns, are not what Superset dashboards produce. Confirm the exact formats and distribution lists currently in use, then choose a destination for each: a scheduled SQL or reporting job, a document generator, or a retained Cognos license for that subset. Each option carries its own build and run cost, and the choice should be made before the rebuild estimate is final. Confirm with the vendor what Superset's alerts and reports feature can deliver in your environment before assuming it covers any of these outputs.
Which cost path fits a small team, a large estate or a regulated environment
An estate with a small number of users and mostly list reports usually has a short rebuild and a small fixed footprint. In this profile the per-user Cognos fee is the line that dominates the comparison, because it recurs every term and scales with named users. Apache Superset carries no license fee, but the cost moves to hosting, a metadata database and the time someone spends owning upgrades.
- Per-user renewal: Ask Cognos for the named user count, edition and renewal date in writing, and check whether seats can be reduced mid-term.
- Rebuild effort: Few list reports keep the one-time rebuild modest, but count every scheduled delivery, not only the report itself.
- Hosting footprint: A single node with PostgreSQL can serve a small team, but the architecture documentation says alerts, reports and async queries need the caching layer and Celery workers.
- Operations ownership: Name one person for upgrades, following the documented steps of backing up the metadata database, running the upgrade and testing in staging first.
Confirm with Cognos the contract end date and whether a reduced seat count is possible, and confirm with your infrastructure team who will carry the upgrade work each year.
A large estate with many packages, data sources and scheduled outputs shifts cost away from seats and toward inventory, rebuild labor and the infrastructure that runs schedules. Per-user fees still scale with headcount, but the largest cost is usually the one-time rebuild of Framework Manager packages and dashboards, followed by the operating cost of workers and the metadata database. Superset will not produce every output type on its own, so the plan for those must be costed separately.
- Rebuild labor: Framework Manager models become Superset datasets, and each dashboard is recreated, so size the effort from a complete inventory rather than an estimate from report counts.
- Worker and cache capacity: Scheduled reports, alerts and async queries depend on Redis and Celery workers, so size them against your actual schedule volume and test that load in staging.
- Metadata database operations: The PostgreSQL 10 to 17 or MySQL 5.7 and 8.x metadata database becomes a production dependency with its own backup and patching routine.
- Kubernetes path: The current development documentation marks the Helm chart as deprecated and points new deployments to the Apache Superset Kubernetes Operator, so confirm which path your platform team will support.
- Burst and pixel-formatted outputs: Identify which of these outputs the business still needs, because a separate tool or service may add cost.
Request the content store size and package count from your own deployment archive, and confirm with your business owners which packages are retired before any quote is requested.
A regulated environment that needs air-gapped or tightly controlled hosting often decides on deployment model before cost. Cognos can run on-premises, in containers or as an IBM-hosted service, so the first question is which of those the controls in your environment allow. Superset has no paid edition and runs entirely in infrastructure you control, which removes the license line but adds hardening, key management and evidence work that you own.
- Hosting control: Superset deploys into your data centers or cloud accounts, and the cost is the infrastructure plus the hardening effort, which is a one-time and then recurring cost.
- Identity integration: Superset supports database, LDAP and OAuth authentication through Flask-AppBuilder, and maps groups to roles with AUTH_ROLES_MAPPING, so plan that mapping against your identity controls.
- Secret handling: A user-specified SECRET_KEY is required at startup, and PREVIOUS_SECRET_KEY supports rotation, so both belong in your key management procedures.
- Metabase comparison: If Metabase is shortlisted, its pricing page lists air-gapped deployment only on the Enterprise plan, which is priced by quote starting at $20,000 per year.
- Evidence and assessment: Independent auditors and certification bodies issue reports, and DeployOpen can prepare controls and evidence for that assessment.
Confirm with your compliance lead which controls and data classes apply, and confirm with Cognos exactly which deployment modes its contract and support terms cover.
How upgrade and lifecycle projects change the cost picture
Staying on a Cognos release or moving to a newer one is a project with its own cost, and that cost belongs in the comparison alongside the license fees. Before you price either path, get the support lifecycle dates for your exact Cognos Analytics release directly from IBM, including the end of any extended support window, and write them into your planning document. Do not assume a date from a secondary source or from an older release cycle. The lifecycle dates set the deadline, and the deadline determines whether you are paying for an upgrade now, a longer period of extended support, or a migration later.
On the Superset side, the upgrade routine is documented and repeatable. The Superset upgrade documentation tells you to back up the metadata database first, run superset db upgrade and superset init, and test the new version in staging before production. Read UPDATING.md for breaking changes between your current and target versions, because those notes decide how much rework a release needs. Apache Superset is licensed under Apache-2.0 and has no paid edition, so there is no subscription line to renew. The recurring cost is the staff time to plan, test and run each upgrade, plus the test environment that makes staging possible. Ask your team to estimate how many upgrades a year their support policy requires and who owns each one.
The main drivers of that cost are how many dashboards and datasets depend on features that change between releases, how closely your Superset deployment matches its staging copy, and whether the Celery workers and caching layer are upgraded in the same window as the web application. Ask any implementation partner to state these items in a fixed-scope quote, including who performs the backup and restore test, who signs off the staging results and how breaking changes are handled. Compare that recurring effort with the per-user fees and upgrade projects you would otherwise pay under a Cognos renewal.
Questions buyers ask about Cognos and Superset costs
Is Apache Superset free to use?
Yes, the software is free to use. Apache Superset is released under the Apache License 2.0 by the Apache Software Foundation, and the project has no paid edition, so there is no per-user license fee. Your costs come from the infrastructure you run it on, the metadata database, the optional caching layer and worker components for alerts and scheduled reports, staff time to operate and upgrade it, and any outside implementation or support you choose to buy. Those costs recur or are one-time in different ways, so ask a provider to separate them in the quote. The Apache Superset repository states the license and project home.
How do I get an IBM Cognos price to compare against Superset?
Cognos pricing is not something DeployOpen publishes, and the figure depends on your contract. Request a current quote or renewal statement from IBM or your reseller, and ask it to list each component separately: named user licenses by edition, any server or processor terms, support, and the content store database and its license. Then ask your finance team to pull the full three-year cost of your current deployment, including the infrastructure and staff time it already consumes. Comparing those totals with a costed Superset plan gives you a like-for-like view. The sibling page on comparing Cognos with Apache Superset covers the feature differences that affect that comparison.
How long does a Cognos to Superset migration take?
The duration depends mainly on the size of the estate you actually use, not on the number of reports that exist. The main drivers are how many reports, packages and Framework Manager models stay in scope after you retire unused content, how complex the calculations and prompts are, how many scheduled outputs need a replacement such as burst or pixel-formatted reports, how many data sources must be connected, and how much documentation of existing logic is missing. Ask any provider for a timeline tied to a written inventory and a fixed scope, not a generic estimate. Start with the export and inventory guide and the migration plan to Superset before requesting dates.
What does my team need to provide for a migration?
Your team needs to supply knowledge and access more than hours. Expect to provide a named business owner who can retire or keep each report, a security or identity contact for SSO and group mapping, database administrators for the data sources and the metadata database, and someone who can explain the business rules behind key calculations. You will also need staging infrastructure, test accounts and time for user acceptance testing. Superset requires a user-specified SECRET_KEY and runs with a PostgreSQL or MySQL metadata database in production, so platform engineers should confirm hosting decisions early. Ask the provider to list these client responsibilities in writing as part of the scope.
Can we run the Superset migration ourselves without outside help?
Yes, many teams can, provided they have engineers who can operate Python-based web applications, manage a relational database, configure authentication and maintain a release process. The Superset upgrade documentation expects you to back up the metadata database, run database upgrades, test in staging and review UPDATING.md for breaking changes, so that routine work must be owned by someone. The harder part is rebuilding Cognos Framework Manager logic as Superset datasets and recreating dashboards with the same meaning. Assess your internal capacity honestly against that inventory, and consider a fixed-scope engagement for the rebuild and handover if the skills or time are missing.
What should a fixed-scope quote for this work include?
A fixed-scope quote should name every deliverable and state what is excluded. Ask for the inventory method and the list of reports and packages in scope, the target architecture with each component (application, metadata database, caching layer, workers), the data source connections, authentication and role mapping, the rebuild and testing approach, the documentation and handover, and the upgrade and backup procedure. Also ask how unsupported outputs such as burst or pixel-formatted reports will be handled, what your team must provide, and what happens if inventory reveals more scope. Separate one-time implementation fees from any recurring support or retainer, and confirm the timelines are written into the agreement before work starts.
How DeployOpen scopes a fixed-price Superset implementation
DeployOpen plans and builds self-hosted Apache Superset inside your own cloud accounts, data centers or air-gapped networks, so the cost comparison on this page turns into a written, fixed scope. We start from your Cognos inventory, agree deliverables in writing, and hand over documentation your own team can run after the engagement ends.
How we scope
- We agree the written scope before work starts, covering which Cognos reports, packages and schedules move to Superset.
- We list the data sources each dashboard depends on and confirm which database drivers Superset must reach.
- We set out which content is retired, which needs rebuilding and which items Superset will not produce, such as burst or pixel-formatted reports.
How we build
- We deploy Superset with PostgreSQL or MySQL as the metadata database, not the SQLite default used for quick installs.
- We configure the caching layer and Celery workers where alerts, reports and async queries are needed, and document each component.
- We connect authentication through LDAP or OAuth, map groups to roles with AUTH_ROLES_MAPPING, and test access against the agreed permission model.
How we hand over
- We deliver runbooks for installation, the SECRET_KEY and PREVIOUS_SECRET_KEY rotation process, and metadata database backups.
- We document the upgrade procedure, including backing up the metadata database, running the upgrade commands and reviewing UPDATING.md before each version change.
- We hand over a dataset and dashboard inventory so your team can see what was rebuilt, what was retired and what still needs owners.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover, agreed in a separate written scope.
- A retainer can cover staging tests of each Superset release before it reaches production, which your team may want to budget for.
- Ask any provider to confirm in writing who carries patching, backup testing and on-call responsibility after go-live.
