[GH-ISSUE #15046] feat: Indexing to improve performance #56115

New Issue

Closed

opened 2026-05-05 18:43:58 -05:00 by GiteaMirror · 13 comments

GiteaMirror commented 2026-05-05 18:43:58 -05:00

Owner

Copy Link

Originally created by @decent-engineer-decent-datascientist on GitHub (Jun 16, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/15046

Check Existing Issues

• I have searched the existing issues and discussions.

Problem Description

When using Open-WebUI with a SQLite or pSQL backend, database queries (such as filtering, sorting, and joining) can become noticeably slow as data grows, particularly for common tables (e.g., chat, tag, function).

Currently, not indexes are created by default. Indexes that would drastically improve performance must be created manually. Many users may not be aware of best practices for index creation or which queries would benefit most.

Desired Solution you'd like

Automatically create indexes for databases upon initial setup or first use of key tables. Example indices include:

Index Name	Fields Impacted	Matches Queries Like…	What It Improves	Tested Improvement %	Create Index Query
folder_id_idx	chat(folder_id)	WHERE folder_id = ...	Fast lookup of all chats in a folder	99%	CREATE INDEX folder_id_idx ON chat(folder_id);
user_id_idx	tag(user_id)	WHERE user_id = ...	Quickly find all tags for a user	35% / 33%	CREATE INDEX user_id_idx ON tag(user_id);
user_id_pinned_idx	chat(user_id, pinned)	WHERE user_id = ... AND pinned = ...	Efficient user & pinned chat filtering	99%	CREATE INDEX user_id_pinned_idx ON chat(user_id, pinned);
updated_at_user_id_idx	chat(updated_at, user_id)	WHERE user_id = ... ORDER BY updated_at DESC	Fast per-user chat listing sorted by update time	83%	CREATE INDEX updated_at_user_id_idx ON chat(updated_at, user_id);
user_id_archived_idx	chat(user_id, archived)	WHERE user_id = ... AND archived = ...	Efficient per-user archived/unarchived lookups	91%	CREATE INDEX user_id_archived_idx ON chat(user_id, archived);
is_global_idx	function(is_global)	WHERE is_global = ...	Fast global/non-global function filtering	50%	CREATE INDEX is_global_idx ON function(is_global);
folder_id_user_id_idx	chat(folder_id, user_id)	WHERE folder_id = ... AND user_id = ...	Quicker lookup for chat folders by user	99%	CREATE INDEX folder_id_user_id_idx ON chat(folder_id, user_id);

Alternatives Considered

• Manual Index Creation: Users can create indexes themselves, but this requires SQL/database knowledge and the ability to identify slow queries, which can be a barrier for some users.
• Documentation: Providing clear documentation or setup guides listing suggested indexes for SQLite could help, but it’s less user-friendly than automating or recommending them directly within the app.

Additional Context

I recently analyzed query logs for a PostgreSQL deployment and found that similar indexes provide major performance boosts on SQLite as well. Given the overlap in SQL functionality, this feature would make Open-WebUI more performant "out-of-the-box" for SQLite users (who may be on resource-limited systems). Additionally, automated index management would help less-technical users avoid sluggishness as their dataset grows.

It would be as simple as doing this for new instances:

backend/open_webui/models/chats.py:

class Chat(Base):
    __tablename__ = "chat"

    id = Column(String, primary_key=True)
    user_id = Column(String)
    title = Column(Text)
    chat = Column(JSON)

    created_at = Column(BigInteger)
    updated_at = Column(BigInteger)

    share_id = Column(Text, unique=True, nullable=True)
    archived = Column(Boolean, default=False)
    pinned = Column(Boolean, default=False, nullable=True)

    meta = Column(JSON, server_default="{}")
    folder_id = Column(Text, nullable=True)

    __table_args__ = (
        Index('idx_chat_user_id_pinned', 'user_id', 'pinned'),
        Index('idx_chat_user_id_archived', 'user_id', 'archived'),
        Index('idx_chat_folder_id', 'folder_id'),
        Index('idx_chat_folder_id_user_id', 'folder_id', 'user_id'),
        Index('idx_chat_updated_at_user_id', 'updated_at', 'user_id'),
    )

Originally created by @decent-engineer-decent-datascientist on GitHub (Jun 16, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/15046 ### Check Existing Issues - [x] I have searched the existing issues and discussions. ### Problem Description When using Open-WebUI with a SQLite or pSQL backend, database queries (such as filtering, sorting, and joining) can become noticeably slow as data grows, particularly for common tables (e.g., chat, tag, function). Currently, not indexes are created by default. Indexes that would drastically improve performance must be created manually. Many users may not be aware of best practices for index creation or which queries would benefit most. ### Desired Solution you'd like Automatically create indexes for databases upon initial setup or first use of key tables. Example indices include: | **Index Name** | **Fields Impacted** | **Matches Queries Like…** | **What It Improves** | **Tested Improvement %** | **Create Index Query** | |----------------------------------|-------------------------|---------------------------------------------------------------|--------------------------------------------------|-------------------|-------------------------------------------| | folder_id_idx | chat(folder_id) | `WHERE folder_id = ...` | Fast lookup of all chats in a folder | 99% | `CREATE INDEX folder_id_idx ON chat(folder_id);` | | user_id_idx | tag(user_id) | `WHERE user_id = ...` | Quickly find all tags for a user | 35% / 33% | `CREATE INDEX user_id_idx ON tag(user_id);` | | user_id_pinned_idx | chat(user_id, pinned) | `WHERE user_id = ... AND pinned = ...` | Efficient user & pinned chat filtering | 99% | `CREATE INDEX user_id_pinned_idx ON chat(user_id, pinned);`| | updated_at_user_id_idx | chat(updated_at, user_id)| `WHERE user_id = ... ORDER BY updated_at DESC` | Fast per-user chat listing sorted by update time | 83% | `CREATE INDEX updated_at_user_id_idx ON chat(updated_at, user_id);`| | user_id_archived_idx | chat(user_id, archived) | `WHERE user_id = ... AND archived = ...` | Efficient per-user archived/unarchived lookups | 91% | `CREATE INDEX user_id_archived_idx ON chat(user_id, archived);` | | is_global_idx | function(is_global) | `WHERE is_global = ...` | Fast global/non-global function filtering | 50% | `CREATE INDEX is_global_idx ON function(is_global);` | | folder_id_user_id_idx | chat(folder_id, user_id)| `WHERE folder_id = ... AND user_id = ...` | Quicker lookup for chat folders by user | 99% | `CREATE INDEX folder_id_user_id_idx ON chat(folder_id, user_id);` | ### Alternatives Considered - Manual Index Creation: Users can create indexes themselves, but this requires SQL/database knowledge and the ability to identify slow queries, which can be a barrier for some users. - Documentation: Providing clear documentation or setup guides listing suggested indexes for SQLite could help, but it’s less user-friendly than automating or recommending them directly within the app. ### Additional Context I recently analyzed query logs for a PostgreSQL deployment and found that similar indexes provide major performance boosts on SQLite as well. Given the overlap in SQL functionality, this feature would make Open-WebUI more performant "out-of-the-box" for SQLite users (who may be on resource-limited systems). Additionally, automated index management would help less-technical users avoid sluggishness as their dataset grows. It would be as simple as doing this for new instances: backend/open_webui/models/chats.py: ```python class Chat(Base): __tablename__ = "chat" id = Column(String, primary_key=True) user_id = Column(String) title = Column(Text) chat = Column(JSON) created_at = Column(BigInteger) updated_at = Column(BigInteger) share_id = Column(Text, unique=True, nullable=True) archived = Column(Boolean, default=False) pinned = Column(Boolean, default=False, nullable=True) meta = Column(JSON, server_default="{}") folder_id = Column(Text, nullable=True) __table_args__ = ( Index('idx_chat_user_id_pinned', 'user_id', 'pinned'), Index('idx_chat_user_id_archived', 'user_id', 'archived'), Index('idx_chat_folder_id', 'folder_id'), Index('idx_chat_folder_id_user_id', 'folder_id', 'user_id'), Index('idx_chat_updated_at_user_id', 'updated_at', 'user_id'), ) ```

GiteaMirror closed this issue 2026-05-05 18:43:58 -05:00

GiteaMirror commented 2026-05-05 18:44:00 -05:00

Author

Owner

Copy Link

@decent-engineer-decent-datascientist commented on GitHub (Jun 16, 2025):

Happy to open a PR on this, with the indices I've tested. That being said, @tjbck, seeing as there are no indices in the models right now, I don't want to commit work that goes against any design decisions.

<!-- gh-comment-id:2978491770 --> @decent-engineer-decent-datascientist commented on GitHub (Jun 16, 2025): Happy to open a PR on this, with the indices I've tested. That being said, @tjbck, seeing as there are no indices in the models right now, I don't want to commit work that goes against any design decisions.

GiteaMirror commented 2026-05-05 18:44:01 -05:00

Author

Owner

Copy Link

@decent-engineer-decent-datascientist commented on GitHub (Jun 19, 2025):

If we're interested, I've added PR #15155

<!-- gh-comment-id:2989339795 --> @decent-engineer-decent-datascientist commented on GitHub (Jun 19, 2025): If we're interested, I've added PR #15155

GiteaMirror commented 2026-05-05 18:44:02 -05:00

Author

Owner

Copy Link

@richard-a-adams commented on GitHub (Jul 3, 2025):

Hi,

Thanks for suggesting these improvements. Am I able to create these indexes on an already existing postgreSQL db and get these performance improvements? Or does it require further code changes to the interface to get any benefits?

Not too familiar with DBs as a whole so thanks for any information you can provide.

<!-- gh-comment-id:3030142210 --> @richard-a-adams commented on GitHub (Jul 3, 2025): Hi, Thanks for suggesting these improvements. Am I able to create these indexes on an already existing postgreSQL db and get these performance improvements? Or does it require further code changes to the interface to get any benefits? Not too familiar with DBs as a whole so thanks for any information you can provide.

GiteaMirror commented 2026-05-05 18:44:04 -05:00

Author

Owner

Copy Link

@decent-engineer-decent-datascientist commented on GitHub (Jul 3, 2025):

If you apply the indices properly, no code changes need to happen. Make a
backup.

On Wed, Jul 2, 2025 at 8:46 PM Richard-Adams @.***>
wrote:

richard-a-adams left a comment (open-webui/open-webui#15046)
https://github.com/open-webui/open-webui/issues/15046#issuecomment-3030142210

Hi,

Thanks for suggesting these improvements. Am I able to create these
indexes on an already existing postgreSQL db and get these performance
improvements? Or does it require further code changes to the interface to
get any benefits?

Not too familiar with DBs as a whole so thanks for any information you can
provide.

—
Reply to this email directly, view it on GitHub
https://github.com/open-webui/open-webui/issues/15046#issuecomment-3030142210,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASRTZN3UBH357FD4LV64V3D3GSDQRAVCNFSM6AAAAAB7OURGXGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAMZQGE2DEMRRGA
.
You are receiving this because you authored the thread.Message ID:
@.***>

<!-- gh-comment-id:3030151195 --> @decent-engineer-decent-datascientist commented on GitHub (Jul 3, 2025): If you apply the indices properly, no code changes need to happen. Make a backup. On Wed, Jul 2, 2025 at 8:46 PM Richard-Adams ***@***.***> wrote: > *richard-a-adams* left a comment (open-webui/open-webui#15046) > <https://github.com/open-webui/open-webui/issues/15046#issuecomment-3030142210> > > Hi, > > Thanks for suggesting these improvements. Am I able to create these > indexes on an already existing postgreSQL db and get these performance > improvements? Or does it require further code changes to the interface to > get any benefits? > > Not too familiar with DBs as a whole so thanks for any information you can > provide. > > — > Reply to this email directly, view it on GitHub > <https://github.com/open-webui/open-webui/issues/15046#issuecomment-3030142210>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ASRTZN3UBH357FD4LV64V3D3GSDQRAVCNFSM6AAAAAB7OURGXGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAMZQGE2DEMRRGA> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

GiteaMirror commented 2026-05-05 18:44:06 -05:00

Author

Owner

Copy Link

@richard-a-adams commented on GitHub (Jul 3, 2025):

Great, thanks.

Would you be able to provide any advice or guidance on how to apple the indices properly?

Of course making a backup before doing these changes is the first step but anything after that?

<!-- gh-comment-id:3030166743 --> @richard-a-adams commented on GitHub (Jul 3, 2025): Great, thanks. Would you be able to provide any advice or guidance on how to apple the indices properly? Of course making a backup before doing these changes is the first step but anything after that?

GiteaMirror commented 2026-05-05 18:44:07 -05:00

Author

Owner

Copy Link

@spammenotinoz commented on GitHub (Jul 25, 2025):

Thank-you this helped dramatically, do you have any other index suggestions to help workspace functions such as models, knowledge and prompts?

<!-- gh-comment-id:3117494112 --> @spammenotinoz commented on GitHub (Jul 25, 2025): Thank-you this helped dramatically, do you have any other index suggestions to help workspace functions such as models, knowledge and prompts?

GiteaMirror commented 2026-05-05 18:44:08 -05:00

Author

Owner

Copy Link

@AsianDesignMajor commented on GitHub (Aug 9, 2025):

If you apply the indices properly, no code changes need to happen. Make a backup.
…

@decent-engineer-decent-datascientist Are the compound indexes the only way to do this? I'm no expert at indexes, but I would think applying single-field indexes would keep the sizes down - it appears you're indexing the same field in more than one place. Would the speed improvement really change all that much (I'm going to apply this to a PSQL back-end)?

So, would it be OK, for example, to do:

CREATE INDEX chat_folder_id_idx ON chat(folder_id);
CREATE INDEX chat_user_id_idx ON chat(user_id);
CREATE INDEX chat_pinned_idx ON chat(pinned);
CREATE INDEX chat_updated_at_idx ON chat(updated_at);
CREATE INDEX chat_archived_idx ON chat(archived);
 
CREATE INDEX tag_user_id_idx ON tag(user_id);
 
CREATE INDEX function_is_global_idx ON function(is_global);

I'm also curious if there's other tables / fields that are in the OWUI code as frequent join conditions, that could benefit from an index long-term (like, for example, indexing user_id across any tables with that field, as I would think joining user_id between certain tables in OWUI queries would be a "given" if a table has that field in it - like the "function" table, probably others.)

EDIT 2: I went through the tables and added indexes on user_id in any table that has that field, so would this be OK, you think, in addition to the ones above?

CREATE INDEX channel_user_id_idx ON public.channel(user_id);
CREATE INDEX channel_member_user_id_idx ON public.channel_member(user_id);
CREATE INDEX chatidtag_user_id_idx ON public.chatidtag(user_id);
CREATE INDEX document_user_id_idx ON public.document(user_id);
CREATE INDEX feedback_user_id_idx ON public.feedback(user_id);
CREATE INDEX file_user_id_idx ON public.file(user_id);
CREATE INDEX folder_user_id_idx ON public.folder(user_id);
CREATE INDEX function_user_id_idx ON public.function(user_id);
CREATE INDEX group_user_id_idx ON public.group(user_id);
CREATE INDEX knowledge_user_id_idx ON public.knowledge(user_id);
CREATE INDEX memory_user_id_idx ON public.memory(user_id);
CREATE INDEX message_user_id_idx ON public.message(user_id);
CREATE INDEX message_reaction_user_id_idx ON public.message_reaction(user_id);
CREATE INDEX model_user_id_idx ON public.model(user_id);
CREATE INDEX note_user_id_idx ON public.note(user_id);
CREATE INDEX prompt_user_id_idx ON public.prompt(user_id);
CREATE INDEX tool_user_id_idx ON public.tool(user_id);

<!-- gh-comment-id:3170635561 --> @AsianDesignMajor commented on GitHub (Aug 9, 2025): > If you apply the indices properly, no code changes need to happen. Make a backup. > […](#) @decent-engineer-decent-datascientist Are the compound indexes the only way to do this? I'm no expert at indexes, but I would think applying single-field indexes would keep the sizes down - it appears you're indexing the same field in more than one place. Would the speed improvement really change all that much (I'm going to apply this to a PSQL back-end)? So, would it be OK, for example, to do: ``` CREATE INDEX chat_folder_id_idx ON chat(folder_id); CREATE INDEX chat_user_id_idx ON chat(user_id); CREATE INDEX chat_pinned_idx ON chat(pinned); CREATE INDEX chat_updated_at_idx ON chat(updated_at); CREATE INDEX chat_archived_idx ON chat(archived);   CREATE INDEX tag_user_id_idx ON tag(user_id);   CREATE INDEX function_is_global_idx ON function(is_global); ``` I'm also curious if there's other tables / fields that are in the OWUI code as frequent join conditions, that could benefit from an index long-term (like, for example, indexing user_id across any tables with that field, as I would think joining user_id between certain tables in OWUI queries would be a "given" if a table has that field in it - like the "function" table, probably others.) EDIT 2: I went through the tables and added indexes on user_id in any table that has that field, so would this be OK, you think, in addition to the ones above? ``` CREATE INDEX channel_user_id_idx ON public.channel(user_id); CREATE INDEX channel_member_user_id_idx ON public.channel_member(user_id); CREATE INDEX chatidtag_user_id_idx ON public.chatidtag(user_id); CREATE INDEX document_user_id_idx ON public.document(user_id); CREATE INDEX feedback_user_id_idx ON public.feedback(user_id); CREATE INDEX file_user_id_idx ON public.file(user_id); CREATE INDEX folder_user_id_idx ON public.folder(user_id); CREATE INDEX function_user_id_idx ON public.function(user_id); CREATE INDEX group_user_id_idx ON public.group(user_id); CREATE INDEX knowledge_user_id_idx ON public.knowledge(user_id); CREATE INDEX memory_user_id_idx ON public.memory(user_id); CREATE INDEX message_user_id_idx ON public.message(user_id); CREATE INDEX message_reaction_user_id_idx ON public.message_reaction(user_id); CREATE INDEX model_user_id_idx ON public.model(user_id); CREATE INDEX note_user_id_idx ON public.note(user_id); CREATE INDEX prompt_user_id_idx ON public.prompt(user_id); CREATE INDEX tool_user_id_idx ON public.tool(user_id); ```

GiteaMirror commented 2026-05-05 18:44:10 -05:00

Author

Owner

Copy Link

@ivanbaldo commented on GitHub (Aug 11, 2025):

@AsianDesignMajor no, multiple column indexes are a good thing if done right, and in many cases is what you really want to do.

This is an excellent resource to understand these things https://use-the-index-luke.com/ if you are interested.

Thanks!!!

<!-- gh-comment-id:3175316605 --> @ivanbaldo commented on GitHub (Aug 11, 2025): @AsianDesignMajor no, multiple column indexes are a good thing if done right, and in many cases is what you really want to do. This is an excellent resource to understand these things https://use-the-index-luke.com/ if you are interested. Thanks!!!

GiteaMirror commented 2026-05-05 18:44:12 -05:00

Author

Owner

Copy Link

@hheydaroff commented on GitHub (Nov 19, 2025):

This is what is needed on OpenWebUI. The backend implementation requires a major upgrade. Is there any follow up plan on this? For the cases where multiple users are onboarded, it becomes a bottleneck for performance.

<!-- gh-comment-id:3551470350 --> @hheydaroff commented on GitHub (Nov 19, 2025): This is what is needed on OpenWebUI. The backend implementation requires a major upgrade. Is there any follow up plan on this? For the cases where multiple users are onboarded, it becomes a bottleneck for performance.

GiteaMirror commented 2026-05-05 18:44:13 -05:00

Author

Owner

Copy Link

@tjbck commented on GitHub (Nov 21, 2025):

This was added a long time ago.

<!-- gh-comment-id:3562208482 --> @tjbck commented on GitHub (Nov 21, 2025): This was added a long time ago.

GiteaMirror commented 2026-05-05 18:44:15 -05:00

Author

Owner

Copy Link

@hheydaroff commented on GitHub (Nov 21, 2025):

Excuse me, my bad. I had not properly checked the PR. It has not solved the issues though. Current implementation covers only high-impact compound indexes but leaves single-column indexes on frequently-queried fields unindexed:

• 16 additional tables with user_id columns used in frequent join operations
• Additional high-impact columns in function and model tables not yet indexed
• Potential performance gaps for users, especially on PostgreSQL deployments

i.e. from a reddit post:

CREATE INDEX IF NOT EXISTS channel_member_user_id_idx ON public.channel_member(user_id);
CREATE INDEX IF NOT EXISTS channel_user_id_idx ON public.channel(user_id);
CREATE INDEX IF NOT EXISTS chat_archived_idx ON public.chat(archived);
CREATE INDEX IF NOT EXISTS chat_folder_id_idx ON public.chat(folder_id);
CREATE INDEX IF NOT EXISTS chat_pinned_idx ON public.chat(pinned);
CREATE INDEX IF NOT EXISTS chat_updated_at_idx ON public.chat(updated_at);
CREATE INDEX IF NOT EXISTS chat_user_id_idx ON public.chat(user_id);
CREATE INDEX IF NOT EXISTS chatidtag_user_id_idx ON public.chatidtag(user_id);
CREATE INDEX IF NOT EXISTS document_user_id_idx ON public.document(user_id);
CREATE INDEX IF NOT EXISTS feedback_user_id_idx ON public.feedback(user_id);
CREATE INDEX IF NOT EXISTS file_user_id_idx ON public.file(user_id);
CREATE INDEX IF NOT EXISTS folder_user_id_idx ON public.folder(user_id);
CREATE INDEX IF NOT EXISTS function_is_active_idx ON public.function(is_active);
CREATE INDEX IF NOT EXISTS function_type_idx ON public.function(type);
CREATE INDEX IF NOT EXISTS function_user_id_idx ON public.function(user_id);
CREATE INDEX IF NOT EXISTS group_user_id_idx ON public.group(user_id);
CREATE INDEX IF NOT EXISTS knowledge_user_id_idx ON public.knowledge(user_id);
CREATE INDEX IF NOT EXISTS memory_user_id_idx ON public.memory(user_id);
CREATE INDEX IF NOT EXISTS message_reaction_user_id_idx ON public.message_reaction(user_id);
CREATE INDEX IF NOT EXISTS message_user_id_idx ON public.message(user_id);
CREATE INDEX IF NOT EXISTS model_base_model_id_idx ON public.model(base_model_id);
CREATE INDEX IF NOT EXISTS model_user_id_idx ON public.model(user_id);
CREATE INDEX IF NOT EXISTS note_user_id_idx ON public.note(user_id);
CREATE INDEX IF NOT EXISTS prompt_user_id_idx ON public.prompt(user_id);
CREATE INDEX IF NOT EXISTS tag_user_id_idx ON public.tag(user_id);
CREATE INDEX IF NOT EXISTS tool_user_id_idx ON public.tool(user_id);

In general, my feeling is that quite some INDEXes are missing.

<!-- gh-comment-id:3562971765 --> @hheydaroff commented on GitHub (Nov 21, 2025): Excuse me, my bad. I had not properly checked the PR. It has not solved the issues though. Current implementation covers only high-impact compound indexes but leaves single-column indexes on frequently-queried fields unindexed: - 16 additional tables with `user_id` columns used in frequent join operations - Additional high-impact columns in `function` and `model` tables not yet indexed - Potential performance gaps for users, especially on PostgreSQL deployments i.e. from a reddit post: ```sql CREATE INDEX IF NOT EXISTS channel_member_user_id_idx ON public.channel_member(user_id); CREATE INDEX IF NOT EXISTS channel_user_id_idx ON public.channel(user_id); CREATE INDEX IF NOT EXISTS chat_archived_idx ON public.chat(archived); CREATE INDEX IF NOT EXISTS chat_folder_id_idx ON public.chat(folder_id); CREATE INDEX IF NOT EXISTS chat_pinned_idx ON public.chat(pinned); CREATE INDEX IF NOT EXISTS chat_updated_at_idx ON public.chat(updated_at); CREATE INDEX IF NOT EXISTS chat_user_id_idx ON public.chat(user_id); CREATE INDEX IF NOT EXISTS chatidtag_user_id_idx ON public.chatidtag(user_id); CREATE INDEX IF NOT EXISTS document_user_id_idx ON public.document(user_id); CREATE INDEX IF NOT EXISTS feedback_user_id_idx ON public.feedback(user_id); CREATE INDEX IF NOT EXISTS file_user_id_idx ON public.file(user_id); CREATE INDEX IF NOT EXISTS folder_user_id_idx ON public.folder(user_id); CREATE INDEX IF NOT EXISTS function_is_active_idx ON public.function(is_active); CREATE INDEX IF NOT EXISTS function_type_idx ON public.function(type); CREATE INDEX IF NOT EXISTS function_user_id_idx ON public.function(user_id); CREATE INDEX IF NOT EXISTS group_user_id_idx ON public.group(user_id); CREATE INDEX IF NOT EXISTS knowledge_user_id_idx ON public.knowledge(user_id); CREATE INDEX IF NOT EXISTS memory_user_id_idx ON public.memory(user_id); CREATE INDEX IF NOT EXISTS message_reaction_user_id_idx ON public.message_reaction(user_id); CREATE INDEX IF NOT EXISTS message_user_id_idx ON public.message(user_id); CREATE INDEX IF NOT EXISTS model_base_model_id_idx ON public.model(base_model_id); CREATE INDEX IF NOT EXISTS model_user_id_idx ON public.model(user_id); CREATE INDEX IF NOT EXISTS note_user_id_idx ON public.note(user_id); CREATE INDEX IF NOT EXISTS prompt_user_id_idx ON public.prompt(user_id); CREATE INDEX IF NOT EXISTS tag_user_id_idx ON public.tag(user_id); CREATE INDEX IF NOT EXISTS tool_user_id_idx ON public.tool(user_id); ``` In general, my feeling is that quite some `INDEX`es are missing.

GiteaMirror commented 2026-05-05 18:44:17 -05:00

Author

Owner

Copy Link

@Classic298 commented on GitHub (Nov 21, 2025):

@hheydaroff

check the dev branch, tim just pushed through a group user table migration for frequently accessed user objects.

please do not use reddit as a source...

<!-- gh-comment-id:3562979764 --> @Classic298 commented on GitHub (Nov 21, 2025): @hheydaroff check the dev branch, tim just pushed through a group user table migration for frequently accessed user objects. please do not use reddit as a source...

GiteaMirror commented 2026-05-05 18:44:20 -05:00

Author

Owner

Copy Link

@hheydaroff commented on GitHub (Nov 21, 2025):

@Classic298, will check. thanks for the input!

<!-- gh-comment-id:3563102367 --> @hheydaroff commented on GitHub (Nov 21, 2025): @Classic298, will check. thanks for the input!

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

dev

v0.9.2

v0.9.1

v0.9.0

v0.8.12

v0.8.11

v0.8.10

v0.8.9

v0.8.8

v0.8.7

v0.8.6

v0.8.5

v0.8.4

v0.8.3

v0.8.2

v0.8.1

v0.8.0

v0.7.2

v0.7.1

v0.7.0

v0.6.43

v0.6.42

v0.6.41

v0.6.40

v0.6.39

v0.6.38

v0.6.37

v0.6.36

v0.6.35

v0.6.34

v0.6.33

v0.6.32

v0.6.31

v0.6.30

v0.6.29

v0.6.28

v0.6.27

v0.6.26

v0.6.25

v0.6.24

v0.6.23

v0.6.22

v0.6.21

v0.6.20

v0.6.19

v0.6.18

v0.6.17

v0.6.16

v0.6.15

v0.6.14

v0.6.13

v0.6.12

v0.6.11

v0.6.10

v0.6.9

v0.6.8

v0.6.7

v0.6.6

v0.6.5

v0.6.4

v0.6.3

v0.6.2

v0.6.1

v0.6.0

v0.5.20

v0.5.19

v0.5.18

v0.5.17

v0.5.16

v0.5.15

v0.5.14

v0.5.13

v0.5.12

v0.5.11

v0.5.10

v0.5.9

v0.5.8

v0.5.7

v0.5.6

v0.5.5

v0.5.4

v0.5.3

v0.5.2

v0.5.1

v0.5.0

v0.4.8

v0.4.7

v0.4.6

v0.4.5

v0.4.4

v0.4.3

v0.4.2

v0.4.1

v0.4.0

v0.3.35

v0.3.34

v0.3.33

v0.3.32

v0.3.31

v0.3.30

v0.3.29

v0.3.28

v0.3.27

v0.3.26

v0.3.25

v0.3.24

v0.3.23

v0.3.22

v0.3.21

v0.3.20

v0.3.19

v0.3.18

v0.3.17

v0.3.16

v0.3.15

v0.3.14

v0.3.13

v0.3.12

v0.3.11

v0.3.10

v0.3.9

v0.3.8

v0.3.7

v0.3.6

v0.3.5

v0.3.4

v0.3.3

v0.3.2

v0.3.1

v0.3.0

v0.2.5

v0.2.4

v0.2.3

v0.2.2

v0.2.1

v0.2.0

v0.1.125

v0.1.124

v0.1.123

v0.1.122

v0.1.121

v0.1.120

v0.1.119

v0.1.118

v0.1.117

v0.1.116

v0.1.115

v0.1.114

v0.1.113

v0.1.112

v0.1.111

v0.1.110

v0.1.109

v0.1.108

v0.1.107

v0.1.106

v0.1.105

v0.1.104

v0.1.103

v0.1.102

Labels

Clear labels

bug

confirmed

confirmed issue

core

documentation

enhancement

good first issue

help wanted

non-core

pull-request

Mirrored from GitHub Pull Request

python

question

testing wanted

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

GiteaMirror ninjasurge

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#56115