Re: [D] Why do the tables generated in the `superset` database differ depending on the `db_type` when using version 6.1.0? [superset]

["FrancescoCastaldi (via GitHub)" <gi...@apache.org>]

GitHub user FrancescoCastaldi added a comment to the discussion: Why do the tables generated in the `superset` database differ depending on the `db_type` when using version 6.1.0?

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:
```bash
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.


GitHub link: https://github.com/apache/superset/discussions/41354#discussioncomment-19164793

----
This is an automatically sent email for notifications@superset.apache.org.
To unsubscribe, please send an email to: notifications-unsubscribe@superset.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org