Обновите схему базы данных sqlite с помощью sqlalchemy и elixir

То, о чем вы говорите, — известная и достаточно сложная проблема. Это известно как миграция базы данных. В каждом хорошем проекте есть определенная политика, описывающая, как следует применять схему базы данных и мутации данных для перехода от одной версии продукта к другой.

Многие фреймворки, такие как Django или Ruby on Rails, имеют встроенную или доступную в виде подключаемого модуля систему миграции. В вашем случае с SQLAlchemy есть несколько вариантов:

1. Не используйте никакую систему. Просто напишите /tmp/migrate.sql руками, запишите операторы ALTER/DROP/CREATE, скрестите пальцы и примените его к своей базе SQLite. Как правило, это плохая идея, поскольку она подвержена ошибкам, но выбор за вами. Отсутствие полнофункционального оператора ALTER TABLE можно обойти, создав новый столбец с нужными свойствами с временным именем, скопировав в него все данные из исходного столбца, удалив исходный столбец и переименовав новый столбец с исходным именем. Тот же метод можно использовать на уровне таблицы.
2. Используйте стороннюю систему миграции, например liquibase. Liquibase классная, хорошо спроектированная и мощная, за исключением одного недостатка. Это действительно глючит. Я попробовал его для SQLite (и да, для SQLAlchemy, но на самом деле это не имеет значения), и он не смог сделать некоторые довольно простые вещи. Я искал проблемы и обнаружил, что это известные ошибки.
3. Используйте SQLAlchemy-migrate, о котором вы упомянули. Он не такой мощный, как ROR-миграции, которыми он был вдохновлен, и не такой мощный, как Liquibase, но он работает. Ограничение SQLite можно обойти таким же образом.

И вы спросили о том, что сделает SQLAlchemy-migrate, если вы попытаетесь удалить столбец. Что ж, он удалит столбец и, следовательно, удалит все данные, которые были в нем. Остальные столбцы в таблице останутся нетронутыми.

Более поздней альтернативой sqlalchemy-migrate является alembic, написанный самим автором SQLAlchemy. Хотя последнее («тот же автор») выглядит сильным аргументом, недостатком может быть то, что он не поддерживает ALTERation таблицы с SQLite, т. е. не имеет встроенных обходных путей для отсутствующей поддержки ALTER в SQLite. (Можно возразить, что это выходит за рамки и вполне может быть решено с помощью специализированного пакета Python или расширения SQLite.)

Что вас смущает в sqlalchemy-migrate? У него есть параметры --preview_sql и --preview_py для предварительного просмотра того, что он собирается делать. В общем случае невозможно выполнить правильную миграцию для любого возможного случая, но вы можете изменить сгенерированный сценарий миграции в соответствии с вашими потребностями. На остальные легко получить ответы, попробовав.