I have searched for any existing and/or related issues.
I have searched for any existing and/or related discussions.
I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!).
I am using the latest version of Open WebUI.
Installation Method
Docker
Open WebUI Version
0.9.1
Ollama Version (if applicable)
No response
Operating System
Debian 12
Browser (if applicable)
Firefox, Edge (both latest stable)
Confirmation
I have read and followed all instructions in README.md.
I am using the latest version of both Open WebUI and Ollama.
I have included the browser console logs.
I have included the Docker container logs.
I have provided every relevant configuration, setting, and environment variable used in my setup.
I have clearly listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
I have documented step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation. My steps:
Start with the initial platform/version/OS and dependencies used,
Specify exact install/launch/configure commands,
List URLs visited, user input (incl. example values/emails/passwords if needed),
Describe all options and toggles enabled or changed,
Include any files or environmental changes,
Identify the expected and actual result at each stage,
Ensure any reasonably skilled user can follow and hit the same issue.
Expected Behavior
Login should work same as in 0.8.12
Actual Behavior
After upgrading to 0.9.0 today i noticed that loading the webui was slower than usual. I noticed that the /api/config endpoint took about 16 seconds to load and then open-webui redirects me to my oidc login (entra id), but that login never really succeeds as it did before, it just keeps loading indefinitely:
Going back to 0.8.12 instantly solves those problems and login works properly (dont even have to manually login, i am automatically logged in).
Steps to Reproduce
Installed open-webui using docker compose with traefik reverse proxy with entra id as oidc provider.
Logs & Screenshots
Not sure if relevant, but this is the only error i could find in the logs of the open-webui container on startup:
Originally created by @Joly0 on GitHub (Apr 21, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/23939
### Check Existing Issues
- [x] I have searched for any existing and/or related issues.
- [x] I have searched for any existing and/or related discussions.
- [x] I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!).
- [x] I am using the latest version of Open WebUI.
### Installation Method
Docker
### Open WebUI Version
0.9.1
### Ollama Version (if applicable)
_No response_
### Operating System
Debian 12
### Browser (if applicable)
Firefox, Edge (both latest stable)
### Confirmation
- [x] I have read and followed all instructions in `README.md`.
- [x] I am using the latest version of **both** Open WebUI and Ollama.
- [x] I have included the browser console logs.
- [x] I have included the Docker container logs.
- [x] I have **provided every relevant configuration, setting, and environment variable used in my setup.**
- [x] I have clearly **listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup** (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
- [x] I have documented **step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation**. My steps:
- Start with the initial platform/version/OS and dependencies used,
- Specify exact install/launch/configure commands,
- List URLs visited, user input (incl. example values/emails/passwords if needed),
- Describe all options and toggles enabled or changed,
- Include any files or environmental changes,
- Identify the expected and actual result at each stage,
- Ensure any reasonably skilled user can follow and hit the same issue.
### Expected Behavior
Login should work same as in 0.8.12
### Actual Behavior
After upgrading to 0.9.0 today i noticed that loading the webui was slower than usual. I noticed that the /api/config endpoint took about 16 seconds to load and then open-webui redirects me to my oidc login (entra id), but that login never really succeeds as it did before, it just keeps loading indefinitely:
<img width="1671" height="169" alt="Image" src="https://github.com/user-attachments/assets/df33d8e9-e24f-4fb8-8902-be0de0da2d1c" />
<img width="1146" height="294" alt="Image" src="https://github.com/user-attachments/assets/7b30103a-fce0-443b-b366-c5cacc825439" />
Going back to 0.8.12 instantly solves those problems and login works properly (dont even have to manually login, i am automatically logged in).
### Steps to Reproduce
Installed open-webui using docker compose with traefik reverse proxy with entra id as oidc provider.
### Logs & Screenshots
Not sure if relevant, but this is the only error i could find in the logs of the open-webui container on startup:
```
await sio.enter_room(sid, f'user:{user.id}')
│ │ └ 'tCranlVMsgLK0-ofAAA1'
│ └ <function AsyncServer.enter_room at 0x7f36c059e200>
└ <socketio.async_server.AsyncServer object at 0x7f36c0ea4350>
File "/usr/local/lib/python3.11/site-packages/socketio/async_server.py", line 306, in enter_room
await self.manager.enter_room(sid, namespace, room)
│ │ │ │ │ └ 'user:adedef21-75fb-4b56-8958-872fe4cdbfb4'
│ │ │ │ └ '/'
│ │ │ └ 'tCranlVMsgLK0-ofAAA1'
│ │ └ <function AsyncManager.enter_room at 0x7f36c059dd00>
│ └ <socketio.async_manager.AsyncManager object at 0x7f36c0ea43d0>
└ <socketio.async_server.AsyncServer object at 0x7f36c0ea4350>
File "/usr/local/lib/python3.11/site-packages/socketio/async_manager.py", line 86, in enter_room
return self.basic_enter_room(sid, namespace, room, eio_sid=eio_sid)
│ │ │ │ │ └ None
│ │ │ │ └ 'user:adedef21-75fb-4b56-8958-872fe4cdbfb4'
│ │ │ └ '/'
│ │ └ 'tCranlVMsgLK0-ofAAA1'
│ └ <function BaseManager.basic_enter_room at 0x7f36c056e840>
└ <socketio.async_manager.AsyncManager object at 0x7f36c0ea43d0>
File "/usr/local/lib/python3.11/site-packages/socketio/base_manager.py", line 120, in basic_enter_room
eio_sid = self.rooms[namespace][None][sid]
│ │ │ └ 'tCranlVMsgLK0-ofAAA1'
│ │ └ '/'
│ └ {'/': {None: bidict({'v2oJhlOPs13CnuBcAAAJ': 'q2F_OWhOu_Y4pmoTAAAI', 'D07Tb5fQnEsIGAwuAAAX': 'r6q5TuGPxwwNozfUAAAW', 'QCuC1wS...
└ <socketio.async_manager.AsyncManager object at 0x7f36c0ea43d0>
File "/usr/local/lib/python3.11/site-packages/bidict/_base.py", line 524, in __getitem__
return self._fwdm[key]
│ │ └ 'tCranlVMsgLK0-ofAAA1'
│ └ {'v2oJhlOPs13CnuBcAAAJ': 'q2F_OWhOu_Y4pmoTAAAI', 'D07Tb5fQnEsIGAwuAAAX': 'r6q5TuGPxwwNozfUAAAW', 'QCuC1wSSHplENpTiAAAZ': '834...
└ bidict({'v2oJhlOPs13CnuBcAAAJ': 'q2F_OWhOu_Y4pmoTAAAI', 'D07Tb5fQnEsIGAwuAAAX': 'r6q5TuGPxwwNozfUAAAW', 'QCuC1wSSHplENpTiAAAZ...
KeyError: 'tCranlVMsgLK0-ofAAA1'
2026-04-21 13:27:54.868 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 10.244.1.142:0 - "GET /api/v1/users/c4910080-ef8b-49ec-aed9-276b44d816ba/profile/image HTTP/1.1" 200
```
### Additional Information
_No response_
GiteaMirror
added the bug label 2026-05-21 02:42:18 -05:00
<!-- gh-comment-id:4288970571 -->
@Classic298 commented on GitHub (Apr 21, 2026):
Are you on postgreSQL or sqlite?
What's your db pool size?
Do you use db session sharing?
The 16s slowness is most likely poor configuration or network issues or database latency. The backend does not take 16s to run the queries for the config endpoint
Probably your db sessions are saturated and therefore the backend is artificially blocked.
<!-- gh-comment-id:4288982228 -->
@Classic298 commented on GitHub (Apr 21, 2026):
The 16s slowness is most likely poor configuration or network issues or database latency. The backend does not take 16s to run the queries for the config endpoint
Probably your db sessions are saturated and therefore the backend is artificially blocked.
is it used by multiple users? is the slowness perchance only when someone uploads a file? whats your document extraction engine, embedding model and vector database?
<!-- gh-comment-id:4289024758 -->
@Classic298 commented on GitHub (Apr 21, 2026):
is it used by multiple users? is the slowness perchance only when someone uploads a file? whats your document extraction engine, embedding model and vector database?
is it used by multiple users? is the slowness perchance only when someone uploads a file? whats your document extraction engine, embedding model and vector database?
Yes, its used by a bunch of users. What do you mean the slowness perchance only when someone uploads a file? As described, this happens DIRECTLY after starting the container, so there is no chance that there could be any user already uploading files anywhere. And so far there were no problems, it just started today after updating to 0.9.0 and also after updating to 0.9.1. Also going back to 0.8.12 seems to instantly solve the problems i am experiencing
<!-- gh-comment-id:4289037497 -->
@Joly0 commented on GitHub (Apr 21, 2026):
> is it used by multiple users? is the slowness perchance only when someone uploads a file? whats your document extraction engine, embedding model and vector database?
Yes, its used by a bunch of users. What do you mean the slowness perchance only when someone uploads a file? As described, this happens DIRECTLY after starting the container, so there is no chance that there could be any user already uploading files anywhere. And so far there were no problems, it just started today after updating to 0.9.0 and also after updating to 0.9.1. Also going back to 0.8.12 seems to instantly solve the problems i am experiencing
Also even in prime-time when a lot of users were using open-webui there were never any problems with slowness or similar, but i am currently UNABLE to even login, it just stopped letting me login, which never happened before
<!-- gh-comment-id:4289046923 -->
@Joly0 commented on GitHub (Apr 21, 2026):
Also even in prime-time when a lot of users were using open-webui there were never any problems with slowness or similar, but i am currently UNABLE to even login, it just stopped letting me login, which never happened before
Thanks for the config, that narrows it down a bit. You're on plain SQLite with defaults (WAL on, busy_timeout 5s, async pool 512), single container.
For that setup, 16s on /api/config is not DB latency
A few things to help narrow this down:
Is the 16s only on the first request after container start, or on every subsequent request too? The lifespan does sync work on startup (embedding model load, install_tool_and_function_dependencies(), tool-server init, optional models cache pre-fetch). Cold-start stalls of 1min are plausible. If later /api/config calls are fast, it's just the frontend hitting the endpoint earlier in the flow than before, not a per-request regression.
Where does the OIDC login get stuck — on login.microsoftonline.com or back on your OWUI domain? If it hangs on Entra's side, it's likely a redirect_uri / cookie / state issue. If it hangs on the OWUI callback URL, the backend is stalling in the callback handler.
Please re-run with GLOBAL_LOG_LEVEL=DEBUG and share the log from clicking "Sign in" until it hangs. That will show whether authorize_access_token / userinfo are actually returning.
Try these two env vars as a quick test:
ENABLE_BASE_MODELS_CACHE=false (skips the startup model pre-fetch)
DATABASE_SQLITE_PRAGMA_BUSY_TIMEOUT=30000
Then report whether /api/config and the login flow behave any differently.
The KeyError: '...' on enter_room is a socketio race. The client disconnected before enter_room finished. It's a symptom of the reconnect/login loop, not the cause.
<!-- gh-comment-id:4289061323 -->
@Classic298 commented on GitHub (Apr 21, 2026):
Thanks for the config, that narrows it down a bit. You're on plain SQLite with defaults (WAL on, busy_timeout 5s, async pool 512), single container.
For that setup, 16s on `/api/config` is not DB latency
A few things to help narrow this down:
1. **Is the 16s only on the first request after container start, or on every subsequent request too?** The lifespan does sync work on startup (embedding model load, `install_tool_and_function_dependencies()`, tool-server init, optional models cache pre-fetch). Cold-start stalls of 1min are plausible. If later `/api/config` calls are fast, it's just the frontend hitting the endpoint earlier in the flow than before, not a per-request regression.
2. **Where does the OIDC login get stuck — on `login.microsoftonline.com` or back on your OWUI domain?** If it hangs on Entra's side, it's likely a redirect_uri / cookie / state issue. If it hangs on the OWUI callback URL, the backend is stalling in the callback handler.
3. Please re-run with `GLOBAL_LOG_LEVEL=DEBUG` and share the log from clicking "Sign in" until it hangs. That will show whether `authorize_access_token` / `userinfo` are actually returning.
4. Try these two env vars as a quick test:
- `ENABLE_BASE_MODELS_CACHE=false` (skips the startup model pre-fetch)
- `DATABASE_SQLITE_PRAGMA_BUSY_TIMEOUT=30000`
Then report whether `/api/config` and the login flow behave any differently.
5. The `KeyError: '...'` on `enter_room` is a socketio race. The client disconnected before `enter_room` finished. It's a symptom of the reconnect/login loop, not the cause.
Its always. I can switch browser and its still happening. I was also able now to login with firefox finally after a few minutes on waiting and it now took 2 minutes to load my chats (the endpoint /api/v1/chats/?page=1):
Its stuck when still on the login.microsoftonline.com page after login when it is trying to redirect me back to my owui instance. I can see that the callback?code=XYZ endpoint is stuck on pending for a while, before finally sending me back to owui where i am then stuck again for quite a while
I hope i got the logs you asked for, its quite a lot of output:
/api/v1/chats/?page=1 taking 2 minutes is pathological, that's a query blocked on I/O or locks. Same with the 13-second gap in your log between GET / (14:00:12) and the first outbound call to Azure (14:00:25). The OIDC "hang" is just the same slowness hitting the callback path.
The snippet shows PRAGMA journal_mode=WAL executing without a matching completed line.
A few more things to narrow it down:
Where does the /data/open-webui volume live? Local SSD, spinning disk, NFS, CIFS, k8s PVC backed by network storage, remote? SQLite + WAL on network-attached storage is catastrophically slow because WAL relies on mmap / fsync semantics that don't work well over NFS. So I really need to know what and where your data folder is and on what storage your sqlite lives. 0.8.12 was synchronous SQLAlchemy so contention was serialized in-process; 0.9.x is async with aiosqlite, which opens connections across threads and hammers the filesystem harder. Slow filesystem/slow storage will kill you. If the volume is network-backed, this is the most likely root cause.
Try as a diagnostic:
DATABASE_POOL_SIZE=1
This forces a single async connection (serialized) and tells us whether the problem is pool/threading contention or something more fundamental. If performance improves noticeably, it's definitely an async-pool-on-SQLite issue.
Test /api/config directly, bypassing Traefik. Run this from inside the container or from any container on the same Docker network:
If it's fast there but slow through Traefik, the culprit is proxy-side. If it's also slow there, it's 100% app + DB.
Please share the full unfiltered DEBUG log of a single login attempt (from clicking "Sign in" to the hang). The snippet has a 13s gap with no log output, but at DEBUG you should see aiosqlite and httpcore lines continuously. Whatever's happening in that gap is the bug.
Size of webui.db also helpful — ls -lh /data/open-webui/webui.db*.
<!-- gh-comment-id:4289198585 -->
@Classic298 commented on GitHub (Apr 21, 2026):
Thanks for the logs. Two important data points:
/api/v1/chats/?page=1 taking 2 minutes is pathological, that's a query blocked on I/O or locks. Same with the 13-second gap in your log between GET / (14:00:12) and the first outbound call to Azure (14:00:25). The OIDC "hang" is just the same slowness hitting the callback path.
The snippet shows PRAGMA journal_mode=WAL executing **without a matching completed line.**
A few more things to narrow it down:
Where does the /data/open-webui volume live? Local SSD, spinning disk, NFS, CIFS, k8s PVC backed by network storage, remote? SQLite + WAL on network-attached storage **is catastrophically slow** because WAL relies on mmap / fsync semantics that **don't work well over NFS**. So I really need to know what and where your data folder is and on what storage your sqlite lives. **0.8.12 was synchronous SQLAlchemy so contention was serialized in-process; 0.9.x is async with aiosqlite, which opens connections across threads and hammers the filesystem harder**. Slow filesystem/slow storage will kill you. If the volume is network-backed, this is the most likely root cause.
Try as a diagnostic:
- DATABASE_POOL_SIZE=1
This forces a single async connection (serialized) and tells us whether the problem is pool/threading contention or something more fundamental. If performance improves noticeably, it's definitely an async-pool-on-SQLite issue.
Test /api/config directly, bypassing Traefik. Run this from inside the container or from any container on the same Docker network:
docker exec open-webui curl -s -o /dev/null -w "%{time_total}\n" http://localhost:8080/api/config
If it's fast there but slow through Traefik, the culprit is proxy-side. If it's also slow there, it's 100% app + DB.
Please **share the full unfiltered DEBUG log of a single login attempt (from clicking "Sign in" to the hang)**. The snippet has a 13s gap with no log output, but at DEBUG you should see aiosqlite and httpcore lines continuously. Whatever's happening in that gap is the bug.
Size of webui.db also helpful — ls -lh /data/open-webui/webui.db*.
Most likely, your setup's problem is either the storage being slow (low I/O and/or huge latency handling async poorly) or pathological aiosqlite behavior on a large DB. The three diagnostics we need (storage type + db size, DATABASE_POOL_SIZE=1, direct curl past Traefik) will tell us which.
<!-- gh-comment-id:4289233890 -->
@Classic298 commented on GitHub (Apr 21, 2026):
Most likely, your setup's problem is either the storage being slow (low I/O and/or huge latency handling async poorly) or pathological aiosqlite behavior on a large DB. The three diagnostics we need (storage type + db size, DATABASE_POOL_SIZE=1, direct curl past Traefik) will tell us which.
Ok, so the volume is on an nfs storage thats mounted on the host. The storage itself is ssd based.
Setting the variable DATABASE_POOL_SIZE=1 seems to solve the problem. The curl command also shows no problem:
Though removing those variables currently seems to still leave the owui instance in a working state
<!-- gh-comment-id:4289292741 -->
@Joly0 commented on GitHub (Apr 21, 2026):
Ok, so the volume is on an nfs storage thats mounted on the host. The storage itself is ssd based.
Setting the variable `DATABASE_POOL_SIZE=1` seems to solve the problem. The curl command also shows no problem:
<img width="965" height="74" alt="Image" src="https://github.com/user-attachments/assets/292e146c-f5d0-4e62-bd8a-f3f33facad33" />
Though removing those variables `currently` seems to still leave the owui instance in a working state
ok so this is most definitely an I/O bound limitation of your NFS mounted storage. I will make sure to document that.
Recommendations, in order of robustness:
Best: move /data/open-webui off NFS onto local disk. SQLite on NFS is officially discouraged by SQLite upstream (SQLite FAQ #17) — especially with WAL, where concurrent writers across clients can corrupt the DB under some NFS implementations. You're a single-writer (one container) so corruption risk is low, but latency will remain bad.
If you must stay on NFS: migrate to PostgreSQL. Set DATABASE_URL=postgresql+asyncpg://.... That removes the fsync-per-connection pathology entirely because the DB process lives next to its own storage. (Recommended for multi user environments anyways)
If you want to keep SQLite on NFS as a workaround: keep DATABASE_POOL_SIZE=1 (or 2-5). You'll lose some concurrency but gain stability. Also keep DATABASE_SQLITE_PRAGMA_BUSY_TIMEOUT=30000 — NFS locks can take longer to acquire.
The fact that performance is still OK after removing the vars is likely just because the pool is warm now and isn't churning. It'll degrade again under load or after restart — please keep DATABASE_POOL_SIZE=1 (or migrate off NFS) for a durable fix.
Not a bug per se — it's working as designed, the design just doesn't assume NFS. Worth filing a docs/defaults note though - and i will add it to the docs.
<!-- gh-comment-id:4289313697 -->
@Classic298 commented on GitHub (Apr 21, 2026):
ok so this is most definitely an I/O bound limitation of your NFS mounted storage. **I will make sure to document that.**
Recommendations, in order of robustness:
- Best: move /data/open-webui off NFS onto local disk. SQLite on NFS is officially discouraged by SQLite upstream ([SQLite FAQ #17](https://www.sqlite.org/faq.html#q5)) — especially with WAL, where concurrent writers across clients can corrupt the DB under some NFS implementations. You're a single-writer (one container) so corruption risk is low, but latency will remain bad.
- If you must stay on NFS: migrate to PostgreSQL. Set DATABASE_URL=postgresql+asyncpg://.... That removes the fsync-per-connection pathology entirely because the DB process lives next to its own storage. (Recommended for multi user environments anyways)
- If you want to keep SQLite on NFS as a workaround: keep DATABASE_POOL_SIZE=1 (or 2-5). You'll lose some concurrency but gain stability. Also keep DATABASE_SQLITE_PRAGMA_BUSY_TIMEOUT=30000 — NFS locks can take longer to acquire.
The fact that performance is still OK after removing the vars is likely just because the pool is warm now and isn't churning. It'll degrade again under load or after restart — please keep DATABASE_POOL_SIZE=1 (or migrate off NFS) for a durable fix.
Not a bug per se — it's working as designed, the design just doesn't assume NFS. Worth filing a docs/defaults note though - and i will add it to the docs.
ok so this is most definitely an I/O bound limitation of your NFS mounted storage. I will make sure to document that.
Recommendations, in order of robustness:
* Best: move /data/open-webui off NFS onto local disk. SQLite on NFS is officially discouraged by SQLite upstream ([SQLite FAQ #17](https://www.sqlite.org/faq.html#q5)) — especially with WAL, where concurrent writers across clients can corrupt the DB under some NFS implementations. You're a single-writer (one container) so corruption risk is low, but latency will remain bad.
* If you must stay on NFS: migrate to PostgreSQL. Set DATABASE_URL=postgresql+asyncpg://.... That removes the fsync-per-connection pathology entirely because the DB process lives next to its own storage. (Recommended for multi user environments anyways)
* If you want to keep SQLite on NFS as a workaround: keep DATABASE_POOL_SIZE=1 (or 2-5). You'll lose some concurrency but gain stability. Also keep DATABASE_SQLITE_PRAGMA_BUSY_TIMEOUT=30000 — NFS locks can take longer to acquire.
The fact that performance is still OK after removing the vars is likely just because the pool is warm now and isn't churning. It'll degrade again under load or after restart — please keep DATABASE_POOL_SIZE=1 (or migrate off NFS) for a durable fix.
Not a bug per se — it's working as designed, the design just doesn't assume NFS. Worth filing a docs/defaults note though - and i will add it to the docs.
Alright, noted. Thanks for assisting here. I will check for possibilities on my end to move away from NFS storage (not a big fan of that solution, but it worked good until now), otherwise i will try and migrate to postgresql. Are there any docs regarding migrating from sqlite to postgres?
<!-- gh-comment-id:4289356306 -->
@Joly0 commented on GitHub (Apr 21, 2026):
> ok so this is most definitely an I/O bound limitation of your NFS mounted storage. **I will make sure to document that.**
>
> Recommendations, in order of robustness:
>
> * Best: move /data/open-webui off NFS onto local disk. SQLite on NFS is officially discouraged by SQLite upstream ([SQLite FAQ #17](https://www.sqlite.org/faq.html#q5)) — especially with WAL, where concurrent writers across clients can corrupt the DB under some NFS implementations. You're a single-writer (one container) so corruption risk is low, but latency will remain bad.
>
> * If you must stay on NFS: migrate to PostgreSQL. Set DATABASE_URL=postgresql+asyncpg://.... That removes the fsync-per-connection pathology entirely because the DB process lives next to its own storage. (Recommended for multi user environments anyways)
>
> * If you want to keep SQLite on NFS as a workaround: keep DATABASE_POOL_SIZE=1 (or 2-5). You'll lose some concurrency but gain stability. Also keep DATABASE_SQLITE_PRAGMA_BUSY_TIMEOUT=30000 — NFS locks can take longer to acquire.
>
>
> The fact that performance is still OK after removing the vars is likely just because the pool is warm now and isn't churning. It'll degrade again under load or after restart — please keep DATABASE_POOL_SIZE=1 (or migrate off NFS) for a durable fix.
>
> Not a bug per se — it's working as designed, the design just doesn't assume NFS. Worth filing a docs/defaults note though - and i will add it to the docs.
Alright, noted. Thanks for assisting here. I will check for possibilities on my end to move away from NFS storage (not a big fan of that solution, but it worked good until now), otherwise i will try and migrate to postgresql. Are there any docs regarding migrating from sqlite to postgres?
I checked the issue and I think I can work on this. Please let me know if it is still available.
<!-- gh-comment-id:4289372150 -->
@13krsnaa commented on GitHub (Apr 21, 2026):
I checked the issue and I think I can work on this. Please let me know if it is still available.
@13krsnaa there is nothing to work on unless you want to submit a PR to the docs
<!-- gh-comment-id:4289386709 -->
@Classic298 commented on GitHub (Apr 21, 2026):
@13krsnaa there is nothing to work on unless you want to submit a PR to the docs
If tested i bit more. We deployed openwebui in kubernetes via ceph. Our staging deployment uses sqllite and we also find a database lock error.
I tried DATABASE_POOL_SIZE: 1 in the deployment but it dosent seem to change much.
User at this point was just me.
<!-- gh-comment-id:4295117970 -->
@VonNao commented on GitHub (Apr 22, 2026):
If tested i bit more. We deployed openwebui in kubernetes via ceph. Our staging deployment uses sqllite and we also find a database lock error.
I tried DATABASE_POOL_SIZE: 1 in the deployment but it dosent seem to change much.
User at this point was just me.
@Joly0 if you set it to 3, then there can only be 3 connections at a time
If you set it to 1 it will create a new connection object for every call
<!-- gh-comment-id:4295850554 -->
@Classic298 commented on GitHub (Apr 22, 2026):
@Joly0 if you set it to 3, then there can only be 3 connections at a time
If you set it to 1 it will create a new connection object for every call
@Joly0 if you set it to 3, then there can only be 3 connections at a time
If you set it to 1 it will create a new connection object for every call
I tried with 1 and its still throwing the same error just with 1 instead of 3 in the error message. So it seems like even with that variable no matter what i set it to, my open-webui instance becomes unusable after some time
<!-- gh-comment-id:4296079138 -->
@Joly0 commented on GitHub (Apr 22, 2026):
> [@Joly0](https://github.com/Joly0) if you set it to 3, then there can only be 3 connections at a time
>
> If you set it to 1 it will create a new connection object for every call
I tried with 1 and its still throwing the same error just with 1 instead of 3 in the error message. So it seems like even with that variable no matter what i set it to, my open-webui instance becomes unusable after some time
On the SQLite path only pool_size is set, so SQLAlchemy's default max_overflow=10 still applies — =1 means up to 11 concurrent connections, =3 means 13, =5 means 15. Tweaking the value just moves the breaking point, doesn't fix the cause.
@VonNao Ceph is the same story as NFS: slow fsync + high per-op latency. aiosqlite opens each connection on its own thread doing its own fsync, connections stay checked out for seconds on slow storage, the pool saturates, pool_timeout=30 trips. No pool size will fix this.
Real fixes:
Move the SQLite file off Ceph onto local/ephemeral disk, or
Migrate to PostgreSQL (DATABASE_URL=postgresql+asyncpg://...). Strongly recommended for k8s — Postgres handles its own storage, your volume latency stops being in the hot path.
Short-term damage control if you're stuck: ENABLE_AUTOMATIONS=false removes the scheduler's 10 s poll, DATABASE_POOL_TIMEOUT=120 delays the 500s. Won't save you under real load.
You can also increase the automator's poll timer but that won't fix anything
<!-- gh-comment-id:4296170991 -->
@Classic298 commented on GitHub (Apr 22, 2026):
On the SQLite path only `pool_size` is set, so SQLAlchemy's default `max_overflow=10` still applies — `=1` means up to 11 concurrent connections, `=3` means 13, `=5` means 15. Tweaking the value just moves the breaking point, doesn't fix the cause.
@VonNao Ceph is the same story as NFS: slow `fsync` + high per-op latency. aiosqlite opens each connection on its own thread doing its own `fsync`, connections stay checked out for seconds on slow storage, the pool saturates, `pool_timeout=30` trips. No pool size will fix this.
Real fixes:
1. Move the SQLite file off Ceph onto local/ephemeral disk, or
2. Migrate to PostgreSQL (`DATABASE_URL=postgresql+asyncpg://...`). Strongly recommended for k8s — Postgres handles its own storage, your volume latency stops being in the hot path.
Short-term damage control if you're stuck: `ENABLE_AUTOMATIONS=false` removes the scheduler's 10 s poll, `DATABASE_POOL_TIMEOUT=120` delays the 500s. Won't save you under real load.
You can also increase the automator's poll timer but that won't fix anything
Ok, so whats the best solution here? From reading your comments it seems like postgres isnt the best approach either (or i am reading it wrong). Also if it is the best, is there official documentation to migrate from sqlite to postgres properly?
Problem is, i use docker swarm, therefore i have to use some sort of shared storage for the database for sqlite (and even if i use postgres it would be in the same compose stack, so also running on swarm and would also need shared storage, which currently is nfs). So for shared storage nfs is not really a solution but ceph neither?
<!-- gh-comment-id:4296353446 -->
@Joly0 commented on GitHub (Apr 22, 2026):
Ok, so whats the best solution here? From reading your comments it seems like postgres isnt the best approach either (or i am reading it wrong). Also if it is the best, is there official documentation to migrate from sqlite to postgres properly?
Problem is, i use docker swarm, therefore i have to use some sort of shared storage for the database for sqlite (and even if i use postgres it would be in the same compose stack, so also running on swarm and would also need shared storage, which currently is nfs). So for shared storage nfs is not really a solution but ceph neither?
<!-- gh-comment-id:4296374298 -->
@Joly0 commented on GitHub (Apr 22, 2026):
For migration from sqlite to postgres i could only find this https://ciodave.medium.com/migrating-open-webui-sqlite-database-to-postgresql-8efe7b2e4156 or an old tool here on github, but that seems to be outdated
You misread me — Postgres IS the right answer. Let me be direct, citing the official docs:
For multi-replica or high-availability deployments (Kubernetes, Docker Swarm), you MUST use an external database (PostgreSQL) instead of SQLite. SQLite does not support concurrent writes from multiple instances and will result in database corruption or data inconsistency.
"Do not store the SQLite database on a network filesystem. SQLite's file locking does not work reliably over NFS."
"If you skip this step and run multiple instances with SQLite, you will see database is locked errors and data corruption."
"SQLite on network filesystems is fundamentally unsupported... NFS, SMB/CIFS, GlusterFS, CephFS, Kubernetes PersistentVolumeClaims on network storage... The only solution: migrate to PostgreSQL or use locally-attached SSDs."
So what you're running right now is officially unsupported. That's the whole reason you're seeing this.
Your entire setup the way you operate it is completely unsupported and WILL break as documented. @Joly0 @VonNao
For Docker Swarm, do this:
Run Postgres as a single-replica service in your stack with a placement constraint pinning it to one node, and use a local volume on that node (not NFS). Only Postgres touches its data dir — no need for shared storage. If that node dies, you restart the service on another node and restore from backup; that's the standard pattern.
For multi-replica Open WebUI, also set Redis (REDIS_URL, WEBSOCKET_MANAGER=redis), share WEBUI_SECRET_KEY, and set ENABLE_DB_MIGRATIONS=false on all replicas except one.
On migrating existing data: there is no built-in migration. Per the env docs: "Changing the URL does not migrate data between databases."
NFS/Ceph for your files/uploads is fine — per the scaling doc, "multiple processes and replicas only ever create new files or read existing ones — they never write to the same file simultaneously." Only the SQLite DB file is the problem.
<!-- gh-comment-id:4296434342 -->
@Classic298 commented on GitHub (Apr 22, 2026):
You misread me — Postgres **IS** the right answer. Let me be direct, citing the official docs:
> For multi-replica or high-availability deployments (Kubernetes, Docker Swarm), you MUST use an external database (PostgreSQL) instead of SQLite. SQLite does not support concurrent writes from multiple instances and will result in database corruption or data inconsistency.
From https://docs.openwebui.com/reference/env-configuration#database-pool
Relevant reading:
From [scaling](https://docs.openwebui.com/getting-started/advanced-topics/scaling):
> "Do not store the SQLite database on a network filesystem. SQLite's file locking does not work reliably over NFS."
> "If you skip this step and run multiple instances with SQLite, you will see `database is locked` errors and data corruption."
From [performance](https://docs.openwebui.com/troubleshooting/performance):
> "SQLite on network filesystems is fundamentally unsupported... NFS, SMB/CIFS, GlusterFS, CephFS, Kubernetes PersistentVolumeClaims on network storage... The only solution: migrate to PostgreSQL or use locally-attached SSDs."
So what you're running right now is officially unsupported. That's the whole reason you're seeing this.
Your entire setup the way you operate it is completely unsupported and WILL break as documented. @Joly0 @VonNao
**For Docker Swarm, do this:**
1. Run Postgres as a single-replica service in your stack with a `placement constraint` pinning it to one node, and use a **local** volume on that node (not NFS). Only Postgres touches its data dir — no need for shared storage. If that node dies, you restart the service on another node and restore from backup; that's the standard pattern.
2. Point Open WebUI at it:
```
DATABASE_URL=postgresql+asyncpg://user:pass@postgres:5432/openwebui
```
3. For multi-replica Open WebUI, also set Redis (`REDIS_URL`, `WEBSOCKET_MANAGER=redis`), share `WEBUI_SECRET_KEY`, and set `ENABLE_DB_MIGRATIONS=false` on all replicas except one.
**On migrating existing data:** there is no built-in migration. Per the env docs: "Changing the URL does not migrate data between databases."
@taylorwilsdon built a community migration tool but use at your own risk and due diligence https://github.com/taylorwilsdon/open-webui-postgres-migration
NFS/Ceph for your **files/uploads** is fine — per the scaling doc, "multiple processes and replicas only ever create new files or read existing ones — they never write to the same file simultaneously." Only the SQLite DB file is the problem.
@Joly0
just for ... understanding. i asked you earlier if you used any form of scaling, you said no - and you also said you don't use redis
but NOW you said you use docker swarm
how does that work out?
<!-- gh-comment-id:4296641073 -->
@Classic298 commented on GitHub (Apr 22, 2026):
@Joly0
just for ... understanding. i asked you earlier if you used any form of scaling, you said no - and you also said you don't use redis
but NOW you said you use docker swarm
how does that work out?
@Joly0 just for ... understanding. i asked you earlier if you used any form of scaling, you said no - and you also said you don't use redis
but NOW you said you use docker swarm
how does that work out?
I may have misread what you asked for when you asked for scaling, but for your question Do you use uvicorn workers? Redis? Some other scaling? i answered with Other than that, no other database or redis or so. I am not using any kind of "scaling", open-webui is running on docker swarm, but always as/on a single node/instance. Docker swarm is only for HA (so if a node dies), not really for scaling, but i see what you mean and it was definitely me misunderstanding what you actually asked for with that question. But its still correct that i am not using redis or any other db.
Though i thought it was clear that i am using some sort of docker orchestrator, i do not see any other reason to use shared storage through nfs if not for that.
<!-- gh-comment-id:4296720505 -->
@Joly0 commented on GitHub (Apr 22, 2026):
> [@Joly0](https://github.com/Joly0) just for ... understanding. i asked you earlier if you used any form of scaling, you said no - and you also said you don't use redis
>
> but NOW you said you use docker swarm
>
> how does that work out?
I may have misread what you asked for when you asked for scaling, but for your question `Do you use uvicorn workers? Redis? Some other scaling?` i answered with `Other than that, no other database or redis or so`. I am not using any kind of "scaling", open-webui is running on docker swarm, but always as/on a single node/instance. Docker swarm is only for HA (so if a node dies), not really for scaling, but i see what you mean and it was definitely me misunderstanding what you actually asked for with that question. But its still correct that i am not using redis or any other db.
Though i thought it was clear that i am using some sort of docker orchestrator, i do not see any other reason to use shared storage through nfs if not for that.
i do not see any other reason to use shared storage through nfs if not for that.
i stopped making assumptions of people's setups after someone said they run Open WebUI on a machine with 128 cores and 2TB RAM but only gave it 1 mCPU (1 milli CPU) and 128 MB RAM. xd
<!-- gh-comment-id:4296746898 -->
@Classic298 commented on GitHub (Apr 22, 2026):
@Joly0 ok thanks that makes sense
> i do not see any other reason to use shared storage through nfs if not for that.
i stopped making assumptions of people's setups after someone said they run Open WebUI on a machine with 128 cores and 2TB RAM but only gave it 1 mCPU (1 milli CPU) and 128 MB RAM. xd
i do not see any other reason to use shared storage through nfs if not for that.
i stopped making assumptions of people's setups after someone said they run Open WebUI on a machine with 128 cores and 2TB RAM but only gave it 1 mCPU (1 milli CPU) and 128 MB RAM. xd
Ye, thats totally reasonable. Definitely sorry for leaving out that information, or better for not clarifying it clearer when you asked for it. You are giving awesome support and i should have given you as much information as i could provide and should have precisely described my environment when you asked for that information.
<!-- gh-comment-id:4296765330 -->
@Joly0 commented on GitHub (Apr 22, 2026):
> [@Joly0](https://github.com/Joly0) ok thanks that makes sense
>
> > i do not see any other reason to use shared storage through nfs if not for that.
>
> i stopped making assumptions of people's setups after someone said they run Open WebUI on a machine with 128 cores and 2TB RAM but only gave it 1 mCPU (1 milli CPU) and 128 MB RAM. xd
Ye, thats totally reasonable. Definitely sorry for leaving out that information, or better for not clarifying it clearer when you asked for it. You are giving awesome support and i should have given you as much information as i could provide and should have precisely described my environment when you asked for that information.
Hey @Classic298 i just wanted to give you an update on this and some problems i have hit.
So i have tried using the tool you linked to migrate from sqlite to postgres. At first i had some problems because of a bug that appears to be originated by open-webui itself, its described here https://github.com/taylorwilsdon/open-webui-postgres-migration/issues/22
Other than that there were several other errors/warnings while migration, where i am not sure if this is a problem or not.
For example:
⠋ Migrating oauth_session... ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 0%Error processing row in oauth_session: insert or update on table "oauth_session" violates foreign key constraint "oauth_session_user_id_fkey"
DETAIL: Key (user_id)=(bcc6e729-4351-4bdf-b253-9a6ddc411f8d) is not present in table "user".
Error processing row in oauth_session: current transaction is aborted, commands ignored until end of transaction block
Error processing row in oauth_session: current transaction is aborted, commands ignored until end of transaction block
Error processing row in oauth_session: current transaction is aborted, commands ignored until end of transaction block
Error processing row in oauth_session: current transaction is aborted, commands ignored until end of transaction block
Error processing row in oauth_session: current transaction is aborted, commands ignored until end of transaction block
Error processing row in oauth_session: current transaction is aborted, commands ignored until end of transaction block
....
⠙ Migrating oauth_session... ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 0%Error processing row in oauth_session: current transaction is aborted, commands ignored until end of transaction block
Error processing row in oauth_session: current transaction is aborted, commands ignored until end of transaction block
Error processing row in oauth_session: current transaction is aborted, commands ignored until end of transaction block
Error processing row in oauth_session: current transaction is aborted, commands ignored until end of transaction block
Error processing row in oauth_session: current transaction is aborted, commands ignored until end of transaction block
Error processing row in oauth_session: current transaction is aborted, commands ignored until end of transaction block
Error processing row in oauth_session: current transaction is aborted, commands ignored until end of transaction block
Error processing row in oauth_session: current transaction is aborted, commands ignored until end of transaction block
.....
Failed rows for oauth_session:
Row 0: insert or update on table "oauth_session" violates foreign key constraint "oauth_session_user_id_fkey"
DETAIL: Key (user_id)=(bcc6e729-4351-4bdf-b253-9a6ddc411f8d) is not present in table "user".
Row 1: current transaction is aborted, commands ignored until end of transaction block
Row 2: current transaction is aborted, commands ignored until end of transaction block
Row 3: current transaction is aborted, commands ignored until end of transaction block
Row 4: current transaction is aborted, commands ignored until end of transaction block
Row 5: current transaction is aborted, commands ignored until end of transaction block
....
⠼ Migrating group_member... ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 0%Error processing row in group_member: insert or update on table "group_member" violates foreign key constraint "group_member_group_id_fkey"
DETAIL: Key (group_id)=(fbe97f44-4ecf-483a-8c91-3e1686a04559) is not present in table "group".
Error processing row in group_member: current transaction is aborted, commands ignored until end of transaction block
Error processing row in group_member: current transaction is aborted, commands ignored until end of transaction block
Error processing row in group_member: current transaction is aborted, commands ignored until end of transaction block
⠸ Migrating chat_file... ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 0%Error processing row in chat_file: insert or update on table "chat_file" violates foreign key constraint "chat_file_file_id_fkey"
DETAIL: Key (file_id)=(51f4b889-4495-444a-b6c7-114f509900db) is not present in table "file".
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
.....
⠼ Migrating chat_file... ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 0%Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
....
⠴ Migrating chat_file... ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 0%Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
......
⠧ Migrating chat_file... ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 0%Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
.....
Error processing row in chat_file: insert or update on table "chat_file" violates foreign key constraint "chat_file_file_id_fkey"
DETAIL: Key (file_id)=(3bcd621c-3550-43cf-b68e-fcb867d835b1) is not present in table "file".
So there were several errors, all looking very similar (or are the same). I nthe end however the migration ended with a success (not sure though if it really was one, i have to verify).
But now when i try to start open-webui with - DATABASE_URL=postgresql+asyncpg://${POSTGRES_OPEN_WEBUI_USER}:${POSTGRES_OPEN_WEBUI_PASSWORD_ENCODED}@postgres:5432/${POSTGRES_OPEN_WEBUI_DB}
i get this error on startup of open-webui:
INFO:open_webui.env:GLOBAL_LOG_LEVEL: INFO
ERROR:open_webui.internal.db:Failed to initialize the database connection: Unrecognized or unsupported scheme: "postgresql+asyncpg".
WARNING:open_webui.internal.db:Hint: If your database password contains special characters, you may need to URL-encode it.
Traceback (most recent call last):
File "<frozen runpy>", line 198, in _run_module_as_main
File "<frozen runpy>", line 88, in _run_code
File "/usr/local/lib/python3.11/site-packages/uvicorn/__main__.py", line 4, in <module>
uvicorn.main()
File "/usr/local/lib/python3.11/site-packages/click/core.py", line 1485, in __call__
return self.main(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/click/core.py", line 1406, in main
rv = self.invoke(ctx)
^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/click/core.py", line 1269, in invoke
return ctx.invoke(self.callback, **ctx.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/click/core.py", line 824, in invoke
return callback(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/uvicorn/main.py", line 433, in main
run(
File "/usr/local/lib/python3.11/site-packages/uvicorn/main.py", line 606, in run
server.run()
File "/usr/local/lib/python3.11/site-packages/uvicorn/server.py", line 75, in run
return asyncio_run(self.serve(sockets=sockets), loop_factory=self.config.get_loop_factory())
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/uvicorn/_compat.py", line 30, in asyncio_run
return runner.run(main)
^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/asyncio/runners.py", line 118, in run
return self._loop.run_until_complete(task)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "uvloop/loop.pyx", line 1518, in uvloop.loop.Loop.run_until_complete
File "/usr/local/lib/python3.11/site-packages/uvicorn/server.py", line 79, in serve
await self._serve(sockets)
File "/usr/local/lib/python3.11/site-packages/uvicorn/server.py", line 86, in _serve
config.load()
File "/usr/local/lib/python3.11/site-packages/uvicorn/config.py", line 441, in load
self.loaded_app = import_from_string(self.app)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/uvicorn/importer.py", line 19, in import_from_string
module = importlib.import_module(module_str)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "<frozen importlib._bootstrap>", line 1204, in _gcd_import
File "<frozen importlib._bootstrap>", line 1176, in _find_and_load
File "<frozen importlib._bootstrap>", line 1147, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 690, in _load_unlocked
File "<frozen importlib._bootstrap_external>", line 940, in exec_module
File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
File "/app/backend/open_webui/main.py", line 60, in <module>
from open_webui.utils.asgi_middleware import (
File "/app/backend/open_webui/utils/asgi_middleware.py", line 44, in <module>
from open_webui.internal.db import ScopedSession
File "/app/backend/open_webui/internal/db.py", line 179, in <module>
handle_peewee_migration(DATABASE_URL)
File "/app/backend/open_webui/internal/db.py", line 158, in handle_peewee_migration
db = register_connection(normalized_url.replace('postgresql://', 'postgres://'))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/app/backend/open_webui/internal/wrappers.py", line 64, in register_connection
db = connect(db_url, unquote_user=True, unquote_password=True)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/playhouse/db_url.py", line 105, in connect
raise RuntimeError('Unrecognized or unsupported scheme: "%s".' %
RuntimeError: Unrecognized or unsupported scheme: "postgresql+asyncpg".
I dont think this is a problem with the migration, but rather with open-webui.
The postgres instance is running with this compose:
Regarding open-webui compose i didnt change anything to my previous compose (except for removing the database_sqlite and database_pool_size variables) other than adding:
<!-- gh-comment-id:4303407291 -->
@Joly0 commented on GitHub (Apr 23, 2026):
Hey @Classic298 i just wanted to give you an update on this and some problems i have hit.
So i have tried using the tool you linked to migrate from sqlite to postgres. At first i had some problems because of a bug that appears to be originated by open-webui itself, its described here https://github.com/taylorwilsdon/open-webui-postgres-migration/issues/22
Other than that there were several other errors/warnings while migration, where i am not sure if this is a problem or not.
For example:
```
⠋ Migrating oauth_session... ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 0%Error processing row in oauth_session: insert or update on table "oauth_session" violates foreign key constraint "oauth_session_user_id_fkey"
DETAIL: Key (user_id)=(bcc6e729-4351-4bdf-b253-9a6ddc411f8d) is not present in table "user".
Error processing row in oauth_session: current transaction is aborted, commands ignored until end of transaction block
Error processing row in oauth_session: current transaction is aborted, commands ignored until end of transaction block
Error processing row in oauth_session: current transaction is aborted, commands ignored until end of transaction block
Error processing row in oauth_session: current transaction is aborted, commands ignored until end of transaction block
Error processing row in oauth_session: current transaction is aborted, commands ignored until end of transaction block
Error processing row in oauth_session: current transaction is aborted, commands ignored until end of transaction block
....
```
```
⠙ Migrating oauth_session... ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 0%Error processing row in oauth_session: current transaction is aborted, commands ignored until end of transaction block
Error processing row in oauth_session: current transaction is aborted, commands ignored until end of transaction block
Error processing row in oauth_session: current transaction is aborted, commands ignored until end of transaction block
Error processing row in oauth_session: current transaction is aborted, commands ignored until end of transaction block
Error processing row in oauth_session: current transaction is aborted, commands ignored until end of transaction block
Error processing row in oauth_session: current transaction is aborted, commands ignored until end of transaction block
Error processing row in oauth_session: current transaction is aborted, commands ignored until end of transaction block
Error processing row in oauth_session: current transaction is aborted, commands ignored until end of transaction block
.....
Failed rows for oauth_session:
Row 0: insert or update on table "oauth_session" violates foreign key constraint "oauth_session_user_id_fkey"
DETAIL: Key (user_id)=(bcc6e729-4351-4bdf-b253-9a6ddc411f8d) is not present in table "user".
Row 1: current transaction is aborted, commands ignored until end of transaction block
Row 2: current transaction is aborted, commands ignored until end of transaction block
Row 3: current transaction is aborted, commands ignored until end of transaction block
Row 4: current transaction is aborted, commands ignored until end of transaction block
Row 5: current transaction is aborted, commands ignored until end of transaction block
....
```
```
⠼ Migrating group_member... ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 0%Error processing row in group_member: insert or update on table "group_member" violates foreign key constraint "group_member_group_id_fkey"
DETAIL: Key (group_id)=(fbe97f44-4ecf-483a-8c91-3e1686a04559) is not present in table "group".
Error processing row in group_member: current transaction is aborted, commands ignored until end of transaction block
Error processing row in group_member: current transaction is aborted, commands ignored until end of transaction block
Error processing row in group_member: current transaction is aborted, commands ignored until end of transaction block
```
```
⠸ Migrating chat_file... ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 0%Error processing row in chat_file: insert or update on table "chat_file" violates foreign key constraint "chat_file_file_id_fkey"
DETAIL: Key (file_id)=(51f4b889-4495-444a-b6c7-114f509900db) is not present in table "file".
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
.....
```
```
⠼ Migrating chat_file... ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 0%Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
....
```
```
⠴ Migrating chat_file... ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 0%Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
......
```
```
⠧ Migrating chat_file... ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 0%Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
Error processing row in chat_file: current transaction is aborted, commands ignored until end of transaction block
.....
Error processing row in chat_file: insert or update on table "chat_file" violates foreign key constraint "chat_file_file_id_fkey"
DETAIL: Key (file_id)=(3bcd621c-3550-43cf-b68e-fcb867d835b1) is not present in table "file".
```
So there were several errors, all looking very similar (or are the same). I nthe end however the migration ended with a success (not sure though if it really was one, i have to verify).
But now when i try to start open-webui with `- DATABASE_URL=postgresql+asyncpg://${POSTGRES_OPEN_WEBUI_USER}:${POSTGRES_OPEN_WEBUI_PASSWORD_ENCODED}@postgres:5432/${POSTGRES_OPEN_WEBUI_DB}`
i get this error on startup of open-webui:
```
INFO:open_webui.env:GLOBAL_LOG_LEVEL: INFO
ERROR:open_webui.internal.db:Failed to initialize the database connection: Unrecognized or unsupported scheme: "postgresql+asyncpg".
WARNING:open_webui.internal.db:Hint: If your database password contains special characters, you may need to URL-encode it.
Traceback (most recent call last):
File "<frozen runpy>", line 198, in _run_module_as_main
File "<frozen runpy>", line 88, in _run_code
File "/usr/local/lib/python3.11/site-packages/uvicorn/__main__.py", line 4, in <module>
uvicorn.main()
File "/usr/local/lib/python3.11/site-packages/click/core.py", line 1485, in __call__
return self.main(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/click/core.py", line 1406, in main
rv = self.invoke(ctx)
^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/click/core.py", line 1269, in invoke
return ctx.invoke(self.callback, **ctx.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/click/core.py", line 824, in invoke
return callback(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/uvicorn/main.py", line 433, in main
run(
File "/usr/local/lib/python3.11/site-packages/uvicorn/main.py", line 606, in run
server.run()
File "/usr/local/lib/python3.11/site-packages/uvicorn/server.py", line 75, in run
return asyncio_run(self.serve(sockets=sockets), loop_factory=self.config.get_loop_factory())
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/uvicorn/_compat.py", line 30, in asyncio_run
return runner.run(main)
^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/asyncio/runners.py", line 118, in run
return self._loop.run_until_complete(task)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "uvloop/loop.pyx", line 1518, in uvloop.loop.Loop.run_until_complete
File "/usr/local/lib/python3.11/site-packages/uvicorn/server.py", line 79, in serve
await self._serve(sockets)
File "/usr/local/lib/python3.11/site-packages/uvicorn/server.py", line 86, in _serve
config.load()
File "/usr/local/lib/python3.11/site-packages/uvicorn/config.py", line 441, in load
self.loaded_app = import_from_string(self.app)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/uvicorn/importer.py", line 19, in import_from_string
module = importlib.import_module(module_str)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "<frozen importlib._bootstrap>", line 1204, in _gcd_import
File "<frozen importlib._bootstrap>", line 1176, in _find_and_load
File "<frozen importlib._bootstrap>", line 1147, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 690, in _load_unlocked
File "<frozen importlib._bootstrap_external>", line 940, in exec_module
File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
File "/app/backend/open_webui/main.py", line 60, in <module>
from open_webui.utils.asgi_middleware import (
File "/app/backend/open_webui/utils/asgi_middleware.py", line 44, in <module>
from open_webui.internal.db import ScopedSession
File "/app/backend/open_webui/internal/db.py", line 179, in <module>
handle_peewee_migration(DATABASE_URL)
File "/app/backend/open_webui/internal/db.py", line 158, in handle_peewee_migration
db = register_connection(normalized_url.replace('postgresql://', 'postgres://'))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/app/backend/open_webui/internal/wrappers.py", line 64, in register_connection
db = connect(db_url, unquote_user=True, unquote_password=True)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/playhouse/db_url.py", line 105, in connect
raise RuntimeError('Unrecognized or unsupported scheme: "%s".' %
RuntimeError: Unrecognized or unsupported scheme: "postgresql+asyncpg".
```
I dont think this is a problem with the migration, but rather with open-webui.
The postgres instance is running with this compose:
```
postgres_open-webui:
# image: postgres:18-alpine
image: pgvector/pgvector:pg18-trixie
hostname: postgres
restart: always
volumes:
- /data/open-webui/postgresql:/var/lib/postgresql
environment:
POSTGRES_DB: ${POSTGRES_OPEN_WEBUI_DB}
POSTGRES_USER: ${POSTGRES_OPEN_WEBUI_USER}
POSTGRES_PASSWORD: ${POSTGRES_OPEN_WEBUI_PASSWORD}
healthcheck:
test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_OPEN_WEBUI_USER} -d ${POSTGRES_OPEN_WEBUI_DB}"]
interval: 10s
timeout: 5s
retries: 5
start_period: 30s
deploy:
mode: replicated
replicas: 1
restart_policy:
condition: any
placement:
constraints:
- node.role == manager
networks:
- owui-net
```
Regarding open-webui compose i didnt change anything to my previous compose (except for removing the database_sqlite and database_pool_size variables) other than adding:
```
# Database Settings
- DATABASE_URL=postgresql+asyncpg://${POSTGRES_OPEN_WEBUI_USER}:${POSTGRES_OPEN_WEBUI_PASSWORD_ENCODED}@postgres:5432/${POSTGRES_OPEN_WEBUI_DB}
- VECTOR_DB=pgvector
```
for database URL try "postgresql" also if "postgresql+asyncpg" yields this
<!-- gh-comment-id:4303456341 -->
@Classic298 commented on GitHub (Apr 23, 2026):
for database URL try "postgresql" also if "postgresql+asyncpg" yields this
Ok, it appears to be working with - DATABASE_URL=postgresql://${POSTGRES_OPEN_WEBUI_USER}:${POSTGRES_OPEN_WEBUI_PASSWORD_ENCODED}@postgres:5432/${POSTGRES_OPEN_WEBUI_DB} but not with - DATABASE_URL=postgresql+asyncpg://${POSTGRES_OPEN_WEBUI_USER}:${POSTGRES_OPEN_WEBUI_PASSWORD_ENCODED}@postgres:5432/${POSTGRES_OPEN_WEBUI_DB}
<!-- gh-comment-id:4303479429 -->
@Joly0 commented on GitHub (Apr 23, 2026):
Ok, it appears to be working with `- DATABASE_URL=postgresql://${POSTGRES_OPEN_WEBUI_USER}:${POSTGRES_OPEN_WEBUI_PASSWORD_ENCODED}@postgres:5432/${POSTGRES_OPEN_WEBUI_DB}` but not with `- DATABASE_URL=postgresql+asyncpg://${POSTGRES_OPEN_WEBUI_USER}:${POSTGRES_OPEN_WEBUI_PASSWORD_ENCODED}@postgres:5432/${POSTGRES_OPEN_WEBUI_DB}`
From my user the migration seems to have worked, atleast i cannot seem to see any missing chats, but those errors i posted earlier during migration are still kinda concerning
<!-- gh-comment-id:4303489442 -->
@Joly0 commented on GitHub (Apr 23, 2026):
From my user the migration seems to have worked, atleast i cannot seem to see any missing chats, but those errors i posted earlier during migration are still kinda concerning
Report it to @taylorwilsdon in his repository otherwise he won't see it
<!-- gh-comment-id:4303535263 -->
@Classic298 commented on GitHub (Apr 23, 2026):
Report it to @taylorwilsdon in his repository otherwise he won't see it
Ok, will do, but shouldnt postgresql+asyncpg work accoridng to the open-webui docs?
<!-- gh-comment-id:4303551140 -->
@Joly0 commented on GitHub (Apr 23, 2026):
Ok, will do, but shouldnt `postgresql+asyncpg` work accoridng to the open-webui docs?
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @Joly0 on GitHub (Apr 21, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/23939
Check Existing Issues
Installation Method
Docker
Open WebUI Version
0.9.1
Ollama Version (if applicable)
No response
Operating System
Debian 12
Browser (if applicable)
Firefox, Edge (both latest stable)
Confirmation
README.md.Expected Behavior
Login should work same as in 0.8.12
Actual Behavior
After upgrading to 0.9.0 today i noticed that loading the webui was slower than usual. I noticed that the /api/config endpoint took about 16 seconds to load and then open-webui redirects me to my oidc login (entra id), but that login never really succeeds as it did before, it just keeps loading indefinitely:
Going back to 0.8.12 instantly solves those problems and login works properly (dont even have to manually login, i am automatically logged in).
Steps to Reproduce
Installed open-webui using docker compose with traefik reverse proxy with entra id as oidc provider.
Logs & Screenshots
Not sure if relevant, but this is the only error i could find in the logs of the open-webui container on startup:
Additional Information
No response
@Classic298 commented on GitHub (Apr 21, 2026):
Are you on postgreSQL or sqlite?
What's your db pool size?
Do you use db session sharing?
@Classic298 commented on GitHub (Apr 21, 2026):
needs your full DB configuration and full startup logs to pinpoint.
@Classic298 commented on GitHub (Apr 21, 2026):
The 16s slowness is most likely poor configuration or network issues or database latency. The backend does not take 16s to run the queries for the config endpoint
Probably your db sessions are saturated and therefore the backend is artificially blocked.
@Classic298 commented on GitHub (Apr 21, 2026):
Do you use uvicorn workers? Redis? Some other scaling?
@Joly0 commented on GitHub (Apr 21, 2026):
Sure, no problem. Here is the startup logs:
Database is sqlite using all default settings. Here is the compose with the open-webui config:
Other than that, no other database or redis or so
@Classic298 commented on GitHub (Apr 21, 2026):
is it used by multiple users? is the slowness perchance only when someone uploads a file? whats your document extraction engine, embedding model and vector database?
@Joly0 commented on GitHub (Apr 21, 2026):
Yes, its used by a bunch of users. What do you mean the slowness perchance only when someone uploads a file? As described, this happens DIRECTLY after starting the container, so there is no chance that there could be any user already uploading files anywhere. And so far there were no problems, it just started today after updating to 0.9.0 and also after updating to 0.9.1. Also going back to 0.8.12 seems to instantly solve the problems i am experiencing
@Joly0 commented on GitHub (Apr 21, 2026):
Also even in prime-time when a lot of users were using open-webui there were never any problems with slowness or similar, but i am currently UNABLE to even login, it just stopped letting me login, which never happened before
@Classic298 commented on GitHub (Apr 21, 2026):
Thanks for the config, that narrows it down a bit. You're on plain SQLite with defaults (WAL on, busy_timeout 5s, async pool 512), single container.
For that setup, 16s on
/api/configis not DB latencyA few things to help narrow this down:
Is the 16s only on the first request after container start, or on every subsequent request too? The lifespan does sync work on startup (embedding model load,
install_tool_and_function_dependencies(), tool-server init, optional models cache pre-fetch). Cold-start stalls of 1min are plausible. If later/api/configcalls are fast, it's just the frontend hitting the endpoint earlier in the flow than before, not a per-request regression.Where does the OIDC login get stuck — on
login.microsoftonline.comor back on your OWUI domain? If it hangs on Entra's side, it's likely a redirect_uri / cookie / state issue. If it hangs on the OWUI callback URL, the backend is stalling in the callback handler.Please re-run with
GLOBAL_LOG_LEVEL=DEBUGand share the log from clicking "Sign in" until it hangs. That will show whetherauthorize_access_token/userinfoare actually returning.Try these two env vars as a quick test:
ENABLE_BASE_MODELS_CACHE=false(skips the startup model pre-fetch)DATABASE_SQLITE_PRAGMA_BUSY_TIMEOUT=30000Then report whether
/api/configand the login flow behave any differently.The
KeyError: '...'onenter_roomis a socketio race. The client disconnected beforeenter_roomfinished. It's a symptom of the reconnect/login loop, not the cause.@Joly0 commented on GitHub (Apr 21, 2026):
/api/v1/chats/?page=1):login.microsoftonline.compage after login when it is trying to redirect me back to my owui instance. I can see that thecallback?code=XYZendpoint is stuck on pending for a while, before finally sending me back to owui where i am then stuck again for quite a while@Classic298 commented on GitHub (Apr 21, 2026):
Thanks for the logs. Two important data points:
/api/v1/chats/?page=1 taking 2 minutes is pathological, that's a query blocked on I/O or locks. Same with the 13-second gap in your log between GET / (14:00:12) and the first outbound call to Azure (14:00:25). The OIDC "hang" is just the same slowness hitting the callback path.
The snippet shows PRAGMA journal_mode=WAL executing without a matching completed line.
A few more things to narrow it down:
Where does the /data/open-webui volume live? Local SSD, spinning disk, NFS, CIFS, k8s PVC backed by network storage, remote? SQLite + WAL on network-attached storage is catastrophically slow because WAL relies on mmap / fsync semantics that don't work well over NFS. So I really need to know what and where your data folder is and on what storage your sqlite lives. 0.8.12 was synchronous SQLAlchemy so contention was serialized in-process; 0.9.x is async with aiosqlite, which opens connections across threads and hammers the filesystem harder. Slow filesystem/slow storage will kill you. If the volume is network-backed, this is the most likely root cause.
Try as a diagnostic:
This forces a single async connection (serialized) and tells us whether the problem is pool/threading contention or something more fundamental. If performance improves noticeably, it's definitely an async-pool-on-SQLite issue.
Test /api/config directly, bypassing Traefik. Run this from inside the container or from any container on the same Docker network:
docker exec open-webui curl -s -o /dev/null -w "%{time_total}\n" http://localhost:8080/api/config
If it's fast there but slow through Traefik, the culprit is proxy-side. If it's also slow there, it's 100% app + DB.
Please share the full unfiltered DEBUG log of a single login attempt (from clicking "Sign in" to the hang). The snippet has a 13s gap with no log output, but at DEBUG you should see aiosqlite and httpcore lines continuously. Whatever's happening in that gap is the bug.
Size of webui.db also helpful — ls -lh /data/open-webui/webui.db*.
@Classic298 commented on GitHub (Apr 21, 2026):
Most likely, your setup's problem is either the storage being slow (low I/O and/or huge latency handling async poorly) or pathological aiosqlite behavior on a large DB. The three diagnostics we need (storage type + db size, DATABASE_POOL_SIZE=1, direct curl past Traefik) will tell us which.
@Joly0 commented on GitHub (Apr 21, 2026):
Ok, so the volume is on an nfs storage thats mounted on the host. The storage itself is ssd based.
Setting the variable
DATABASE_POOL_SIZE=1seems to solve the problem. The curl command also shows no problem:Though removing those variables
currentlyseems to still leave the owui instance in a working state@Joly0 commented on GitHub (Apr 21, 2026):
Also the webui.db is currently 906MB
@Classic298 commented on GitHub (Apr 21, 2026):
ok so this is most definitely an I/O bound limitation of your NFS mounted storage. I will make sure to document that.
Recommendations, in order of robustness:
The fact that performance is still OK after removing the vars is likely just because the pool is warm now and isn't churning. It'll degrade again under load or after restart — please keep DATABASE_POOL_SIZE=1 (or migrate off NFS) for a durable fix.
Not a bug per se — it's working as designed, the design just doesn't assume NFS. Worth filing a docs/defaults note though - and i will add it to the docs.
@Classic298 commented on GitHub (Apr 21, 2026):
@tjbck can we transfer this to the docs repo please?
@Joly0 commented on GitHub (Apr 21, 2026):
Alright, noted. Thanks for assisting here. I will check for possibilities on my end to move away from NFS storage (not a big fan of that solution, but it worked good until now), otherwise i will try and migrate to postgresql. Are there any docs regarding migrating from sqlite to postgres?
@13krsnaa commented on GitHub (Apr 21, 2026):
I checked the issue and I think I can work on this. Please let me know if it is still available.
@Classic298 commented on GitHub (Apr 21, 2026):
@13krsnaa there is nothing to work on unless you want to submit a PR to the docs
@Joly0 commented on GitHub (Apr 22, 2026):
Hey, just wanted to ask what i can do here:
I have currently set:
but i cannot access open-webui currently because of that error. I thought the database_pool_size variable should help in this case?
@VonNao commented on GitHub (Apr 22, 2026):
If tested i bit more. We deployed openwebui in kubernetes via ceph. Our staging deployment uses sqllite and we also find a database lock error.
I tried DATABASE_POOL_SIZE: 1 in the deployment but it dosent seem to change much.
User at this point was just me.
@Classic298 commented on GitHub (Apr 22, 2026):
@Joly0 if you set it to 3, then there can only be 3 connections at a time
If you set it to 1 it will create a new connection object for every call
@Joly0 commented on GitHub (Apr 22, 2026):
I tried with 1 and its still throwing the same error just with 1 instead of 3 in the error message. So it seems like even with that variable no matter what i set it to, my open-webui instance becomes unusable after some time
@Joly0 commented on GitHub (Apr 22, 2026):
Same error with other values (eg. 5 or 10)
@Classic298 commented on GitHub (Apr 22, 2026):
On the SQLite path only
pool_sizeis set, so SQLAlchemy's defaultmax_overflow=10still applies —=1means up to 11 concurrent connections,=3means 13,=5means 15. Tweaking the value just moves the breaking point, doesn't fix the cause.@VonNao Ceph is the same story as NFS: slow
fsync+ high per-op latency. aiosqlite opens each connection on its own thread doing its ownfsync, connections stay checked out for seconds on slow storage, the pool saturates,pool_timeout=30trips. No pool size will fix this.Real fixes:
DATABASE_URL=postgresql+asyncpg://...). Strongly recommended for k8s — Postgres handles its own storage, your volume latency stops being in the hot path.Short-term damage control if you're stuck:
ENABLE_AUTOMATIONS=falseremoves the scheduler's 10 s poll,DATABASE_POOL_TIMEOUT=120delays the 500s. Won't save you under real load.You can also increase the automator's poll timer but that won't fix anything
@Joly0 commented on GitHub (Apr 22, 2026):
Ok, so whats the best solution here? From reading your comments it seems like postgres isnt the best approach either (or i am reading it wrong). Also if it is the best, is there official documentation to migrate from sqlite to postgres properly?
Problem is, i use docker swarm, therefore i have to use some sort of shared storage for the database for sqlite (and even if i use postgres it would be in the same compose stack, so also running on swarm and would also need shared storage, which currently is nfs). So for shared storage nfs is not really a solution but ceph neither?
@Joly0 commented on GitHub (Apr 22, 2026):
For migration from sqlite to postgres i could only find this https://ciodave.medium.com/migrating-open-webui-sqlite-database-to-postgresql-8efe7b2e4156 or an old tool here on github, but that seems to be outdated
@Classic298 commented on GitHub (Apr 22, 2026):
You misread me — Postgres IS the right answer. Let me be direct, citing the official docs:
From https://docs.openwebui.com/reference/env-configuration#database-pool
Relevant reading:
From scaling:
From performance:
So what you're running right now is officially unsupported. That's the whole reason you're seeing this.
Your entire setup the way you operate it is completely unsupported and WILL break as documented. @Joly0 @VonNao
For Docker Swarm, do this:
placement constraintpinning it to one node, and use a local volume on that node (not NFS). Only Postgres touches its data dir — no need for shared storage. If that node dies, you restart the service on another node and restore from backup; that's the standard pattern.REDIS_URL,WEBSOCKET_MANAGER=redis), shareWEBUI_SECRET_KEY, and setENABLE_DB_MIGRATIONS=falseon all replicas except one.On migrating existing data: there is no built-in migration. Per the env docs: "Changing the URL does not migrate data between databases."
@taylorwilsdon built a community migration tool but use at your own risk and due diligence https://github.com/taylorwilsdon/open-webui-postgres-migration
NFS/Ceph for your files/uploads is fine — per the scaling doc, "multiple processes and replicas only ever create new files or read existing ones — they never write to the same file simultaneously." Only the SQLite DB file is the problem.
@Classic298 commented on GitHub (Apr 22, 2026):
@Joly0
just for ... understanding. i asked you earlier if you used any form of scaling, you said no - and you also said you don't use redis
but NOW you said you use docker swarm
how does that work out?
@Joly0 commented on GitHub (Apr 22, 2026):
I may have misread what you asked for when you asked for scaling, but for your question
Do you use uvicorn workers? Redis? Some other scaling?i answered withOther than that, no other database or redis or so. I am not using any kind of "scaling", open-webui is running on docker swarm, but always as/on a single node/instance. Docker swarm is only for HA (so if a node dies), not really for scaling, but i see what you mean and it was definitely me misunderstanding what you actually asked for with that question. But its still correct that i am not using redis or any other db.Though i thought it was clear that i am using some sort of docker orchestrator, i do not see any other reason to use shared storage through nfs if not for that.
@Classic298 commented on GitHub (Apr 22, 2026):
@Joly0 ok thanks that makes sense
i stopped making assumptions of people's setups after someone said they run Open WebUI on a machine with 128 cores and 2TB RAM but only gave it 1 mCPU (1 milli CPU) and 128 MB RAM. xd
@Joly0 commented on GitHub (Apr 22, 2026):
Ye, thats totally reasonable. Definitely sorry for leaving out that information, or better for not clarifying it clearer when you asked for it. You are giving awesome support and i should have given you as much information as i could provide and should have precisely described my environment when you asked for that information.
@Joly0 commented on GitHub (Apr 23, 2026):
Hey @Classic298 i just wanted to give you an update on this and some problems i have hit.
So i have tried using the tool you linked to migrate from sqlite to postgres. At first i had some problems because of a bug that appears to be originated by open-webui itself, its described here https://github.com/taylorwilsdon/open-webui-postgres-migration/issues/22
Other than that there were several other errors/warnings while migration, where i am not sure if this is a problem or not.
For example:
So there were several errors, all looking very similar (or are the same). I nthe end however the migration ended with a success (not sure though if it really was one, i have to verify).
But now when i try to start open-webui with
- DATABASE_URL=postgresql+asyncpg://${POSTGRES_OPEN_WEBUI_USER}:${POSTGRES_OPEN_WEBUI_PASSWORD_ENCODED}@postgres:5432/${POSTGRES_OPEN_WEBUI_DB}i get this error on startup of open-webui:
I dont think this is a problem with the migration, but rather with open-webui.
The postgres instance is running with this compose:
Regarding open-webui compose i didnt change anything to my previous compose (except for removing the database_sqlite and database_pool_size variables) other than adding:
@Classic298 commented on GitHub (Apr 23, 2026):
for database URL try "postgresql" also if "postgresql+asyncpg" yields this
@Joly0 commented on GitHub (Apr 23, 2026):
Ok, it appears to be working with
- DATABASE_URL=postgresql://${POSTGRES_OPEN_WEBUI_USER}:${POSTGRES_OPEN_WEBUI_PASSWORD_ENCODED}@postgres:5432/${POSTGRES_OPEN_WEBUI_DB}but not with- DATABASE_URL=postgresql+asyncpg://${POSTGRES_OPEN_WEBUI_USER}:${POSTGRES_OPEN_WEBUI_PASSWORD_ENCODED}@postgres:5432/${POSTGRES_OPEN_WEBUI_DB}@Joly0 commented on GitHub (Apr 23, 2026):
From my user the migration seems to have worked, atleast i cannot seem to see any missing chats, but those errors i posted earlier during migration are still kinda concerning
@Classic298 commented on GitHub (Apr 23, 2026):
Report it to @taylorwilsdon in his repository otherwise he won't see it
@Joly0 commented on GitHub (Apr 23, 2026):
Ok, will do, but shouldnt
postgresql+asyncpgwork accoridng to the open-webui docs?@Classic298 commented on GitHub (Apr 23, 2026):
yes looking into that. thx