mirror of
https://github.com/open-webui/open-webui.git
synced 2026-05-07 03:18:23 -05:00
[GH-ISSUE #11467] feat: Chat Database Schema Update for Better Design, Performance, and Scalability #16241
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/open-webui#16241
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @harrywang on GitHub (Mar 9, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/11467
Check Existing Issues
Problem Description
The current chat is saved in the Chat table.
Each chat is one row, with chat field saving all chat messages in json - this can be slow and when the number of messages get large, the json is getting very big and slow.
This could be better designed.
Each chat is a conversation, each message can be in a separate table.
For example, see the schema from Vercel's at chatbot: https://github.com/vercel/ai-chatbot/blob/main/lib/db/schema.ts
How Chats are Stored
1. When a user creates a chat, a new row is inserted into the Chat table.
2. The id is automatically generated using defaultRandom(), ensuring each chat gets a unique identifier.
3. The createdAt field captures the time when the chat was created.
4. The userId field links the chat to the user who created it.
5. The visibility field determines if the chat is public or private.
How Messages are Associated with Chats
The Message table links messages to chats:
• The chatId column in the Message table references the id column in the Chat table.
• When a user sends a message in a chat, it is saved with:
• chatId (to associate it with a chat),
• role (e.g., ‘user’, ‘assistant’),
• content (stored as JSON),
• createdAt (timestamp of the message).
I think this is a much better design.
FYI, this is the current Chat table:
Desired Solution you'd like
a new database design for better scalability and performance.
Alternatives Considered
No response
Additional Context
No response