Add SQLModel ORM layer alongside raw SQLite for database portability

[Pfannkuchensack]

Summary

Introduces SQLModel (SQLAlchemy + Pydantic) as an ORM layer to enable future database backend switching (PostgreSQL, MySQL). All services except session_queue have been migrated to SQLModel-based implementations while keeping the existing migration system and raw SQLite connection intact for backwards compatibility.

Key changes:

• Add sqlmodel dependency
• Define SQLModel table models for all 14 database tables
• Extend SqliteDatabase with SQLAlchemy Engine and Session management
• Create SQLModel implementations for 10 services (boards, images, workflows, models, users, style presets, app settings, etc.)
• Session queue remains on raw SQLite (Phase 3)
• Add 95 unit tests and 12 performance benchmarks
• Optimize with StaticPool, expire_on_commit=False, and read-only sessions

Related Issues / Discussions

This PR is the first phase of a larger migration proposal to make InvokeAI's database layer portable across different backends (SQLite, PostgreSQL, MySQL).

QA Instructions

Run the new unit tests

uv run --extra cuda --extra test python -m pytest tests/app/services/test_sqlmodel_services/ -v --timeout=30

Expected: 94 passed, 1 skipped

Run the performance benchmarks

uv run --extra cuda --extra test python -m pytest tests/app/services/test_sqlmodel_services/test_benchmark_sqlmodel_vs_sqlite.py -v -s --timeout=120

Expected: 12 passed with timing comparison output

Manual testing

1. Start InvokeAI normally — all existing functionality should work as before
2. Create/edit/delete boards and verify they persist
3. Generate images and verify they appear in the gallery
4. Create/manage style presets
5. Verify user authentication works (if multiuser is enabled)

What changed at runtime

• dependencies.py now instantiates SQLModel-based services instead of raw SQLite ones
• The SqliteDatabase class now also provides a SQLAlchemy Engine + Session alongside the existing raw sqlite3 connection
• The raw connection is still used for migrations and the session queue
• All other services use SQLModel for queries

Merge Plan

• This PR does not change the database schema — migrations remain untouched
• The old raw SQLite implementations are kept as-is (not deleted) for reference and rollback
• Session queue migration is planned as Phase 3 in a future PR
• No special merge timing required

Checklist

• The PR has a short but descriptive title, suitable for a changelog
• Tests added / updated (if applicable)
• ❗Changes to a redux slice have a corresponding migration
• Documentation added / updated (if applicable)
• Updated What's New copy (if doing a release after this PR)

[JPPhoto]

Why is database portability a significant issue?

[Pfannkuchensack]

If you want to host the multi User Feature with many User there is a Problem with Performance on sqlite. (this is a PR to test it)

[JPPhoto]

If you want to host the multi User Feature with many User there is a Problem with Performance on sqlite. (this is a PR to test it)

It would be interesting to capture some real-world Invoke sqlite3 access patterns and benchmark those. Perhaps that would tell us if there's first an opportunity for optimization in the way we do things.