This is probably a regression. Back in 2014, it was already reported and fixed thanks to Dan. See reference [1] on the bottom.

It all seems to be related to the use of nested SAVEPOINTs (Tx + Sp or Sp + Sp) and FK operations.

Here's the simple python script to reproduce the issue:

import sqlite3
import os

DATABASE_FILE = "/tmp/test.sqlite3"
JOURNAL_FILE = f"{DATABASE_FILE}-journal"


def prepare_database():
    if os.path.exists(DATABASE_FILE):
        os.remove(DATABASE_FILE)
    if os.path.exists(JOURNAL_FILE):
        os.remove(JOURNAL_FILE)

    result = sqlite3.connect(DATABASE_FILE)
    result.isolation_level = None

    # Requirement (1): 'PRAGMA foreign_keys = ON;'
    result.executescript("""
        PRAGMA page_size = 4096;
        PRAGMA temp_store = MEMORY;
        PRAGMA synchronous = OFF;
        PRAGMA journal_mode = DELETE;
        PRAGMA foreign_keys = ON;
        """)

    # Requirement (2): foo_id is FK
    result.executescript("""
        CREATE TABLE IF NOT EXISTS foo (
          id       INTEGER PRIMARY KEY,
          data     TEXT DEFAULT NULL
        );
        
        CREATE TABLE IF NOT EXISTS bar (
          id       INTEGER PRIMARY KEY,
          foo_id   INTEGER,
          data     TEXT DEFAULT NULL,
          FOREIGN KEY(foo_id) REFERENCES foo(id) ON DELETE RESTRICT
        );
        """)

    # Optional requirement: causes x3 more memory consumption
    result.execute("CREATE INDEX IF NOT EXISTS foo_bar_idx ON bar(foo_id, id);")

    # Just filling the data
    result.execute("BEGIN IMMEDIATE;")
    result.execute("INSERT INTO foo(id) VALUES(1),(2);")
    for i in range(1, 500000):
        result.execute(f"INSERT INTO bar(id, foo_id) VALUES({i}, 1);")
    result.execute("COMMIT;")
    return result


def main():
    db = prepare_database()

    # Requirement (3): top-level transaction
    db.execute("BEGIN IMMEDIATE;")
    # Requirement (4): savepoint inside top-level transaction
    db.execute("SAVEPOINT foo1;")

    # This is the place where memory consumption skyrockets
    # Each update allocates a large chunk of memory
    for i in range(1, 500000):
        db.execute(f"UPDATE bar SET foo_id = 2 WHERE id = {i};")

    # At this point, RAM consumption is around 6GiB
    db.close()

    # This is a result of *ALL* 4 requirements being met, if either of them isn't:
    #  - (1) foreign_keys not enabled
    #  - or (2) foo_id isn't a FK
    #  - or (3) there's no top-level transaction
    #  - or (4) there's no savepoint
    # then no memory consumption spike occurs


if __name__ == "__main__":
    main()

References

[1] Original thread about similar issue http://sqlite.1065341.n5.nabble.com/Abnormal-memory-usage-when-removing-rows-within-nested-transaction-from-a-table-referenced-by-anothe-td79640.html