Question: Is there an official migration path from SQLite to PostgreSQL in codex-lb?

[Brook-ning]

Hi codex-lb team and community,

I'm currently using codex-lb with the default SQLite backend in a production-like environment. Recently, I've been encountering frequent 500 errors due to SQLite's single-writer limitation — specifically, write operations queue up and exceed the built-in teardown timeout (bound_seconds=5.0), causing requests to be cancelled and returning errors to clients.

I'm aware that codex-lb supports PostgreSQL as an alternative database backend via the CODEX_LB_DATABASE_URL environment variable. However, I couldn't find any official documentation or built-in tooling that describes how to migrate existing data from SQLite to PostgreSQL.

My questions are:

1. Does codex-lb provide any official migration tool or command (like codex export/import) to transfer data from SQLite to PostgreSQL?
2. If not, what is the recommended approach? Should I use third-party tools like pgloader, or is there a specific workflow you suggest?
3. Are there any critical considerations I should be aware of during the migration, such as:
   • Handling encrypted data (e.g., plugin credentials stored with encryption keys)?
   • Schema compatibility between SQLite and PostgreSQL?
   • Ensuring data consistency during the switch?

For context:

• codex-lb version: 1.24.0
• Running in a containerized environment (Docker)
• We have a moderate amount of existing data stored in SQLite that we'd like to preserve

Any guidance, official or community-recommended, would be greatly appreciated. Thank you!

P.S. If there's currently no official migration path, I'm also happy to contribute documentation or tools if you can point me in the right direction.

[gyanu2507]

Short answers:

1. There is no official codex export/import (or similar) that copies live data from SQLite to PostgreSQL.
2. What does exist is schema migration on whatever DB you point CODEX_LB_DATABASE_URL at. Startup/Alembic brings an empty Postgres up to head. It does not move rows out of an existing SQLite file.
3. Practical cutover people use: stand up Postgres, point a fresh instance at it, let migrations run, then copy application data with a one-off script or pgloader only if you have mapped the tables yourself. Treat encrypted fields carefully. If credentials are sealed with a key from env/config, that key must be identical on the new deployment or those blobs will not decrypt.
4. Do the switch with the app stopped (or read-only) so you do not split writes across two backends.

Docs cover SQLite vs Postgres config and Postgres version upgrades, not SQLite→Postgres data move: https://soju06.github.io/codex-lb/database/

If you want to contribute, a small “dump selected tables → insert into Postgres” doc plus a warning about encryption keys would fill the gap better than pretending Alembic alone migrates the data.