GitHub user dosubot[bot] added a comment to the discussion: superset db upgrade fails with migration generated immediately after fresh setup of Apache Superset 4.1.4 (PostgreSQL)
<!-- Greeting --> Hi @csronakpadaliya! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the superset team. <!-- Answer --> The error happens because when you switch Superset's metadata database from the default (like SQLite) to PostgreSQL and then run `superset db migrate`, Alembic compares the Python models (which use a Python Enum for `limiting_factor`) to the actual database schema (which, per the official migrations, uses a plain VARCHAR column). Alembic sees this as a type mismatch and tries to generate a migration that alters the column to a PostgreSQL enum type called `limitingfactor`—but that type doesn't exist in the database, nor is it created by any official Superset migration. That's why you get the "type 'limitingfactor' does not exist" error during `superset db upgrade` [source](https://github.com/apache/superset/blob/829e4d92d91ceae4b43b1ed3b063ffe45377799c/superset/migrations/versions/2021-04-16_17-38_d416d0d715cc_add_limiting_factor_column_to_query_.py). **How to avoid and fix this:** - Never run `superset db migrate` immediately after switching the metadata database backend unless you have actually changed the models. The official schema for Superset expects the `limiting_factor` column to be a VARCHAR, not a PostgreSQL enum. - If you want to switch the metadata database (e.g., from SQLite to PostgreSQL), you should: 1. Start with a fresh, empty PostgreSQL database. 2. Point Superset to it. 3. Run `superset db upgrade` to apply all official migrations and create the schema. 4. (Optional) Import your data using Superset's import/export commands if needed. - If you already generated and applied a migration that tries to use the `limitingfactor` enum, you'll need to manually fix your schema. Drop the generated migration, ensure the `query.limiting_factor` column is of type VARCHAR(255), and re-run `superset db upgrade` [source](https://github.com/apache/superset/blob/829e4d92d91ceae4b43b1ed3b063ffe45377799c/superset/migrations/versions/2021-04-16_17-38_d416d0d715cc_add_limiting_factor_column_to_query_.py). **Best practices for migrations and backend switching:** - Always use the official migration scripts and avoid generating new migrations unless you have custom model changes. - If you see migration errors about missing types or columns, check that your Alembic migration history (`alembic_version` table) matches the expected state for your Superset version. - For enum-related errors, make sure your schema matches the official migrations, which typically use VARCHAR for enum-like fields, not PostgreSQL enums [discussion](https://github.com/apache/superset/discussions/33616#discussioncomment-13309116). If you need to recover from a broken migration state, you may need to manually adjust the schema or reset the metadata database and reapply the official migrations. Always back up your data before making manual changes. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/01a8e5ec-2106-4baf-8268-5dc5f6e09691?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/01a8e5ec-2106-4baf-8268-5dc5f6e09691?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/01a8e5ec-2106-4baf-8268-5dc5f6e09691?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/01a8e5ec-2106-4baf-8268-5dc5f6e09691?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/01a8e5ec-2106-4baf-8268-5dc5f6e09691?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/01a8e5ec-2106-4baf-8268-5dc5f6e09691?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/01a8e5ec-2106-4baf-8268-5dc5f6e09691?feedback_type=other)</sup> [](https://app.dosu.dev/a28d3c7e-a9d3-459e-9fb6-3a6f9ff4f357/ask?utm_source=github) [](https://cursor.com/link/prompt?text=The%20error%20happens%20because%20when%20you%20switch%20Superset%27s%20metadata%20database%20from%20the%20default%20%28like%20SQLite%29%20to%20PostgreSQL%20and%20then%20run%20%60superset%20db%20migrate%60%2C%20Alembic%20compares%20the%20Python%20models%20%28which%20use%20a%20Python%20Enum%20for%20%60limiting_factor%60%29%20to%20the%20actual%20database%20schema%20%28which%2C%20per%20the%20official%20migrations%2C%20uses%20a%20plain%20VARCHAR%20column%29.%20Alembic%20sees%20this%20as%20a%20type%20mismatch%20and%20tries%20to%20generate%20a%20migration%20that%20alters%20the%20column%20to%20a%20PostgreSQL%20enum%20type%20called%20%60limitingfactor%60%E2%80%94but%20that%20type%20doesn%27t%20exist%20in%20the%20database%2C%20nor%20is%20it%20created%20by%20any %20official%20Superset%20migration.%20That%27s%20why%20you%20get%20the%20%22type%20%27limitingfactor%27%20does%20not%20exist%22%20error%20during%20%60superset%20db%20upgrade%60%20%5Bsource%5D%28https%3A//github.com/apache/superset/blob/829e4d92d91ceae4b43b1ed3b063ffe45377799c/superset/migrations/versions/2021-04-16_17-38_d416d0d715cc_add_limiting_factor_column_to_query_.py%29.%0A%0A%2A%2AHow%20to%20avoid%20and%20fix%20this%3A%2A%2A%0A%0A-%20Never%20run%20%60superset%20db%20migrate%60%20immediately%20after%20switching%20the%20metadata%20database%20backend%20unless%20you%20have%20actually%20changed%20the%20models.%20The%20official%20schema%20for%20Superset%20expects%20the%20%60limiting_factor%60%20column%20to%20be%20a%20VARCHAR%2C%20not%20a%20PostgreSQL%20enum.%0A-%20If%20you%20want%20to%20switch%20the%20metadata%20database%20%28e.g.%2C%20from%20SQLite%20to%20PostgreSQL%29%2C%20you%20should%3A%0A%20%201.%20Start%20with%20a%20fresh%2C%20empty%20PostgreSQL%20database.%0A%20%202.%20Point %20Superset%20to%20it.%0A%20%203.%20Run%20%60superset%20db%20upgrade%60%20to%20apply%20all%20official%20migrations%20and%20create%20the%20schema.%0A%20%204.%20%28Optional%29%20Import%20your%20data%20using%20Superset%27s%20import/export%20commands%20if%20needed.%0A-%20If%20you%20already%20generated%20and%20applied%20a%20migration%20that%20tries%20to%20use%20the%20%60limitingfactor%60%20enum%2C%20you%27ll%20need%20to%20manually%20fix%20your%20schema.%20Drop%20the%20generated%20migration%2C%20ensure%20the%20%60query.limiting_factor%60%20column%20is%20of%20type%20VARCHAR%28255%29%2C%20and%20re-run%20%60superset%20db%20upgrade%60%20%5Bsource%5D%28https%3A//github.com/apache/superset/blob/829e4d92d91ceae4b43b1ed3b063ffe45377799c/superset/migrations/versions/2021-04-16_17-38_d416d0d715cc_add_limiting_factor_column_to_query_.py%29.%0A%0A%2A%2ABest%20practices%20for%20migrations%20and%20backend%20switching%3A%2A%2A%0A-%20Always%20use%20the%20official%20migration%20scripts%20and%20avoid%20gen erating%20new%20migrations%20unless%20you%20have%20custom%20model%20changes.%0A-%20If%20you%20see%20migration%20errors%20about%20missing%20types%20or%20columns%2C%20check%20that%20your%20Alembic%20migration%20history%20%28%60alembic_version%60%20table%29%20matches%20the%20expected%20state%20for%20your%20Superset%20version.%0A-%20For%20enum-related%20errors%2C%20make%20sure%20your%20schema%20matches%20the%20official%20migrations%2C%20which%20typically%20use%20VARCHAR%20for%20enum-like%20fields%2C%20not%20PostgreSQL%20enums%20%5Bdiscussion%5D%28https%3A//github.com/apache/superset/discussions/33616%23discussioncomment-13309116%29.%0A%0AIf%20you%20need%20to%20recover%20from%20a%20broken%20migration%20state%2C%20you%20may%20need%20to%20manually%20adjust%20the%20schema%20or%20reset%20the%20metadata%20database%20and%20reapply%20the%20official%20migrations.%20Always%20back%20up%20your%20data%20before%20making%20manual%20changes.) [](https://go.dosu.dev/discord-bot) [](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/apache/superset/discussions/36236) GitHub link: https://github.com/apache/superset/discussions/36236#discussioncomment-15060497 ---- 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]
