Hi @taavi! While I understand the original intention of having a public Superset instance is to replace Quarry, which didn't happen. We have been using Quarry to develop and run queries against Wiki replicas, while Superset is really intended for visualization and dashboard. Unless someone has the need for latter, they don't have the need to go to Superset instance - which may have been the case with many users of Quarry.

But the public Superset instance actually solves a different problem - a public dashboard/visualization platform, for custom metrics and reporting (and currently there is no alternative to it). It's a really useful to have such a platform. Here are a couple of examples:

• https://superset.wmcloud.org/superset/dashboard/unified-automoderator-activity-dashboard/ (cc @Samwalton9-WMF)
  • It surfaces the activity of Automoderator on wikis where it deployed, and for community members to monitor it. - T369488
• https://superset.wmcloud.org/superset/dashboard/unified-cx-metrics/ (cc @santhosh, @Pginer-WMF)
  • Usage of Content Translation tool on various wikis and its impact (also to monitor) - T365813

These are actively used by both staff and volunteers. Happy to chat more.

Perhaps just keeping it on maintenance mode, with no further additions could be considered.

In T416373#11580024, @KCVelaga_WMF wrote:

Perhaps just keeping it on maintenance mode, with no further additions could be considered.

Unmaintained projects are not ideal as they eventually lead to a security compromise or an unexpected outage that begs for hero intervention. It would certainly be possible for a group of technical volunteers (staff or not) to decide to operate a superset instance as a Cloud VPS project if there is energy for that.

Might it be possible to enable superset.wikimedia.org dashboards to be publicly viewable?

@bd808 I believe having a public instance is still useful for the usecases I mentioned above, even if that was not the originally intended goal. We can try Cloud VPS, but recreating dashboard, configuring DB etc. will be take some time, and not sure how much effort it would be.

In T416373#11588290, @Samwalton9-WMF wrote:

Might it be possible to enable superset.wikimedia.org dashboards to be publicly viewable?

@Samwalton9-WMF I remember having that conversation with DPE (more than a year ago). It's bit tricky as it involves creating a new users, and we have internal private datasets that are accessible from that instance. Also, that is connected to internal data lake (private by default), and this is connected to public ToolsDB and wiki-replicas.

https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/thread/N3CNQHEUFDLQT3HK2SJDANYTEDMNIDDV/

Sent to cloud-announce and wikitech-l:

Summary:

The Cloud Services implementation of Superset (https://superset.wmcloud.org) is currently unsupported by WMF staff. We would welcome a volunteer stepping up to maintain it, but without a new home the service will be shut down at the end of March.

If you would like to take on ownership of this service, please reach out to WMCS staff or comment on the phabricator task[1]. The day-to-day maintenance load is minimal, but someone will need to keep track up updates, security concerns and a potential future of defense against AI scraping.

Background:

There has always been demand from researchers and volunteers to run one-off queries against Wikimedia datasets. Quarry.wmcloud.org was build and launched by the WMF more than 10 years ago. Originally a one-person skunkworks project, it soon caught on in popularity as one of the most trafficked services run by Wikimedia Cloud Services.

A few years ago, we launched superset.wmcloud.org[0] as an intended Quarry replacement. We soon learned that despite being a less polished, home-made tool, Quarry provides many features that Superset does not, and most users resisted migration away from it. Superset has only a handful of active users.

At this point, Superset is essentially unsupported by WMF staff; as part of ongoing efforts to improve our support for Toolforge and other more popular services we will be either shutting it off or transferring ownership of Superset in a few weeks[1].

[0] https://phabricator.wikimedia.org/T169452
[1] https://phabricator.wikimedia.org/T416373

Over the years, data has been useful in conversations with communities. For projects like content Translation, getting to a shared understanding of how much content is created, which are the deletion rates, how the content creation is distributed acoss editors of different edit count levels, etc. has helped to get into more nuanced conversations. One of th eproblems we encountered is that the data, for example when using Turnilo, was not publicly available. Having a public instance of Superset seemed like useful way to provide communities with this data in a way that they can have a better understanding earlier and in a more independent way. If it is shutting down, it would be good to understand. which will be the available alternatives to provide communities with that kind of support.

If it is shutting down, it would be good to understand. which will be the available alternatives to provide communities with that kind of support.

Quarry accesses the same datasets as the superset install, so any query that works in superset should be available there as well.

If you want to make a pitch for preserving superset, please detail the specific use case that's not supported on Quarry and which current users will be affected by the deprecation. Thanks!

In T416373#11665536, @Andrew wrote:

If it is shutting down, it would be good to understand. which will be the available alternatives to provide communities with that kind of support.

Quarry accesses the same datasets as the superset install, so any query that works in superset should be available there as well.

Let's imagine the Bangla Wikipedia community having a conversation about the number of deleted translations. With the current Superset they can access this view:

That provides an understanding of the deletion percentages comparing translation with other ways to create articles and its evolution over time with an option to adjust the time range or look to the results of other wikis.
This overview seems intuitive and does not require any technical knowledge (SQL or database internals).

I tried to copy over the query for that graph to Quarry, but I was getting an error. Despite the error, I have the impression that Quarry seems quite SQL-centric which may make it hard to serve usecases where communities may need an intuitive overview they can easily adjust without SQL or database knowledge. I'm less familiar with Quarry and maybe the error is preventing me from making a fair comparison. So maybe someone else may be able to illustrate how to support this better with Quarry.

If you want to make a pitch for preserving superset, please detail the specific use case that's not supported on Quarry and which current users will be affected by the deprecation. Thanks!

From my perspective, I don't have a strong preference about a particular tool. I'm more interested in making sure that communities have visibility to the impact our tools have in a way that is intuitive and does not require technical knowledge.

I tried to understand how many people are opening the existing superset dashboards. Unfortunately we only have logs for the past few days, but it looks like there is some ongoing usage:

root@superset-bastion:~# export KUBECONFIG=/home/rook/superset-deploy/tofu/kube.config
root@superset-bastion:~# kubectl logs pod/superset-5d5b4875f9-9nhz6 |awk '{print $4 " " $7}' |grep " /superset" |awk '{print $1}' |cut -d "[" -f2 |cut -d':' -f1 |uniq -c
Defaulted container "superset" out of: superset, wait-for-postgres (init)
      1 01/Mar/2026
    368 02/Mar/2026
    133 03/Mar/2026

The filter is probably not very accurate, but gives a rough estimate of the page views.

A slightly more accurate version:

root@superset-bastion:~# kubectl logs pod/superset-5d5b4875f9-9nhz6 |awk '{print $4 " " $7}' |grep " /superset/dashboard" |awk '{print $1}' |cut -d "[" -f2 |cut -d':' -f1 |uniq -c
Defaulted container "superset" out of: superset, wait-for-postgres (init)
      1 01/Mar/2026
     71 02/Mar/2026
     78 03/Mar/2026
root@superset-bastion:~# kubectl logs pod/superset-5d5b4875f9-9nhz6 |awk '{print $4 " " $7}' |grep " /superset/dashboard" |awk '{print $2}' |sort |uniq -c |sort -nr |head -n10
Defaulted container "superset" out of: superset, wait-for-postgres (init)
     43 /superset/dashboard/p/***/
     19 /superset/dashboard/unified-automoderator-activity-dashboard/
     10 /superset/dashboard/***?permalink_key=***
     10 /superset/dashboard/***/?permalink_key=***
      3 /superset/dashboard/unified-cx-metrics/
      3 /superset/dashboard/unified-automoderator-activity-dashboard/?native_filters_key=***
      3 /superset/dashboard/p/***/
      3 /superset/dashboard/p/***/
      3 /superset/dashboard/p/***/
      3 /superset/dashboard/p/***/

(I blanked all IDs for extra safety, they should not be sensitive but I'm not 100% sure)

In T416373#11665536, @Andrew wrote:

If it is shutting down, it would be good to understand. which will be the available alternatives to provide communities with that kind of support.

Quarry accesses the same datasets as the superset install, so any query that works in superset should be available there as well.

If you want to make a pitch for preserving superset, please detail the specific use case that's not supported on Quarry and which current users will be affected by the deprecation. Thanks!

@Andrew As Pau described in the use case above, the while both can SQL queries against wiki-replicas, Quarry can only run queries and users need to be familiar with SQL. On Superset, we can go a step ahead to create charts and dashboards that non-technical audience can easily understand, which is one of primary purposes of Superset (for data visualization). There are several dashboards that are leveraging exactly that feature. We don't have an alternative for public data visualization and sharing; unless we build a custom application from scratch. While Charts extension supports basic visualizations, it doesn't support functionalities of a typical dashboard like filtering subset of data, navigation etc.

Thanks @fnegri for the data, it looks like there is usage.

I tried to copy over the query for that graph to Quarry, but I was getting an error. Despite the error, I have the impression that Quarry seems quite SQL-centric which may make it hard to serve usecases where communities may need an intuitive overview they can easily adjust without SQL or database knowledge. I'm less familiar with Quarry and maybe the error is preventing me from making a fair comparison. So maybe someone else may be able to illustrate how to support this better with Quarry.

@Pginer-WMF You're right, even if we resolve the query error (we need to check the database), we'd only get a table output in various formats at the best. But we can't visualize data in Quarry. Even if we create some template queries and share with community, it will require some basic SQL knowledge.

I would like to formally volunteer to take on maintainership of the Superset instance at https://superset.wmcloud.org

I am a member of the Indic MediaWiki Developers User Group and have experience working within Wikimedia technical infrastructure and workflows.

From the discussion above, Superset serves a distinct role from Quarry by enabling public, community-facing dashboards that do not require SQL knowledge.

Use case not supported by Quarry

While Quarry is effective for running SQL queries, it is inherently technical and limited to tabular outputs. Superset enables:

• interactive dashboards (filters, time ranges, comparisons)
• visual exploration for non-technical contributors
• shareable public views for community discussions

Examples in use:

1. Content Translation metrics dashboards (T365813)
2. Automoderator activity dashboards (T369488)

These use cases are difficult to replicate in Quarry without requiring SQL knowledge or additional tooling.

Impact and affected users

The current instance supports:

• Wikimedia product teams (e.g., CX, Automoderator)
• community members analyzing trends
• non-technical contributors relying on accessible data

Existing logs also indicate ongoing usage of these dashboards.

Proposed maintainership approach

If there is agreement to continue operating the service, I am willing to:

• act as a primary volunteer point of contact
• help keep the deployment operational and reasonably up to date
• monitor for major updates or security concerns as they arise
• coordinate with WMCS and stakeholders when needed
• focus on maintaining stability rather than introducing new features initially

I am comfortable working with the relevant stack (Cloud VPS, Kubernetes-based deployments, Superset configuration, and wiki-replica data sources), and open to collaborating if a shared maintainership model is preferred.

Adding to the above - there is also recent community-driven usage of this instance.

Members of the Indic MediaWiki Developers User Group have created a dashboard for the Indic community:
https://superset.wmcloud.org/superset/dashboard/indic-wikimedia-community-insights/?native_filters_key=qXP6jvZDTHk7kY_HkC5_ZW0SzOgUX_nytoa0xZX-fpSUQGhEBzh7LqqdnhXcsFE3

This (beta) dashboard includes insights on article growth, edit activity, interface usage, content distribution, and commonly edited pages and templates, demonstrating Superset’s value as a community-facing visual analytics layer beyond SQL-based tools.

@Dev I will add you to the project; can you tell me your toolforge/cloud-vps username or shell name?

@KCVelaga_WMF I have added you as a project member.

@Dev and @KCVelaga_WMF I would like to announce the new stewardship of this project as a followup to this email:

https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/message/N3CNQHEUFDLQT3HK2SJDANYTEDMNIDDV/

Do either of you have objections? And what names would you like me to use for you?

I would like to announce the new stewardship of this project as a followup to this email:
And what names would you like me to use for you?

Sounds good. As I intend to support instance maintenance during my volunteer hours, please use User:KCVelaga. Thank you.

In T416373#11841489, @Andrew wrote:

@Dev I will add you to the project; can you tell me your toolforge/cloud-vps username or shell name?

In T416373#11841498, @Andrew wrote:

@Dev and @KCVelaga_WMF I would like to announce the new stewardship of this project as a followup to this email:

https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/message/N3CNQHEUFDLQT3HK2SJDANYTEDMNIDDV/

Do either of you have objections? And what names would you like me to use for you?

Happy to proceed. You can use User:Dev Jadiya for the announcement. My Cloud VPS / Toolforge shell username is: devjadiya.

Great! The two of you should now have full access to the project -- please follow up here if you find otherwise, and don't hesitate to reach out if there's anything I/we can do to support you.

I do not see a whole lot of documentation for this project, unfortunately. I believe that the deployment closely resembles the PAWS deployment which is reasonably well-documented at https://wikitech.wikimedia.org/wiki/PAWS/Admin

In brief:

The deployment code is in https://github.com/toolforge/superset-deploy.git with an at least partially-useful README. The deployment script creates a kubernetes cluster via Magnum, then deploys onto it with Helm and...maybe does some other things :)

I encourage you to try setting up a test/dummy deployment to make sure that you know how to do that. If you want to write documentation, feel free to use the (not yet existing) https://wikitech.wikimedia.org/wiki/Portal:Cloud_VPS/Admin/Superset

If you need more to go on than that, let me know and I will have a look in the next few days -- in theory I'm off today :)

Thank you so much for taking this on! I will send an email to the list about this tomorrow.

Oh, one other thing, are you happy to continue to use this phab tag for coordinating with users, or do you prefer a different path of contact? It's totally up to you but I'll put a pointer in the announcement email.

Proposed, something like:

Users User:KCVelaga and User:Dev_Jadiya have volunteered to take on maintenance of our Superset install, and I'm in the process of handing over access rights and getting them up to speed.

Users of this project can continue to use the https://phabricator.wikimedia.org/tag/superset.wmcloud.org/ tag and cloud@lists.wikimedia.org for issues and coordination. Do please keep in mind that volunteer maintainers will have other priorities in their lives; I would not suggest building any large-scale or mission-critical stacks on top of Superset without careful discussion with the new maintainers.

Thanks @Andrew, that all sounds good.

Happy to continue using the same Phabricator tag for coordination.

We’ll start by setting up a test/dummy deployment over the next 2-3 weeks to get familiar with the current deployment setup and workflow.

Appreciate the pointers to the PAWS docs and deployment repo - we’ll go through those and follow up here if we run into any issues. Also, mail draft paragraph sounds good.

note to self, also need to sort out github access

Actually, it's going to be tough to untangle that so I suggest that you fork into a new repo that you control.