django-sqlite-strict

django-sqlite-strict is a drop-in replacement for Django's stock SQLite engine that enforces STRICT tables.

Prerequisites

django-sqlite-strict works on Django webapps that use:

• Django >= 4.2
• SQLite >= 3.37.0

Supported Django versions depend on the Python version in use; see pyproject.toml for the exact dependency constraints.

Install

1. Add as a dependency:

   uv add django-sqlite-strict
   

2. In settings.py, add to INSTALLED_APPS.

   INSTALLED_APPS = [
       ...,
       'django_sqlite_strict',
       ...,
   ]
   

3. In settings.py, configure DATABASES to use it as the engine:

   DATABASES = {
       "default": {
           "ENGINE": "django_sqlite_strict",
           "NAME": BASE_DIR / "db.sqlite3",
       }
   }
   

Features

Compared to Django's stock SQLite backend

SQLite STRICT tables only permit the storage classes INTEGER, REAL, TEXT, BLOB and ANY (source).
To generate valid STRICT tables, django-sqlite-strict maps field types differently to Django's stock SQLite backend. For example:

• CharField is stored as TEXT instead of VARCHAR
• BooleanField as INTEGER instead of BOOL
• DecimalField as REAL instead of DECIMAL

These field remappings affect only the SQL column types used in migrations. Django's Python field API remains unchanged.

[!NOTE] Plain Django DecimalField is stored as REAL so it remains compatible with SQLite STRICT column types. Values wider than SQLite's exact REAL precision may lose precision. For exact decimal storage on SQLite, use django_sqlite_strict.fields.StrictDecimalField, which stores scaled integer minor units.

StrictDecimalField

django_sqlite_strict.fields.StrictDecimalField is a DecimalField subclass that stores exact integer minor units in an INTEGER column instead of storing decimals as REAL. For example, Decimal("19.99") with decimal_places=2 is stored as 1999 and read back as a Decimal.

from django.db import models

from django_sqlite_strict.fields import StrictDecimalField


class Order(models.Model):
    total_price = StrictDecimalField(max_digits=18, decimal_places=2)

• Round-trips are exact for max_digits <= 18. The dss.E003 check guards against wider fields because they could overflow SQLite's 8-byte INTEGER.
• Values with more decimal places than the field declares raise ValueError on save.
• Lookups and ordering work normally because comparisons are scaled to the stored integer value.
• SQL-side arithmetic, including F() expressions, and raw SQL use the stored minor units, ie. 1999 rather than 19.99.

System checks

django-sqlite-strict will register the following Django system checks:

• check_column_types
  Raises an error if any entry in the DATABASES setting has a column of a type that is not accepted by STRICT tables.
• check_tables_are_strict
  Raises an error if a model's table already exists in the database but is not STRICT, ie. the ENGINE was switched without running convert_to_strict.
• check_decimal_max_digits
  Raises a warning if a DecimalField has max_digits set to a value higher than the '15 significant digits' threshold up to which SQLite's REAL stores decimals.
• dss.E003
  Raises an error if a StrictDecimalField has max_digits > 18, meaning its integer minor units could overflow SQLite's 8-byte INTEGER. Runs on every ./manage.py check.

Management commands

• convert_to_strict
  Rebuilds existing non-STRICT tables as STRICT ones. Pass --dry-run to preview the effect of this command, and --no-input for use in CI pipelines.

Escape hatches

When you own the model, prefer mapping unsupported field types to STRICT-compatible storage, for example use StrictDecimalField for exact decimals.
For third-party app models, setting the strict_exempt_tables option allows specified tables to be created with Django's stock non-STRICT template. Exempt tables are skipped by the checks & the convert_to_strict management command.

DATABASES = {
    "default": {
        "ENGINE": "django_sqlite_strict",
        "NAME": BASE_DIR / "db.sqlite3",
        "OPTIONS": {
            "strict_exempt_tables": ["some_third_party_table"],
        },
    }
}

Develop

Development prerequisites

The following tools must be available locally to develop django-sqlite-strict:

• uv
• prek

Run tests

The project aims for 100% test coverage. nox is used to run the test suite against all supported Python/Django pairings (see noxfile.py).

# run latest supported Python/Django pairing only
# (eg. Python 3.14 / Django 6.1)
uvx nox

# run all test sessions
# (ie. all supported Python/Django pairings)
uvx nox -s test

Use the development version in projects

Build the package as a binary distribution (wheel) and install it in a Django project:

# in django-sqlite-strict's root directory
uv build

# in the target Django webapp project
uv add ~/Projects/django-sqlite-strict/dist/django_sqlite_strict-M.m.p-py3-none-any.whl

Acknowledgements

This package was inspired by Martin Dørum's advocacy for STRICT tables in the article SQLite should have (Rust-style) editions.

Shameless self-promotion

Starting a new Django project? Try djereo for a Django project template with modern defaults.

Try pycliché for a no-nonsense Python project template with opinionated tooling.

19th century apparatus to enforce STRICT columns (source, Eton College)