feat: external DB support #582

Closed
opened 2025-11-11 14:26:43 -06:00 by GiteaMirror · 8 comments
Owner

Originally created by @tjbck on GitHub (Apr 2, 2024).

Originally created by @tjbck on GitHub (Apr 2, 2024).
GiteaMirror added the enhancementgood first issuehelp wantedcore labels 2025-11-11 14:26:43 -06:00
Author
Owner

@Lanhild commented on GitHub (Apr 8, 2024):

PostgreSQL would be a good candidate IMO

@Lanhild commented on GitHub (Apr 8, 2024): PostgreSQL would be a good candidate IMO
Author
Owner

@ghost commented on GitHub (Apr 11, 2024):

PostgreSQL would be a good candidate IMO

I agree but I think the best consideration is to support ORM, something like SQLAlchemy ORM. As long as we adhere to Object Relational Mapper compatible statements, many major databases could be supported! SQLAlchemy presently supports a variety of dialects including PostgreSQL, MySQL and MariaDB, SQLite, Oracle, and Microsoft SQL Server.

@ghost commented on GitHub (Apr 11, 2024): > PostgreSQL would be a good candidate IMO I agree but I think the best consideration is to support ORM, something like [SQLAlchemy ORM](https://docs.sqlalchemy.org/en/20/orm/index.html#sqlalchemy-orm). As long as we adhere to **Object Relational Mapper** compatible statements, many major databases could be supported! SQLAlchemy presently supports a variety of [dialects](https://docs.sqlalchemy.org/en/20/dialects/index.html#dialects) including [PostgreSQL](https://docs.sqlalchemy.org/en/20/dialects/postgresql.html), [MySQL and MariaDB](https://docs.sqlalchemy.org/en/20/dialects/mysql.html), [SQLite](https://docs.sqlalchemy.org/en/20/dialects/sqlite.html), [Oracle](https://docs.sqlalchemy.org/en/20/dialects/oracle.html), and [Microsoft SQL Server](https://docs.sqlalchemy.org/en/20/dialects/mssql.html).
Author
Owner

@justinh-rahb commented on GitHub (Apr 11, 2024):

@lainedfles I am in full agreement that we need a more flexible solution to data storage, but I get real nervous about ORMs, heard too many horror stories of absolutely unhinged monstrosities of queries full of JOINS being emitted by them. They can make writing the code easier, but it's usually at the cost of efficiency.

@justinh-rahb commented on GitHub (Apr 11, 2024): @lainedfles I am in full agreement that we need a more flexible solution to data storage, but I get real nervous about ORMs, heard too many horror stories of absolutely unhinged monstrosities of queries full of JOINS being emitted by them. They can make writing the code easier, but it's usually at the cost of efficiency.
Author
Owner

@buroa commented on GitHub (Apr 11, 2024):

Postgres would be the best use case here.

@buroa commented on GitHub (Apr 11, 2024): Postgres would be the best use case here.
Author
Owner

@sourabratabose commented on GitHub (Apr 14, 2024):

Any update on this one? Where is the data being handled to be stored in database? at /rag/utils.py ?

@sourabratabose commented on GitHub (Apr 14, 2024): Any update on this one? Where is the data being handled to be stored in database? at /rag/utils.py ?
Author
Owner

@sfn-git commented on GitHub (Apr 14, 2024):

Any update on this one? Where is the data being handled to be stored in database? at /rag/utils.py ?

Not sure whether you are talking about storing the information relating to connecting to the database but I do not believe this path has any relation to that.

I am currently looking at creating relational diagram based off of the models located at backend\apps\web\models. I also believe SQLAlchemy ORM is the best option to implement this from a relational database perspective.

Would there also be considerations for something like Mongo in the future?

@sfn-git commented on GitHub (Apr 14, 2024): > Any update on this one? Where is the data being handled to be stored in database? at /rag/utils.py ? Not sure whether you are talking about storing the information relating to connecting to the database but I do not believe this path has any relation to that. I am currently looking at creating relational diagram based off of the models located at backend\apps\web\models. I also believe [SQLAlchemy ORM](https://docs.sqlalchemy.org/en/20/orm/index.html#sqlalchemy-orm) is the best option to implement this from a relational database perspective. Would there also be considerations for something like Mongo in the future?
Author
Owner

@Lanhild commented on GitHub (Apr 15, 2024):

Would there also be considerations for something like Mongo in the future?
@sfn-git

IMO, MongoDB isn't appropriate for the practical use case here as Open WebUI database is well defined and structured

@Lanhild commented on GitHub (Apr 15, 2024): > Would there also be considerations for something like Mongo in the future? @sfn-git IMO, MongoDB isn't appropriate for the practical use case here as Open WebUI database is well defined and structured
Author
Owner

@swatchion commented on GitHub (Nov 14, 2024):

The latest version works on postgresql 16, the only exception is that primary key is not set for some table, like auth table and others. Guess caused by ORM miss-configuration? Or it is intend to configure the table to has no primary key.

Test and deployed by github container images with external postgresql container instance.

@swatchion commented on GitHub (Nov 14, 2024): The latest version works on postgresql 16, the only exception is that primary key is not set for some table, like auth table and others. Guess caused by ORM miss-configuration? Or it is intend to configure the table to has no primary key. Test and deployed by github container images with external postgresql container instance.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#582