Registry / database / migra
library3.0.1663481299pypypiunverified

migra is a Python library that functions like `diff` for PostgreSQL schemas. It compares two PostgreSQL databases (or SQLAlchemy metadata objects) and generates the SQL statements necessary to migrate one to the other, making schema management and deployment safer and more explicit. The current version is 3.0.1663481299, with releases following active development.

pip install migra
INSTALL
IMPORT
SIG · MIGRA
M
migra
databasepythonv3.0.1663481299
Install
3.6s avg
Import
1096ms
Disk
43MB
Pass rate
10/ 10
Env Coverage10 / 10
glibc
3.93.13
musl
3.93.13
Install & Compatibility
Where this runs
tested against v3.0.1663481299 · pip install
no network on importno background threads
Install × environment matrix
Each cell = how many times install + import succeeded across repeated harness runs. Partial = flaky.
glibc = Debian/Ubuntu slim · musl = Alpine Linux
musl
py 3.103.910 runs
installs and imports cleanly · install 0.0s · import 0.702s · 44.5MB
glibc
py 3.103.910 runs
installs and imports cleanly · install 3.6s · import 0.613s · 43MB
43MB installed
● package 43MB
Code
Verified usage

Verified import paths — ran on the pinned version, not inferred.

Migration
from migra import Migration
from migra import Migration

This quickstart compares a defined SQLAlchemy `MetaData` schema with a live (potentially empty) target PostgreSQL database. It generates the DDL needed to make the target schema match the source. Remember to set `POSTGRES_SOURCE_URL` and `POSTGRES_TARGET_URL` environment variables to your actual PostgreSQL connection strings. Always review the generated SQL before applying it to a production database.

import os from migra import Migration from sqlalchemy import create_engine, MetaData, Table, Column, Integer, String # Use environment variables for PostgreSQL connection strings for safety # Ensure POSTGRES_SOURCE_URL and POSTGRES_TARGET_URL are set to real PostgreSQL databases. # For a demo, you can point them to two different databases on the same host, # or create a temporary 'source' schema and an empty 'target' schema. source_url = os.environ.get('POSTGRES_SOURCE_URL', 'postgresql+psycopg2://user:pass@localhost:5432/source_db') target_url = os.environ.get('POSTGRES_TARGET_URL', 'postgresql+psycopg2://user:pass@localhost:5432/target_db') # Establish SQLAlchemy engines source_engine = create_engine(source_url) target_engine = create_engine(target_url) # Define a simple schema for the "source" database (what we want the target to look like) source_metadata = MetaData() Table('users', source_metadata, Column('id', Integer, primary_key=True), Column('name', String(50), nullable=False), Column('email', String(100), unique=True)) # Apply the source schema to the source database (if not already there) print("Ensuring source schema exists in source_db...") with source_engine.connect() as conn: source_metadata.create_all(conn) conn.commit() # The target database is assumed to be empty or have an older schema. # migra will generate SQL to make target look like source. # Create a Migration object to compare the live schemas m = Migration(source=source_engine, target=target_engine) # Get the DDL statements to transform target to source sql_statements = m.statements print("\nGenerated SQL statements to migrate target_db to source_db schema:") if sql_statements: for stmt in sql_statements: print(stmt) # To apply the migration to the target database (UNCOMMENT WITH EXTREME CAUTION!) # print("\nApplying migration to target database...") # with target_engine.connect() as conn: # m.apply(conn) # conn.commit() # print("Migration applied successfully.") else: print("No migration statements needed (schemas are identical or target is already ahead).")
migra --version
Debug
Known issues
gotchaMigra performs destructive operations (e.g., `DROP` and `CREATE`) for schema changes it cannot intelligently alter directly (like column type changes, renames without explicit hints, or complex constraint modifications). Always review generated SQL statements carefully before applying.
fix
Always inspect `m.statements` output before calling `m.apply()`. Manually adjust complex migrations if needed.
affects: All
gotcha`migra` directly modifies your PostgreSQL database when `m.apply()` is called. This can lead to data loss or schema corruption if used improperly. It operates on schema, not data integrity during evolution.
fix
Always use `m.statements` to perform a dry run. Back up your target database before applying any migration, especially in production environments. Consider wrapping `m.apply()` in a transaction for rollback capabilities.
affects: All
gotcha`migra` depends on `psycopg2-binary` for PostgreSQL connectivity. Incompatible versions or a missing installation can lead to runtime errors or failed connections.
fix
Ensure `psycopg2-binary` is correctly installed and compatible with your Python version. If `pip install migra` doesn't resolve it, try `pip install psycopg2-binary` explicitly.
affects: All
Upgrade
Version history
3.0.1663481299latest on PyPI · released Sep 18, 2022
Audit
Dependencies
psycopg2-binaryrequiredRequired for PostgreSQL database connectivity.
Agent activity
11 hits · last 30 days
node
10
Amazon
1
Resources
migra — pip install migra · libregistry