Repository navigation
db-sync daemon silently stops syncing — large version gap between DB and Mergin Maps project (v26 DB vs v92 GPKG) #179
Description
Environment
- Mergin Maps: self-hosted instance via Docker (CE) version 2.1.1
- db-sync: Docker container (
lutraconsulting/mergin-db-sync) - Database: PostGIS (PostgreSQL)
- Init mode:
--init-from-gpkg - Projects: Multiple production projects initialized with DB Sync, each with dedicated schemas
Description
We are running db-sync in production against a self-hosted Mergin Maps instance. Synchronization initially works correctly — data collected on mobile devices appears in the PostgreSQL database as expected.
However, at some point the daemon appears to stop syncing silently: the Docker container keeps running (no crash reported, no restart), but new changes from Mergin Maps are no longer applied to the database. There is no visible error or alert.
We only discovered the issue by noticing a growing discrepancy between database content and what was visible in the Mergin Maps web interface and mobile app.
Observed state:
- Mergin Maps project (web + mobile): v92
- GPKG file: v92
- PostgreSQL database (base + modified schemas): stuck at v26
- ~2,000 records collected between v26 and v92 were missing from the database
- Users continued collecting data normally on the mobile app without any issue
Steps to reproduce
We cannot reliably reproduce the issue on demand, but the sequence appears to be:
- db-sync is initialized from GPKG and runs correctly for a period of time
- At some point (possibly triggered by a network hiccup, a large changeset, or a geodiff error on a specific diff), the daemon stops applying changes to the database
- The Docker container remains in a running state — no restart, no error in the console output we observed
- New versions continue to be pushed to Mergin Maps by mobile users without any problem
- The database version counter freezes while the Mergin project version keeps incrementing
Questions / requests
- Is there a known condition that causes the daemon to silently stop applying changes without exiting?
- Is there a way to resume sync from a specific project version without a full
--force-init(to avoid data loss in case of future incidents)? - Are there recommended log verbosity settings and monitoring practices for production deployments?
- Are you planning any future versions of Mergin Maps?
Related issues
- Network issues may freeze sync #10 — Network issues may freeze sync (no timeout on Mergin client)
- tool fails to restart after its stopped #30 — Tool fails to restart after being stopped
- Failed to run db sync after changing project name in the config #142 — Version mismatch after config change
Activity
afourneyron commentedon May 11, 2026
After restart docker service :
root@24809ccd8f90:/mergin-db-sync# python3 dbsync_daemon.py /settings/config.yaml
== starting mergin-db-sync daemon == version 2.1.1 ==
Using config file: /settings/config.yaml
Logging in to Mergin...
Going to log in user XXX
User XXX successfully logged in.
Processing Mergin Maps project 'mergin/projet_oedicneme'
Connecting to the database...
Modified and base schemas already exist
Working directory /tmp/dbsync/projet_oedicneme already exists, with project version v26
There are pending changes on server, please run pull command after init
Checking GeoPackage content...
Checking 'base' schema content...
Local project version at v26 and base schema at v26
Base schema changes:
t_couples 0 1 0
t_observation 0 1 0
The output GPKG file exists already but is not synchronized with db 'base' schema.Running
dbsync_deamon.pywith--force-initshould fix the issue.[-]## db-sync daemon silently stops syncing — large version gap between DB and Mergin Maps project (v26 DB vs v92 GPKG)[/-][+]db-sync daemon silently stops syncing — large version gap between DB and Mergin Maps project (v26 DB vs v92 GPKG)[/+]rjwillson commentedon May 12, 2026
I experienced this same issue last week where there was no indication in the container logs that there were any syncing problems.
the only reason I noticed that the sync was broken was because of the discrepancy in record counts between the geopackage tables and the postgres layers
I also always now use db-sync initialized from GPKG to avoid data loss for field users or conflicted geopackage copies for field users
I am also interested to know if there
"Is there a way to resume sync from a specific project version without a full --force-init (to avoid data loss in case of future incidents)?"
if there is a not a solution, then I was thinking I could have the dbsync reset in the middle of the night if there is a record count differential between geopackage and postgres table
afourneyron commentedon Jun 1, 2026
Thanks @rjwillson for your reply!
We're going to try changing the
init_fromsetting to use the source gpkg and rundbsync --force-initevery night to verify that synchronization and data retrieval are working properly.I hope it works, I'll let you know if it works
A reset of dbsync in the middle of the night every day may not be very costly and helps ensure that synchronization works properly.