Why do the tables generated in the superset database differ depending on the db_type when using version 6.1.0?

[A-little-bit-of-data]

Total number of data tables generated using external PostgreSQL data sources:
ab_group ab_group_role ab_permission ab_permission_view ab_permission_view_role ab_register_user ab_role ab_user ab_user_group ab_user_role ab_view_menu alembic_version annotation annotation_layer cache_keys css_templates dashboard_roles dashboard_slices dashboard_user dashboards database_user_oauth2_tokens dbs dynamic_plugin embedded_dashboards favstar key_value keyvalue logs query report_execution_log report_recipient report_schedule report_schedule_user rls_filter_roles rls_filter_tables row_level_security_filters saved_query slice_user slices sql_metrics sqlatable_user ssh_tunnels tab_state table_columns table_schema tables tag tagged_object task_subscribers tasks themes user_attribute user_favorite_tag

The total number of data tables generated using external MySQL data sources is:
ab_group ab_group_role ab_permission ab_permission_view ab_permission_view_role ab_register_user ab_role ab_user ab_user_group ab_user_role ab_view_menu access_request alembic_version alert_logs alert_owner alerts annotation annotation_layer cache_keys clusters columns css_templates dashboard_email_schedules dashboard_roles dashboard_slices dashboard_user dashboards datasources dbs druiddatasource_user dynamic_plugin favstar keyvalue logs metrics query report_execution_log report_recipient report_schedule report_schedule_user rls_filter_roles rls_filter_tables row_level_security_filters saved_query slice_email_schedules slice_user slices sql_metrics sql_observations sqlatable_user tab_state table_columns table_schema tables tag tagged_object url user_attribute

Using two different databases with different numbers and names of tables, will this have any impact on daily use?

I checked using superset db heads and superset db current, and the results were consistent:
heads: 4b2a8c9d3e1f (head)
current: 4b2a8c9d3e1f (head)

However, there is one significant difference:

# PG
Context impl PostgresqlImpl.
Will assume transactional DDL.

# MySQL
Context impl MySQLImpl.
Will assume non-transactional DDL.

Another question is that I need to migrate existing historical data from PostgreSQL to MySQL. Is there a quick way to

[dosubot[bot]]

The table differences you're seeing are not caused by using different database types (PostgreSQL vs MySQL). They're caused by migration history differences — specifically, how far along the Alembic migration chain each database has been migrated.

Your MySQL instance appears to be an older installation that still contains legacy tables that were dropped in 2023–2024 migrations:

• access_request, alert_logs, alert_owner, alerts, sql_observations, columns, metrics, datasources, clusters, druiddatasource_user, dashboard_email_schedules, slice_email_schedules, url — these were all removed in cleanup migrations [1] [2] [3]

Your PostgreSQL instance appears to be a fresh or fully-migrated installation that has the newer tables (ssh_tunnels, key_value, embedded_dashboards, database_user_oauth2_tokens, user_favorite_tag, etc.) added in 2022–2024 migrations [4] [5] [6].

Even though superset db heads and superset db current show the same revision hash, it's possible your MySQL database was brought to head from a much older starting point where some migrations didn't execute cleanly (MySQL uses non-transactional DDL, meaning failed migrations can leave partial state). Superset uses a single unified migration path — there are no database-type-specific branches [7].

Impact on daily use: If both databases report the same head revision and Superset starts without errors, it should function normally. The leftover legacy tables in MySQL are just orphaned — they aren't used by current code. The missing newer tables in MySQL would be a problem if they're actually missing (features like SSH tunnels, embedded dashboards, etc. wouldn't work).

Regarding migrating from PostgreSQL to MySQL: There is no officially supported tool for this. The recommended approach would be:

1. Set up a fresh MySQL instance and run superset db upgrade from scratch
2. Use Superset's built-in dashboard/chart JSON export/import to transfer your dashboards and charts
3. Manually recreate database connections and user/role configurations
4. Do not attempt a raw database dump-and-restore across dialects — data types, JSON handling, and text column types differ between PostgreSQL and MySQL [8] [9]

I'd recommend verifying your MySQL installation by checking whether the newer tables actually exist — if they don't, you may need to troubleshoot your migration history.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[A-little-bit-of-data]

I cleared the Superset database in MySQL and performed a completely fresh installation. The number of tables and the table names now match, but in the settings section—using MySQL 6.1.0—several tabs are missing (specifically the ones on the far right). What is causing this issue?

[dosubot[bot]]

The missing tabs in Settings are not caused by using MySQL — they're controlled by feature flags in your superset_config.py. Several Settings menu items are hidden by default unless you explicitly enable their corresponding feature flags.

Key feature flags that control Settings tabs visibility [1]:

Settings Item	Feature Flag
Tags	TAGGING_SYSTEM
Alerts & Reports	ALERT_REPORTS
Plugins	DYNAMIC_PLUGINS

Additionally, configuration flags control the Security section items [2]:

• SUPERSET_SECURITY_VIEW_MENU → List Users, List Roles, List Groups
• FAB_ADD_SECURITY_VIEWS + SUPERSET_LOG_VIEW → Action Log

If these tabs are present in your PostgreSQL installation but missing in MySQL, it's almost certainly because your PostgreSQL instance has a superset_config.py with these feature flags enabled, while your fresh MySQL installation is using defaults.

To fix this, add the relevant flags to your superset_config.py:

FEATURE_FLAGS = {
    "TAGGING_SYSTEM": True,
    "ALERT_REPORTS": True,
    # add others as needed
}

Then restart Superset. The tabs should appear regardless of database backend.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[A-little-bit-of-data]

Apart from using an external MySQL database, I haven't made any other changes. Regarding your comment—that the issue is almost certainly due to the PostgreSQL instance using a superset_config.py file with specific feature flags enabled, whereas the new MySQL installation uses default settings—could you specify exactly which features these are? I’d like to compare the configurations between the two environments.

[dosubot[bot]]

Here are the default values for all feature flags that affect Settings menu visibility — they are all False (disabled) by default in a vanilla Superset installation [1]:

Feature Flag	Default	Controls
TAGGING_SYSTEM	False	"Tags" tab in Settings → Manage
ALERT_REPORTS	False	"Alerts & Reports" tab in Settings → Manage
DYNAMIC_PLUGINS	False	"Plugins" tab in Settings → Manage
EMBEDDED_SUPERSET	False	Embedded dashboard functionality
SSH_TUNNELING	False	SSH tunnel options in database connections

If both your PostgreSQL and MySQL installations use default settings with no custom superset_config.py, they should show the same tabs. The fact that your PostgreSQL setup shows more tabs suggests something is enabling those flags — likely through:

1. Your deployment method — Docker images, Helm charts, or managed distributions often ship a pre-configured superset_config.py or set environment variables like SUPERSET_FEATURE_TAGGING_SYSTEM=true [2]
2. Environment variables — Any env var prefixed with SUPERSET_FEATURE_ will override the default flags at runtime

To compare, check:

• The superset_config.py file in your PostgreSQL deployment (look for a FEATURE_FLAGS dictionary)
• Environment variables in both environments: env | grep SUPERSET_FEATURE_

If your PostgreSQL deployment uses Docker, check the docker-compose.yml or Dockerfile for any config files being mounted or env vars being set — that's likely where the difference lives.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[FrancescoCastaldi]

The difference in table count (53 tables on PostgreSQL vs 60 tables on MySQL) is not caused by different database dialects. It is caused by migration history differences between a clean database initialization versus a database that ran through legacy migrations.

Why MySQL has extra tables

The extra tables present in your MySQL instance (clusters, datasources, columns, metrics, druiddatasource_user, dashboard_email_schedules, slice_email_schedules, alerts, alert_logs) are legacy tables from Superset 1.x through 3.x:

• clusters, datasources, druiddatasource_user: belonged to the legacy Druid connector that was deprecated in SIP-38 and removed.
• dashboard_email_schedules, alerts: belonged to the old email reporting system that was superseded by report_schedule and report_execution_log.

When Superset deprecates features, Alembic migrations deliberately avoid destructive DROP TABLE statements on production databases to prevent accidental data loss. As a result, an older database upgraded over time retains these legacy tables. A freshly initialized PostgreSQL database created directly on modern Superset only creates currently active models.

Does this impact daily use?

No, there is zero impact on daily operations. The active SQLAlchemy ORM models in Superset 6.1.0 strictly query the 53 core tables. The remaining legacy tables in MySQL are completely inert and ignored by the application.

Recommended Method to Migrate Historical Data from PostgreSQL to MySQL

Do not attempt raw SQL table dumps between PostgreSQL and MySQL because column data types (such as BOOLEAN vs TINYINT, JSONB vs JSON/LONGTEXT, and datetime microseconds) differ between the two engines.

The cleanest and officially supported migration paths are:

1. Metadata Export/Import (Zero Risk):
   Use the Superset CLI to export your assets to portable YAML bundles:

superset export-dashboards -f dashboards.zip
superset export-datasources -f datasources.zip

Import them into your target instance using superset import-dashboards and superset import-datasources. This re-hydrates all charts, dashboards, and datasets cleanly into the destination schema.

2. Using pgloader (Direct Database Migration):
   If migrating the entire database directly, use pgloader with a command file configured to map types cleanly, excluding the legacy tables mentioned above.