Looker or Apache Superset: which fits your renewal and data control needs
If your Looker renewal is driven by a need to keep dashboards and data under your own control, the first question is where the platform must run. Looker (Google Cloud core) instances are hosted by Google in Google Cloud and are not offered for customer-hosted or multicloud environments, so it fits teams that accept Google Cloud hosting and want a managed, Git-backed LookML model. Apache Superset fits teams that must self-host, want an Apache-2.0 licensed platform with no paid edition, and can operate the stack themselves. Confirm your hosting rule first, because it usually decides the outcome before features are compared.
Looker (Google Cloud core) makes sense when the organization is already comfortable with Google Cloud as the hosting boundary and wants LookML definitions versioned in a Git repository. Each LookML project corresponds to a Git repository, and Looker connects to GitHub, GitLab or Bitbucket over HTTPS or SSH, so model changes can be reviewed like code. Confirm with Google whether the Standard, Enterprise or Embed edition covers the features your team uses, and ask what your renewal terms say about data residency and exit. Apache Superset makes sense when you need the platform inside your own cloud account, data center or network, and when you can maintain its metadata database, caching layer and workers.
The decision turns on three factors: hosting requirements, how much LookML logic must be preserved, and who will operate the platform. In Superset, unified metric definitions live in datasets, and the SQL IDE and chart builder cover much of daily analysis, but explores, joins and derived logic must be rebuilt in SQL, dbt or the warehouse. Ask your team to inventory LookML views, explores and persistent derived tables, then estimate how many depend on logic that would have to move. Assign an owner for upgrades, backups and the SECRET_KEY before you commit, because a self-hosted Superset is only as governed as the team that runs it.
Which option fits which scenario
This table maps common situations to the better fit between Google-hosted Looker (Google Cloud core) and self-hosted Apache Superset. Read each row for the condition that drives the choice, then check it against your own hosting, governance and staffing constraints.
| Scenario | Better fit | Condition that drives the choice |
|---|---|---|
| Google Cloud is already the standard with no customer-hosting need | Looker (Google Cloud core) | Google hosts Looker (Google Cloud core) in Google Cloud, so the platform team has no servers to run for BI. |
| On-premises or multicloud requirement | Apache Superset | Looker (Google Cloud core) is not offered for customer-hosted or multicloud environments, while Superset runs on infrastructure you control. |
| Heavy LookML investment in Git | Looker, unless you plan a migration | LookML projects map to Git repositories, so existing models stay in version control; a move means rebuilding them as Superset datasets and metrics or warehouse views. |
| SQL-first analysts who write queries daily | Apache Superset | Superset provides a SQL IDE with metadata browsing and Jinja templating, which suits analysts who think in SQL. |
| Governed metrics shared across charts | Either, depending on where definitions live | Superset offers physical and virtual datasets with unified metric definitions; confirm which metric governance your team needs before choosing. |
| Embedded dashboards in a host application | Confirm with a proof of concept | Looker's Embed edition is its embedding path; Superset offers an embedded SDK with guest tokens. Test the flow your app needs. |
| Small platform team with limited operations capacity | Looker (Google Cloud core), unless you can staff upgrades | Superset requires a metadata database, caching and worker components, and upgrades that include database migrations and staging tests. |
| Strict license and source-visibility requirements | Apache Superset | Superset is licensed under Apache-2.0 with no paid edition, which simplifies license review for internal use. |
What LookML users redo when they move to Superset
Superset does not reproduce LookML explores or derived table logic one for one, so plan to rebuild the modeling layer rather than copy it across. In LookML, a view bundles a table with its dimensions and measures, and an explore defines the joins a business user can query. In Superset, the closest equivalents are the physical or virtual datasets (a table or a SQL query saved as a dataset) and the metrics and calculated columns defined on each dataset. Each LookML measure needs a matching metric definition, and each dimension needs a column or expression. Joins are the part that changes most: Superset datasets are single queryable sources, so multi-table logic usually moves into a SQL view in the warehouse or into a dbt model before Superset sees it.
Governed definitions are the risk to plan for. Superset's unified metric definitions keep a metric consistent across charts once it is defined on the dataset, but the definitions live in Superset's metadata database unless you deliberately keep them elsewhere. Treat the SQL behind each virtual dataset and each metric as code: store it in a Git repository, review changes through merge requests, and deploy from there to staging before production. Looker users already work this way, since each LookML project corresponds to a Git repository that Looker can connect to over HTTPS or SSH on GitHub, GitLab or Bitbucket. Export those repositories first, then decide which LookML logic becomes warehouse views, dbt models or Superset metrics. Ask your team to confirm how persistent derived tables were refreshed in Looker, because that schedule has to be recreated in the warehouse.
Where your data and metadata live under each option
Looker and Superset differ first in where the platform runs, then in where the metadata, credentials and audit evidence sit. Each card below is a location or control to confirm before you choose, because residency terms and hosting limits decide which options are open to you.
Looker runs in Google Cloud
Looker (Google Cloud core) instances are hosted by Google in Google Cloud, and Google documents them as unavailable for customer-hosted or multicloud environments. Your queries and model metadata therefore run inside Google's hosting boundary, even when the warehouse sits elsewhere. Ask Google for the current data location and residency terms for the edition you would buy, and confirm them against your own policy before a renewal discussion.
Superset runs in your environment
Superset is deployed in your cloud account, data center or air-gapped network, so the application, its logs and its cached results stay under your change control. You choose the region, the network path to each warehouse and who can reach the web tier. The trade-off is that you own availability, patching and backup of every component, which Looker's hosting removes.
Metadata database choice
Superset stores its own metadata, including dashboards, datasets, users and metric definitions, in PostgreSQL or MySQL, and the documentation advises against the SQLite default for production. That database becomes a backup and residency object in its own right. Confirm the engine version your standards allow, where it is hosted, and how you encrypt and restore it.
Identity integration path
Superset authenticates through database accounts, LDAP or OAuth2 providers, built on Flask-AppBuilder, and can map directory groups to roles. Looker users sign in through Google identity. With Superset, the identity provider, group mapping and session handling are your design decisions and must be tested with your own directory before users are migrated.
Compliance evidence is yours to assemble
With either option, your organization prepares the controls, configuration records and access reviews, and an independent auditor assesses them. Under Looker, part of the hosting evidence comes from Google's own documentation and attestations, which you should request directly. Under Superset, the logs, backups, key rotation records and change history all come from your environment.
Residency terms to confirm
Before choosing, write down every location that holds data for your analytics: warehouse, Superset metadata database, caches, exported files and backups. Ask Google for the residency commitments that apply to Looker, and check them against your own data classification. Run the same inventory for a self-hosted Superset so the comparison covers the same data flows.
How a self-hosted Superset deployment is structured
A pilot is the fastest way to see how Superset's data model, datasets and charts map to your warehouse. Superset's architecture has four components: the Flask and React application, a metadata database, an optional caching layer and optional Celery worker and beat processes. For a pilot you can run the application against a single database, but the default SQLite metadata store that comes with Quickstart and PyPI installs is not recommended for production, and the same applies to the PostgreSQL Docker Compose container. Treat the pilot as a throwaway environment and plan to move the metadata database before anyone builds governed dashboards on it.
- Application node: one web process serving the UI and API, pointed at your warehouse through a Python DB-API driver and SQLAlchemy dialect.
- Metadata database: a PostgreSQL or MySQL instance holds dashboards, datasets, roles and metric definitions, even in a pilot.
- Caching and workers: skip them at this stage unless you need alerts, reports or async queries.
- Secret key: Superset requires a user-specified SECRET_KEY to start, so set it from day one.
- Exit criteria: record which warehouse connections, metrics and roles the pilot exercised.
Before you rely on the pilot's results, confirm the supported metadata database versions in the configuration documentation for the release you intend to run.
A production deployment separates the stateful pieces from the application so you can back up, patch and scale each one. The metadata database should be PostgreSQL or MySQL in a managed or well-operated configuration with its own backups, since it holds the definitions that replace your LookML layer. Caching and workers become necessary when you want scheduled alerts and reports, async queries or dashboard thumbnails. The architecture documentation notes that most installations use Redis and Celery for these features, so plan for those services as recurring operations work.
- Metadata database: PostgreSQL or MySQL with tested backups and restore drills.
- Caching layer: typically Redis, required for alerts, reports, async queries and thumbnails.
- Celery workers and beat: run them as separate processes so scheduled jobs do not compete with interactive users.
- Authentication: connect OAuth2 providers, LDAP and AUTH_ROLES_MAPPING to your identity system.
- Upgrades: back up the metadata database, run superset db upgrade and superset init, and test in staging first, checking UPDATING.md for breaking changes.
Ask your implementation partner or internal platform team to document which of these components they will operate, and who is on call for each.
Kubernetes gives you horizontal scaling and standard rollout tooling, but it adds cluster-level components to operate. The Superset 6.1.0 documentation describes installs with the official Helm chart. The current development documentation marks that Helm chart as deprecated and points new deployments to the Apache Superset Kubernetes Operator. If you are starting now, evaluate the operator first and confirm its current status with the project before you commit to a chart-based pipeline.
- Helm chart: documented for the 6.1.0 release, but marked deprecated for new deployments in current development docs.
- Kubernetes Operator: the path the project points new deployments to, documented on its own site.
- Components as workloads: the web application, workers, beat, caching and metadata database each map to a workload or external service.
- Configuration: keep SECRET_KEY, database credentials and OAuth settings in Kubernetes secrets, not in images.
- Migrations: run database upgrades as a controlled job during each release, not on every pod start.
Confirm the installation path, supported Kubernetes versions and Helm or operator release with the project's current documentation before you write the deployment plan.
Regulated environments often need Superset inside a private network with no outbound access to hosted services. Because Superset is Apache-2.0 licensed and has no paid edition, the software itself can be mirrored into your registries and built from source or from published artifacts. The harder questions are about what the platform reaches: warehouses, identity providers, mail relays for reports, and any caching or worker services. Each of those connections should be listed in the deployment design and approved by the teams that own them.
- Artifact provenance: mirror the release you test into your internal registry and record the version and checksum.
- Network paths: document every connection to warehouses, identity providers, SMTP and caching services.
- Secrets handling: store SECRET_KEY and credentials outside the image, with rotation planned through PREVIOUS_SECRET_KEY.
- Evidence: keep configuration, upgrade records and access reviews as artifacts for your compliance assessor.
- Ownership: name who patches the metadata database, the caching layer and the workers.
DeployOpen prepares systems and evidence for assessments, but independent auditors and certification bodies issue the actual reports, so confirm your assessor's expectations early.
Cost components on each side and what drives them
Looker costs are mostly licenses and warehouse consumption, while Superset costs are mostly infrastructure and people. Both sides carry modeling work, so compare the components one by one rather than comparing a single headline number. Confirm every figure with Google, your cloud provider and your own team before you commit.
Looker licenses by edition and users
Looker (Google Cloud core) is sold as Standard, Enterprise and Embed editions, and the price depends on the edition and the number of users who need access. This is a recurring cost tied to your term. Ask Google for a written quote that lists the edition, user counts by role, any embed or add-on terms, and what happens to the license at renewal.
Warehouse query consumption
Every Looker query runs in your warehouse, so the warehouse bill rises with dashboard refreshes, scheduled deliveries and ad hoc exploration. Superset also sends queries to the warehouse, so this cost carries over. Model the query volume from your current usage logs, and check whether caching, aggregate tables or pre-built views reduce scans on either side.
LookML development time
Your LookML views, explores and derived tables are code that someone maintains. Moving to Superset means rebuilding that logic as datasets, virtual datasets and metric definitions, or moving it into the warehouse. This is a one-time cost, but it is often the largest. Ask how many LookML files, explores and dashboards are in scope before estimating effort.
Superset infrastructure and metadata database
Superset runs as an application server plus a metadata database, and the project tests PostgreSQL and MySQL for that role. You pay for compute, storage, backups and high availability, which recur monthly and vary by cloud or data center. The SQLite default and the Docker Compose PostgreSQL container are not recommended for production, so budget for a proper database service from the start.
Caching, workers and alerting
Alerts and reports, async queries and dashboard thumbnails need the caching layer and the Celery worker and beat processes, and most installations use Redis and Celery for them. Each adds runtime, monitoring and upgrade effort. Confirm with your platform team which of these features you need, since they drive the number of services you operate.
Upgrades, staging and support staff
Superset upgrades require a metadata database backup, running database and init commands, testing in staging and reviewing breaking changes in the release notes. This recurring work needs engineers with time allocated, or a paid support retainer. Looker upgrades are handled by Google. Ask who on your team owns each release and how much time that takes each quarter.
How a move from Looker to Superset is carried out
The sequence moves LookML logic, dashboards and access rules into a self-hosted Superset deployment in a controlled order, so each stage has a check before the next one starts. The result is a validated Superset environment that teams can switch to without losing the metric definitions they rely on.
Export and inventory the LookML and Looker content
Your data engineering or BI lead clones the LookML project from its Git repository, since each LookML project maps to a repository that Looker connects to over HTTPS or SSH. In parallel, someone from the analytics team lists every Look, Explore, dashboard, scheduled delivery and user group, noting which ones feed executive or regulatory reporting. The step is complete when you have a versioned copy of the models and a spreadsheet inventory that names an owner and a priority for each asset.
Decide which logic moves to the warehouse
Before any Superset work starts, the team classifies each LookML view, derived table and measure. Simple column and aggregation definitions usually map to Superset datasets and metrics, while complex joins, persistent derived tables and row-level logic are better pinned in SQL views or dbt models in the warehouse. The architecture lead signs off this mapping, and the output is a short register that shows where every governed definition will live after cutover.
Stage Superset with a backed-up metadata database
The platform team deploys Superset in a staging environment using PostgreSQL or MySQL as the metadata database, because the SQLite default is not recommended for production. Before any upgrade or configuration change, they take a backup of the metadata database and set a SECRET_KEY, which Superset requires to start. The official upgrade guidance also says to check UPDATING.md for breaking changes between versions. The step closes when staging starts cleanly, a restore from backup has been tested, and the deployment details are recorded in your configuration management system.
Rebuild datasets, metrics and charts
Analysts recreate the physical and virtual datasets in Superset, connect them to the warehouse through a supported SQLAlchemy driver, and define metrics once so every chart uses the same calculation. Charts that were built in Looker Explores are rebuilt with the drag-and-drop builder, and complex cases are written in the SQL IDE with Jinja templating where needed. The output is a list of rebuilt datasets with each metric's source, owner and test query, reviewed against the LookML register from the earlier step.
Recreate dashboards and map roles
The platform team configures sign-in through the identity provider using Flask-AppBuilder options such as OAuth2 or LDAP, then maps directory groups to Superset roles with AUTH_ROLES_MAPPING. Dashboard owners rebuild each dashboard and assign access that mirrors the old Looker folder and group permissions. The step is complete when test users from each group can see exactly the dashboards and datasets they could see in Looker, and no more, and the mapping is documented.
Validate results side by side
Analysts run the same questions in Looker and Superset for a defined set of key reports, then compare totals, filters, time zones and null handling. Any difference is logged with its root cause, and the metric is corrected in the warehouse or dataset, not patched in one chart. Business owners sign off each critical report. The output is a reconciliation record that shows which reports match, which were changed deliberately, and who approved each change.
Cut over and retire Looker content
The team schedules the production switch, repeats the metadata database backup immediately beforehand, and points users, scheduled deliveries and embedded links to the new Superset environment. Looker content stays read-only until the owners confirm that nothing depends on it. Your renewal or contract decision follows this confirmation, not the other way around. The step closes when production users can work in Superset, the backup and runbook are filed, and the Looker retirement date is approved in writing.
Questions buyers ask before switching from Looker to Superset
What does it cost to switch from Looker to Apache Superset?
The switch cost is driven by the work, not by a license fee, because Apache Superset is licensed under Apache-2.0 and has no paid edition. The main cost components are the infrastructure to run Superset and its metadata database, the effort to rebuild LookML logic as datasets and metrics or as warehouse views, dashboard rebuilding, testing, and the people who operate the platform afterward. Ask any implementation partner for a quote that lists each component separately, with one-time work (discovery, migration, hardening, documentation) shown apart from recurring work (hosting, upgrades, support). The size of your LookML estate and the number of dashboards and explores are the biggest drivers.
How long does a Looker to Superset migration take?
The timeline depends on how much LookML you have, how many dashboards depend on it, how clean your warehouse models are, and how many systems need authentication and access rules rebuilt. Start by inventorying views, explores, Looks and dashboards, then decide which logic moves into the warehouse or dbt. Your schedule should also allow for side-by-side validation against Looker before the renewal date. Ask for a timeline in the written scope, with milestones for discovery, staging and cutover, rather than relying on a general estimate.
What does our team need to provide for a Superset migration?
You need access to the LookML repository, the warehouse with its schemas and permissions, a list of the dashboards and their business owners, and someone who can confirm which metric definitions are authoritative. Your identity team must supply the sign-in method, such as OAuth2 through Google or Azure, LDAP, or a custom OAuth2 server, and the group structure that will map to Superset roles. Infrastructure access to your cloud account, data center or private network is also required, along with a staging environment for testing.
Can our internal team migrate from Looker to Superset alone?
An internal team can do it alone if it already has strong SQL, Python and Docker or Kubernetes skills, a clear inventory of dashboards, and time away from its current backlog. Teams with little platform operations experience often underestimate the upgrade path, the metadata database backups, and the secret key handling that Superset requires at startup. A hybrid model is common: internal staff keep ownership of content and metrics while an outside team handles deployment, hardening and documentation. Assess your own skills honestly against the scope before deciding.
Does Superset replace LookML governance and version control?
Superset does not provide a LookML-style modeling language stored in Git. It offers physical and virtual datasets, unified metric definitions that scale chart creation, and a SQL IDE, so governed definitions usually live in the warehouse, in dbt or in version-controlled SQL that Superset reads. Confirm with your team which metrics must be single sources of truth and how changes will be reviewed before they reach dashboards. Access control in Superset depends on the roles you configure and the group mapping from your identity provider, so test those rules in staging.
How do we control warehouse query cost after moving off Looker?
Warehouse query cost depends on how often dashboards refresh, how many users query at the same time, and how large the underlying tables are, so it does not change simply because the BI tool changes. Superset's caching layer can reduce repeated queries, and async queries and alerts run through workers, which add components to operate. Before cutover, measure current query volume from your warehouse and compare it with the expected pattern on Superset, then set refresh schedules and cache settings deliberately. Ask your warehouse vendor which usage reports can show this.
Which Superset features need extra components to run?
Core dashboards and the SQL IDE run on the application and a metadata database, but alerts and reports, async queries and dashboard thumbnails need the caching layer and Celery worker and beat processes, usually backed by Redis. The metadata database must be PostgreSQL or MySQL in production, because the SQLite default and the Docker Compose PostgreSQL container are not recommended for production. Plan monitoring, backups and upgrades for each component. Confirm the exact supported versions in the configuration documentation before you size the environment.
Questions to answer before you pick a side
Start with hosting, because it decides whether this comparison is open at all. Looker (Google Cloud core) instances are hosted by Google in Google Cloud and are not offered for customer-hosted or multicloud environments, so if your policy requires BI to run in your own data center, a specific cloud account or an air-gapped network, the choice is already made. Confirm with your cloud and data residency owners whether Google Cloud hosting is acceptable for the data classes that flow through your dashboards, including who in the organization can see the Looker instance's administrative and query logs. Superset, by contrast, runs wherever you can deploy its Flask and React application, metadata database and optional caching and worker components.
Next, measure how much LookML and Looker content must carry over. Count the LookML projects, their Git repositories, the models and explores, the Looks and dashboards that business users depend on, and the scheduled deliveries. Superset does not read LookML, so every measure, join and access rule that lives in a model has to be rebuilt as a dataset metric, a virtual dataset or a warehouse view, or moved into SQL or dbt. Ask the analytics engineers who own the models how much of the logic is business definition and how much is presentation. The larger the share of governed definitions that must be re-expressed, the more the modeling work, not the software, drives the timeline.
Then decide who will run upgrades, backups and incident response after go-live. Superset upgrades call for backing up the metadata database, running superset db upgrade and superset init, testing in staging and reading UPDATING.md for breaking changes. Alerts, reports, async queries and thumbnails also depend on Redis and Celery workers, which need their own patching and monitoring. Name an owner for the platform team, a secondary, and a schedule for applying security releases. Then gather the evidence your security and compliance team will ask for: the SECRET_KEY handling and rotation plan, the authentication design (database, LDAP or OAuth2 with AUTH_ROLES_MAPPING), logging, backup restore tests and access reviews. DeployOpen prepares controls and evidence for assessments, but independent auditors issue any opinion, so ask your auditor early which artifacts they will accept.
How DeployOpen helps you evaluate, implement or migrate
DeployOpen plans, implements and supports self-hosted Apache Superset inside your own cloud accounts, data centers or air-gapped networks. We start from your Looker instance, its LookML project and the governed metrics your teams depend on, then agree the work in writing before anything changes.
How we scope
- We inventory LookML views, explores, measures and the warehouse tables they query.
- We confirm which metrics need unified definitions in Superset datasets and which belong in the warehouse.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We deploy Superset with PostgreSQL or MySQL metadata databases and configure SSO through your identity provider.
- We rebuild datasets, metric definitions and dashboards, and test them side by side with Looker outputs.
- We add the caching layer and Celery workers only where alerts, reports or async queries are needed.
How we hand over
- You receive architecture, configuration, role mapping and runbooks written for your environment.
- We document the upgrade path, including database backups, staging tests and reviewing UPDATING.md before each version change.
- Metric definitions and modeling decisions are recorded so your team can maintain them after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers.
- Retainers can cover Superset version upgrades, security patches and changes to datasets and roles.
- Ask any provider to confirm which Superset release line and Kubernetes install method they will support.
