Scaling Enterprise Fieldwork with Mergin Maps DB Sync and Work Packages

The core challenge of large-scale geospatial field data collection isn't capturing the data; it's managing the human workflow around that data.

At MapMatics, we frequently work with organizations who have successfully trialed Mergin Maps with 5 or 10 users. But as soon as they attempt to scale that workflow to an enterprise level—with 50, 100, or more users across different categories or regions—the traditional single-project model breaks down.

The complexity increases exponentially. How do you allow multiple users to edit the data simultaneously without conflicts? How do you ensure users only see and edit data relevant to their specific category or organization? And, crucially, how do you synthesize all this activity back into a central, authoritative database in near real-time, with full two-way synchronization?

Today, we are diving deep into the technical architecture that solves this paradox. The solution doesn't require complex custom scripting; it relies on mastering two foundational pillars of the advanced Mergin Maps ecosystem: DB Sync and Work Packages.

The Anatomy of the Enterprise Field Problem

Before we look at the solution, let's visualize the enterprise scenario we are addressing. We need an architecture that supports five rigid constraints:

• Enterprise scale: The system must handle hundreds of simultaneous connections.
• Concurrency: Multiple users must be able to view and edit the data layer at the same time.
• Logical isolation: Data must be partitioned by organization or category. User A (Category Blue) must not see or edit User B's (Category Green) data.
• Role-based access control: Users are restricted to editing data only within their specific category or organization partition.
• Bi-directional convergence: All changes from all partitions must synchronize seamlessly back to a master, collective database layer.

This is a complex data flow problem that is impossible to solve with simple file-based GeoPackages alone. It requires a robust backend and clever project management logic.

Figure 1: The full, interconnected enterprise architecture we are building. This schematic shows the flow from multiple field teams (Category Red, Blue, Green), through the logical Work Package sync, converging back to the master PostGIS collective layer. Crucially, two-way synchronization is established across all paths.

The Two Pillars of the Enterprise Solution

The image above (Figure 1) visually maps out the complex journey. The core of this robust workflow is the combination of Mergin Maps DB Sync and the application of Work Packages.

Understanding how these two tools interact is the key to enterprise success.

Pillar 1: The Backbone (DB Sync)

The problem with native Mergin Maps projects is that they usually depend on GeoPackage (GPKG) files. When you have hundreds of users, editing a single file leads to serious database locking and versioning nightmares.

We need a persistent, multi-user database backend. This is where PostgreSQL/PostGIS enters.

DB Sync (Database Synchronization) is a Mergin Maps feature that sits on your server. It creates a connection between a specific Mergin Maps project and a live PostGIS database table. When data is captured in the field, it syncs to the Mergin Maps project, and the DB Sync service immediately writes that data to the PostGIS master table. The process also works in reverse.

Benefits: You get real-time access to the data, powerful SQL querying, and the stability of a production-grade database.

Pillar 2: The Logic (Work Packages)

If we used DB Sync by itself for hundreds of users, we would still have a major problem: all users would see all data, and they could edit everything. This violates the constraint of logical isolation. We need a filtering mechanism.

This is the purpose of Work Packages.

A Work Package is essentially a powerful filtering and partitioning service. It takes the main DB Sync project (the big collective project) and splits it into multiple sub-projects.

You, as the administrator, define the logic—usually through SQL queries on your PostGIS database. For example: "If user Field_Team_Alpha logs in, only download data WHERE category = 'A'." Work Packages creates a small, targeted Mergin Maps project just for that team.

The magic of Work Packages is that it handles the two-way sync between the main DB Sync project and the dozens of category sub-projects. The field user only interacts with their small sub-project, but their changes flow intelligently back to the main project, through DB Sync, and into the live database.

Mastering the Workflow: Step-by-Step

Let's refine the high-level schematic (Figure 1) and break down how data travels across this architecture. The key is understanding that the database (PostGIS) is the single point of truth.

1. The Setup (PostgreSQL/PostGIS Views)

First, you establish your master database. Let's say you have a single PostGIS layer called collective_field_data.

In your PostGIS database, you create specific SQL views based on your categories or organizations. For example:

-- Create a view for Category A
CREATE VIEW data_category_a AS
SELECT * FROM collective_field_data
WHERE category = 'Category A';

-- Create a view for Category B
CREATE VIEW data_category_b AS
SELECT * FROM collective_field_data
WHERE category = 'Category B';

Figure 2: The filtering mechanism. The central PostGIS database (established in Figure 1) uses SQL filtering logic to partition the collective master data. This logic dynamically generates distinct, isolated Mergin Maps sub-projects—the Work Packages—specific to each category (Category Blue, Category Red), ensuring data isolation.

2. Field Execution and Sync

This is where the architecture proves its worth. The setup visualized in Figure 2 is complete. Now, the user experience looks like this:

Field UX (The isolation): A user from Category Blue (Figure 1) opens the Mergin Maps app on their mobile device. They only see the project WORK PACKAGE: CATEGORY BLUE. They download it. The map is clean; it only contains blue data.

The two-way sync (Convergence): The user captures new data or edits an existing point in the field. When they press Sync, the data leaves their device.

1. The data syncs to the Mergin Maps sub-project.
2. The Work Package service (Figure 2, connecting logic) detects the change. It knows which master table this data belongs to. It pushes the new blue point into the data_category_a PostGIS view.
3. Because the view is built on the live master table, the data is automatically written to the collective layer database (Figure 1).
4. Within moments, any changes made by other users (Green or Red) that occurred since the last sync are downloaded into the Blue user's project, keeping their filtered view up to date.

Figure 3: Live field execution. Distributed field teams (the users defined in Figure 1) capture data using the filtered Work Package interfaces (defined in Figure 2). Glowing paths show the live, two-way convergence of data from different devices, passing through the sync logic and synthesizing into the powerful central master PostGIS database.

Conclusion: Complexity Managed by Architecture

This architecture solves the enterprise scaling paradox. It provides a simple, clean, and isolated interface for hundreds of field users. At the same time, it integrates a powerful, multi-user database backbone through the clever application of DB Sync and Work Packages.

If your organization is struggling to move past pilot projects because of the complexity of managing large field teams and conflicting data edits, this architectural shift is the solution.

At MapMatics, we specialize in deploying these advanced Mergin Maps enterprise workflows. We can help you configure your PostGIS backend, set up DB Sync on your server, and implement the Work Packages logic required to partition your data effectively.

Contact Us to Scale Your Fieldwork

Are you ready to move your field data collection to the enterprise level? Contact MapMatics today for a consultation on setting up a robust, scalable Mergin Maps workflow with DB Sync and Work Packages.