So I followed the guide at https://github.com/lldap/lldap/blob/main/docs/database_migration.md 1. Created all tables using

docker exec -it <LLDAP container name> /app/lldap create_schema -d <Target database url>

2. Dumped existing data from sqlite to a file

./sqlite_dump_commands.sh | sqlite3 /path/to/lldap/config/users.db > /path/to/dump.sql

3. Sanitized the data for postgres with

sed -i -r -e "s/X'([[:xdigit:]]+'[^'])/'\\\x\\1/g" \
-e ":a; s/(INSERT INTO (user_attribute_schema|jwt_storage)\(.*\) VALUES\(.*),1([^']*\);)$/\1,true\3/; s/(INSERT INTO (user_attribute_schema|jwt_storage)\(.*\) VALUES\(.*),0([^']*\);)$/\1,false\3/; ta" \
-e '1s/^/BEGIN;\n/' \
-e '$aSELECT setval(pg_get_serial_sequence('\''groups'\'', '\''group_id'\''), COALESCE((SELECT MAX(group_id) FROM groups), 1));' \
-e '$aCOMMIT;' /path/to/dump.sql

4. Point lldap container to postgres db using env variable

LLDAP_DATABASE_URL

This is when I encounter errors from the container. I believe lldap is trying to so some invalid migrations. Can someone give some pointers on how to solve this?

message has been deleted

lldap container:

[entrypoint] Copying the default config to /data/lldap_config.toml
[entrypoint] Edit this file to configure LLDAP.
> Setup permissions..
> Starting lldap..
Loading configuration from /data/lldap_config.toml
WARNING: A key_seed was given, we will ignore the key_file and generate one from the seed! Set key_file to an empty string in the config to silence this message.
2025-11-11T03:47:12.763912758+00:00  INFO     set_up_server [ 15.1ms | 100.00% ]
2025-11-11T03:47:12.763938062+00:00  INFO     ┝━ ｉ [info]: Starting LLDAP version 0.6.2
2025-11-11T03:47:13.353758460+00:00  INFO     ┝━ ｉ [info]: Upgrading DB schema from version 1
2025-11-11T03:47:13.353764048+00:00  INFO     ┝━ ｉ [info]: Upgrading DB schema to version 2
2025-11-11T03:47:13.702412795+00:00  INFO     ┕━ ｉ [info]: Upgrading DB schema to version 3
Error: while creating base tables
Caused by:
    0: Execution Error: error returned from database: column "first_name" does not exist
    1: error returned from database: column "first_name" does not exist
    2: error returned from database: column "first_name" does not exist
    3: column "first_name" does not exist

I'm surprised that it's trying to run migration. You should have an lldap_metadata column with the version number which should be 8+ (don't remember the exact value)

Perfect! Thanks for the hint @nitnelave version column in metadata table had value set as 2. I updated it to 11 based on output from log. working good now

That's weird, creating the schema should have set the version number. Did you get any error when creating the schema?

Thats on me. I took create schema as literally create schema and did not consider any potential DML My setup is to manage a shared postgres db for many apps and the way I managed my migrations using flyway So post creating a schema using the provided commands. I dumped all the DDL's into a migration script for the new lldap database I similarly took the output of the dump data step and included into another migration that said it would be nice to have(may be they already are) the migration scripts available somewhere in a structured so that an external tool like flyway, liquibase can be hooked into for database related migrations

The scripts are written in rust, because they get translated to the DB specific dialect

Understood. I see the challenge there How about providing an api/cli equivalent of 1. listing down all migrations till date for the current version 2. another option to list only migrations applicable between 2 versions, if any would that sound better?

I wouldn't want to have to translate the migrations into a different format, that seems risky. Why is running the migrations as part of LLDAP startup a problem?

automation. because it helps in creating the setup very easily say I bring in a new host machine where this setup needs to be replicated I trigger my flyway migrations: - it readily setups up my lldap database - creates schemas/data as needed this is followed by bringing up the versions of the app that I need in isolation, it would not matter much but you can imagine across multiple apps, it greatly simplifies the process

It sounds like you can have a simple flyway migration that just creates an empty DB, and let LLDAP populate it on first run (you don't need to create the schema in advance)

does it work if I directly point it to postgres without starting with sqlite? say I create the empty db as you suggested, point database_url to postgres. will it do the schema setup, initial DML's?

Yes it will!

hmm. that solves my problem in that case

Great 🙂

my bad. when i read the docs it seemed like one always has to start with sqlite and then migrate to other databases

Have another look at the place where the docs were confusing, and if you can propose a clarification, it'll be gladly accepted!