Default Django Auth migrations don't work

[th7nder]

Describe the bug

When I run python manage.py migrate on fresh DSQL Cluster with

INSTALLED_APPS = [
    "django.contrib.admin",
    "django.contrib.auth",
    "django.contrib.contenttypes",
    "django.contrib.sessions",
    "django.contrib.messages",
    "django.contrib.staticfiles",

Regression Issue

• Select this option if this issue appears to be a regression.

Expected Behavior

It should migrate properly and it does not.

Current Behavior

$ python manage.py migrate
System check identified some issues:

WARNINGS:
?: (staticfiles.W004) The directory '/Users/th7nder/workspace/bedtime_production/backend/static' in the STATICFILES_DIRS setting does not exist.
2025-07-12 14:03:43,005 - botocore.credentials - INFO - Found credentials in environment variables.
Operations to perform:
  Apply all migrations: accounts, admin, auth, contenttypes, payments, sessions, stories, token_blacklist
Running migrations:
  Applying contenttypes.0001_initial...Traceback (most recent call last):
  File "/Users/th7nder/workspace/bedtime_production/backend/manage.py", line 22, in <module>
    main()
    ~~~~^^
  File "/Users/th7nder/workspace/bedtime_production/backend/manage.py", line 18, in main
    execute_from_command_line(sys.argv)
    ~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^
  File "/Users/th7nder/workspace/bedtime_production/backend/venv/lib/python3.13/site-packages/django/core/management/__init__.py", line 442, in execute_from_command_line
    utility.execute()
    ~~~~~~~~~~~~~~~^^
  File "/Users/th7nder/workspace/bedtime_production/backend/venv/lib/python3.13/site-packages/django/core/management/__init__.py", line 436, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^
  File "/Users/th7nder/workspace/bedtime_production/backend/venv/lib/python3.13/site-packages/django/core/management/base.py", line 416, in run_from_argv
    self.execute(*args, **cmd_options)
    ~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/th7nder/workspace/bedtime_production/backend/venv/lib/python3.13/site-packages/django/core/management/base.py", line 460, in execute
    output = self.handle(*args, **options)
  File "/Users/th7nder/workspace/bedtime_production/backend/venv/lib/python3.13/site-packages/django/core/management/base.py", line 107, in wrapper
    res = handle_func(*args, **kwargs)
  File "/Users/th7nder/workspace/bedtime_production/backend/venv/lib/python3.13/site-packages/django/core/management/commands/migrate.py", line 353, in handle
    post_migrate_state = executor.migrate(
        targets,
    ...<3 lines>...
        fake_initial=fake_initial,
    )
  File "/Users/th7nder/workspace/bedtime_production/backend/venv/lib/python3.13/site-packages/django/db/migrations/executor.py", line 135, in migrate
    state = self._migrate_all_forwards(
        state, plan, full_plan, fake=fake, fake_initial=fake_initial
    )
  File "/Users/th7nder/workspace/bedtime_production/backend/venv/lib/python3.13/site-packages/django/db/migrations/executor.py", line 167, in _migrate_all_forwards
    state = self.apply_migration(
        state, migration, fake=fake, fake_initial=fake_initial
    )
  File "/Users/th7nder/workspace/bedtime_production/backend/venv/lib/python3.13/site-packages/django/db/migrations/executor.py", line 255, in apply_migration
    state = migration.apply(state, schema_editor)
  File "/Users/th7nder/workspace/bedtime_production/backend/venv/lib/python3.13/site-packages/django/db/migrations/migration.py", line 132, in apply
    operation.database_forwards(
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~^
        self.app_label, schema_editor, old_state, project_state
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/Users/th7nder/workspace/bedtime_production/backend/venv/lib/python3.13/site-packages/django/db/migrations/operations/models.py", line 717, in database_forwards
    alter_together(
    ~~~~~~~~~~~~~~^
        new_model,
        ^^^^^^^^^^
        from_model_state.options.get(self.option_name) or set(),
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        to_model_state.options.get(self.option_name) or set(),
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/Users/th7nder/workspace/bedtime_production/backend/venv/lib/python3.13/site-packages/django/db/backends/base/schema.py", line 624, in alter_unique_together
    self.execute(s)
    ~~~~~~~~~~~~^^^
  File "/Users/th7nder/workspace/bedtime_production/backend/venv/lib/python3.13/site-packages/django/db/backends/postgresql/schema.py", line 46, in execute
    sql = self.connection.ops.compose_sql(str(sql), params)
  File "/Users/th7nder/workspace/bedtime_production/backend/venv/lib/python3.13/site-packages/django/db/backends/postgresql/operations.py", line 202, in compose_sql
    return mogrify(sql, params, self.connection)
  File "/Users/th7nder/workspace/bedtime_production/backend/venv/lib/python3.13/site-packages/django/db/backends/postgresql/psycopg_any.py", line 107, in mogrify
    return cursor.mogrify(sql, params).decode()
           ~~~~~~~~~~~~~~^^^^^^^^^^^^^
psycopg2.ProgrammingError: can't execute an empty query

Reproduction Steps

Setup a django app with default 'admin' django apps which are necessary to build a application.

Possible Solution

I tried to solve some of the issues, but gave up after a point.

1. Django default migrations are incremental and use ALTER TABLE ADD CONSTRAINT which is not supported. After I created a fresh postgresql docker container, run the migrations on this one and created migrations by hand, still didn't help much, because...
2. Aurora DSQL doesn't support AUTOINCREMENT/Sequence IDs, so I ended up changing every id to "id" uuid NOT NULL DEFAULT gen_random_uuid(). This doesn't help much as Django is not designed to support uuid in those contrib layers.

There are multiple ways one could try to solve it, like writing own contrib.apps with ready-made authentication and stuff.
Curious what's your opinion on that.

Additional Information/Context

No response

version

0.1.0

Environment details (Version of Python, OS environment)

MacOS 15.5

[wcmjunior]

Hi @th7nder . We will analyze this issue and get back to you.

[adamcloudboss]

Hi @wcmjunior any update on this? Same issue for me.

[vic-tsang]

Hi @adamcloudboss,

I am investigating into this issue. I am wondering which issue are you having ?

is it psycopg2.ProgrammingError: can't execute an empty query ? or ALTER Table ? or something else ?

It will be helpful if you can please provide me a log of your error and also a list of values inside your array INSTALLED_APPS

Thanks!

[vic-tsang]

Hi @th7nder

I was able to reproduce your issue via psycopg2 regarding psycopg2.ProgrammingError: can't execute an empty query. We will need to update the schema.py under "aurora_dsql_django". Set all the empty sql string to a no-op sql string such as sql_create_unique = "SELECT 1 WHERE FALSE". We will address this in a future update.

You also mention about ALTER TABLE ADD CONSTRAINT. Do you have more context on that issue ?

PS: FYI psycopg (psycopg3) doesn't error out when executing "" as the sql query.

[vic-tsang]

[EDIT] Please note the workarounds provided here may no longer be relevant in the latest version v0.2.0. See this comment for more detail.

Hi @adamcloudboss and @th7nder,

I have a fix to resolve your migration issue located in this branch. We are in the process of documenting the workarounds. We would like to unblock you first. Please follow the instructions below to complete the migration. If you have any other questions/issues, please let me know!

Known Issues and Solutions

1. When running migrations with the following Django Contrib Apps, you may encounter not-null constraint errors

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions']

Error Message:

django.db.utils.IntegrityError: null value in column "name" of relation "django_content_type" violates not-null constraint

Solution: Allow null values for the following columns

• name from the table django_content_type

  • connect to your DSQL cluster via psql
  • execute the following queries:

    DROP TABLE IF EXISTS "django_content_type";
    
    CREATE TABLE "django_content_type" ("id" integer NOT NULL PRIMARY KEY, "name" varchar(100), "app_label" varchar(100) NOT NULL, "model" varchar(100) NOT NULL);

• last_login from the table auth_user

  • execute the following queries:

    DROP TABLE IF EXISTS "auth_user";
    CREATE TABLE "auth_user" ("id" integer NOT NULL PRIMARY KEY, "password" varchar(128) NOT NULL, "last_login" timestamptz, "is_superuser" boolean NOT NULL, "username" varchar(150) NOT NULL UNIQUE, "first_name" varchar(150) NOT NULL, "last_name" varchar(150) NOT NULL, "email" varchar(254) NOT NULL, "is_staff" boolean NOT NULL, "is_active" boolean NOT NULL, "date_joined" timestamptz NOT NULL);

  • Run python manage.py migrate again. The errors should be resolved.

2. Null is used as the primary key during insertion for tables related to Django Contrib Apps

Solution: Ensure auto primary key generation is enabled

• Add the attribute 'ENABLE_ID_GENERATION_FOR_AUTO_FIELDS': True to DATABASES
• Ensure the DEFAULT_AUTO_FIELD in settings.py is set to either django.db.models.BigAutoField or django.db.models.AutoField

Note: This will automatically generate a default value for the AutoField and BigAutoField which can be used for the primary key.

#settings.py

DATABASES = {
    'default': {
        'HOST': <HOST>,
        'USER': <USER_NAME>,
        'NAME': 'postgres',
        'ENGINE': 'aurora_dsql_django',
        'ENABLE_ID_GENERATION_FOR_AUTO_FIELDS': True,
        'OPTIONS': {
            'sslmode': 'verify-full',
            'region': 'us-east-1'
        }
    }
}


DEFAULT_AUTO_FIELD = 'django.db.models.BigAutoField'

3. DeclareCursor is not supported

Solution: Disable Server Side Cursors

• Add the attribute 'DISABLE_SERVER_SIDE_CURSORS': True to DATABASES in settings.py. Note: DISABLE_SERVER_SIDE_CURSORS should be at the same level as OPTIONS, not within it

#settings.py

DATABASES = {
    'default': {
        'HOST': <HOST>,
        'USER': <USER_NAME>,
        'NAME': 'postgres',
        'ENGINE': 'aurora_dsql_django',
        'DISABLE_SERVER_SIDE_CURSORS': True, # Fixes unsupported statement: DeclareCursor 
        'OPTIONS': {
            'sslmode': 'verify-full',
            'region': 'us-east-1'
        }
    }
}

[danielfrankcom]

@th7nder Thank you for reporting this issue with migrations. We've just released v0.2.0 which improves the handling of migrations in a few areas which should help.

I was able to get the admin webpage working locally with the new version, after following the manual migrations steps in the docs mentioned below.

Empty queries

psycopg2.ProgrammingError: can't execute an empty query

This was caused by empty adapter definitions for features which are not supported by DSQL. We have modified the adapter to better align with supported DSQL features, and now raise a more helpful error when an unsupported feature is used.

You should no longer see this issue.

Unsupported features

Django default migrations are incremental and use ALTER TABLE ADD CONSTRAINT which is not supported. After I created a fresh postgresql docker container, run the migrations on this one and created migrations by hand

As you correctly identified, some of the contrib apps use features which are not supported by DSQL. At this time, manual steps are required to work around these incompatible migrations.

We have improved documentation around this, including a list of migrations which are known to be incompatible here. See the following new docs for more information:

• Known Issues
• Behavior of Aurora DSQL Adapter for Django

The manual steps boil down to recreating the table with the correct schema, and running the following:

python manage.py migrate <app_name> <migration_number> --fake

UUID primary keys

Aurora DSQL doesn't support AUTOINCREMENT/Sequence IDs, so I ended up changing every id to "id" uuid NOT NULL DEFAULT gen_random_uuid(). This doesn't help much as Django is not designed to support uuid in those contrib layers.

Django mainly uses AutoField in the contrib apps to provide primary keys for the necessary tables. The previous adapter version modified AutoField to use UUIDs instead of SERIAL, but it was missing a few components.

The new adapter version provides an improved AutoField implementation for UUID primary keys, which fixes a few of the contrib apps which I tested. The support is not perfect, as there are still incompatibilities such as the site app which assumes the site ID is an integer. From my testing the admin app seems to work okay with UUIDs.

Disable server-side cursors

You didn't mention this in the issue since I think you were blocked before reaching this point, but the admin webpage attempts to use server-side cursors which are not supported by DSQL.

We have updated the adapter to disable these by default, but just mentioning it here as it may be relevant.

Summary

We're closing this issue as the core migration problems have been addressed. The remaining limitations are inherent to Aurora DSQL's feature set and are now properly documented with workarounds where applicable.

Please upgrade to v0.2.0 and migrate again. If you encounter any new issues after upgrading, feel free to open a new ticket. Thanks!

[github-actions]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.