[GH-ISSUE #53] bug: PostgreSQL is not supported despite being documented as supported #26

New issue

Closed

opened 2026-10-18 21:13:32 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-18 21:13:32 +00:00

Owner

Originally created by @Silent69330 on GitHub (Aug 14, 2026).
Original GitHub issue: https://github.com/open-webui/terminals/issues/53

The documentation states that PostgreSQL is supported, but PostgreSQL compatibility is currently incomplete. The orchestrator does not include the required PostgreSQL driver and fails to start when the database password contains URL-escaped special characters such as %25, %7D, %3A, or %26. These characters are incorrectly rejected by Python’s configparser during Alembic configuration, before the database connection or migrations can run.

Originally created by @Silent69330 on GitHub (Aug 14, 2026). Original GitHub issue: https://github.com/open-webui/terminals/issues/53 The documentation states that PostgreSQL is supported, but PostgreSQL compatibility is currently incomplete. The orchestrator does not include the required PostgreSQL driver and fails to start when the database password contains URL-escaped special characters such as %25, %7D, %3A, or %26. These characters are incorrectly rejected by Python’s configparser during Alembic configuration, before the database connection or migrations can run.

bsakaguchi closed this issue

2026-10-18 21:13:32 +00:00

bsakaguchi commented

2026-10-18 21:13:33 +00:00

Author

Owner

@Silent69330 commented on GitHub (Aug 26, 2026):

Looks like version v0.2.2 fixed the PostgreSQL compatibility issue, thanks.

We are now seeing a timestamp error: aware UTC datetimes are being inserted into columns defined as TIMESTAMP WITHOUT TIME ZONE.
asyncpg fails before the query reaches PostgreSQL, so changing the database URL or RDS timezone will not resolve it.
The failing values come from datetime.now(timezone.utc) used for created_at and updated_at. (policies table)
A quick hotfix would be to omit these fields and let the existing server_default=func.now() populate them, or pass naive UTC values using .replace(tzinfo=None).
The long-term fix is to use DateTime(timezone=True) / TIMESTAMP WITH TIME ZONE for these columns. (migration alembic)

@Silent69330 commented on GitHub (Aug 26, 2026): Looks like version v0.2.2 fixed the PostgreSQL compatibility issue, thanks. We are now seeing a timestamp error: aware UTC datetimes are being inserted into columns defined as TIMESTAMP WITHOUT TIME ZONE. asyncpg fails before the query reaches PostgreSQL, so changing the database URL or RDS timezone will not resolve it. The failing values come from datetime.now(timezone.utc) used for created_at and updated_at. (policies table) A quick hotfix would be to omit these fields and let the existing server_default=func.now() populate them, or pass naive UTC values using .replace(tzinfo=None). The long-term fix is to use DateTime(timezone=True) / TIMESTAMP WITH TIME ZONE for these columns. (migration alembic)

bsakaguchi commented

2026-10-18 21:13:33 +00:00

Author

Owner

@Silent69330 commented on GitHub (Aug 31, 2026):

Fixed in v0.2.3, thanks

@Silent69330 commented on GitHub (Aug 31, 2026): Fixed in v0.2.3, thanks

bsakaguchi referenced this issue

2026-10-18 21:13:49 +00:00

[PR #26] [CLOSED] feat: make log level configurable #51