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 [email protected]. To unsubscribe, please send an email to: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
