HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
tbicr
django-pg-zero-downtime-migrations
Python2018–2026
tbicr / django-pg-zero-downtime-migrations

django-pg-zero-downtime-migrations

Django postgresql backend that apply migrations with respect to database locks

Web DevelopmentData & Databases
Explore on GitHubRead Hacker News discussions
3Distinct people
4Mentions
0Explicit recommenders
574GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Django postgresql backend that apply migrations with respect to database locks

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year4 dated mentions

Observed mentions: 2018-10-23 08:13:58 UTC to 2026-01-28 15:11:47 UTC.

012018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments20182019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC110
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC110
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC000
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC000
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC101
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC000
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC000
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC000
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC101

What Hacker News says

4 sources
tmarice·Jan 28, 2026
This is not specific to Django, but to any project using a database. Here's a list of a couple quite useful resources I used when we had to address this: * https://github.com/tbicr/django-pg-zero-downtime-migrations * https://docs.gitlab.com/development/migration_style_guide/ * https://pankrat.github.io/2015/django-migrations-without-dow... * https://www.caktusgroup.com/blog/2021/05/25/django-migration... * https://openedx.atlassian.net/wiki/spaces/AC/pages/23003228/... Generally it's also advisable to set a statement timeout for migrations otherwise you can end up with unintended downtime -- ALTER TABLE operations very often require ACCESS EXCLUSIVE lock, and if you're migrating a table that already has an e.g. very long SELECT operation from a background task on it, all other SELECTs will queue up behind the migration and cause request
Read the rest
timeouts. There are some cases you can work around this limitation by manually composing operations that require less strict locks, but in our case, it was much simpler to just make sure all Celery workers were stopped during migrations.
In Some notes on starting to use Django
techdragon·Feb 21, 2022
While it hasn't been updated in a while, fundamentally https://github.com/pombredanne/django-zerodowntime would be a base for building similar check logic in a DB agnostic way on Django. It has some of the most important checks in place, but could obviously do with adding more sophisticated checks. For Django users using PostgreSQL you can use https://github.com/antonioIrizar/django-check-migration-wtf or https://github.com/yandex/zero-downtime-migrations or https://github.com/tbicr/django-pg-zero-downtime-migrations to provide similar functionality to the library this post links to, depending on your exact use case of course.
In Show HN: Zero-downtime PostgreSQL migrations for Ruby on Rails
tbicr·Sep 26, 2019Submission

New Postgres 12 SET NOT NULL constraint creation with minimal lock

New postgres 12 will be released soon and I want to highlight one change you can see in ALTER TABLE SET NOT NULL docs: Ordinarily this is checked during the ALTER TABLE by scanning the entire table; however, if a valid CHECK constraint is found which proves no NULL can exist, then the table scan is skipped. Before 12 for huge tables to avoid long table lock I use next approach instead of SET NOT NULL: ALTER TABLE tbl ADD CONSTRAINT cnstr CHECK (col IS NOT NULL) NOT VALID; ALTER TABLE tbl VALIDATE CONSTRAINT cnstr; With 12 you can extend this approach: ALTER TABLE tbl ALTER COLUMN col SET NOT NULL; ALTER TABLE tbl DROP CONSTRAINT cnstr; But you can have similar approach for previous postgres too: Postgres has ATExecSetNotNull function for SET NOT NULL that set attnotnull to true in pg_attribute and ATRewriteTable that check all values in c
Read the rest
olumn is not null. There are call tree and code: AlterTable ATController ATRewriteCatalogs ATExecCmd ATExecSetNotNull ((Form_pg_attribute) GETSTRUCT(tuple))->attnotnull = true; ATRewriteTables ATRewriteTable ereport(ERROR, (errcode(ERRCODE_NOT_NULL_VIOLATION), So if we sure that column doesn't have nulls we can only change pg_attribute.attnotnull: UPDATE pg_attribute SET attnotnull = TRUE WHERE attrelid = 'tbl'::regclass::oid AND attname = 'col'; Unfortunately this approach require superuser permissions for pg_catalog changes. Why it important? I will use django as example, it has migrations that can down you application for huge table and SET NOT NULL is one of them. So to avoid negative experience for 24x7 working application you probably want to avoid negative consequences with migrations. I have django extension https://github.com/tbicr/django-pg-zero-downtime-migrations that provide same state as standard django, but use different tricks like described above to apply migrations more safe way and described tricks available now.
1 points · Open discussion

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.