Choosing a PMC System for SMB Factories: The On-Premise + LAN Sync Path

Why does an on-premise PMC system serving 0-500 employee factories choose a "local-first + LAN sync" architecture? This article uses real benchmark data to lay out the capabilities and boundaries of this approach.

If you run a 0-500 employee discrete manufacturing plant, where production data lives on-site, you have 2-10 PCs, you don't want the cloud, you don't want annual fees, and you need to keep working when the internet is down — on-premise deployment plus LAN multi-PC sync is a very pragmatic path.

This article is not about features. It's about one thing: how this architecture performs, what scale of factory it fits, and what scenarios it does not fit. If you're selecting a system, this will help you judge whether it matches your factory.

1. Why SMB factories prefer on-premise

Having worked with dozens of SMB factories, one common trait stands out: nearly all production data is created and consumed inside the LAN. Goods receiving, shop-floor reporting, purchase orders, shipment — it all happens on-site. Moving that data to a public cloud creates real problems:

• Network jitter: SMB factories have limited bandwidth; cloud systems often respond in 3-5 seconds
• Outage shutdown: internet outages are common in manufacturing — a cloud system that can't connect stops everyone
• Data anxiety: owners don't want their production data on someone else's server
• Subscription pressure: a cloud ERP costs tens of thousands per year — hard for SMB factories to accept

So the "less trendy" architecture — on-premise + LAN multi-PC — is actually the pragmatic choice for SMB factories.

2. Three mainstream multi-PC sync approaches

To support multi-PC collaboration, PMC systems generally take one of three approaches:

PMClite uses a hybrid "write-direction incremental push + read-direction incremental pull" approach:

• Client → host: client computes the delta locally and pushes only the changed rows (tens of KB)
• Host → client: host maintains a change log; client pulls deltas by sequence number
• First connection: one full snapshot, then everything is incremental

3. Three optimizations that make sync truly smooth

Step 1: Incremental push (client → host)

On every save, the client doesn't push the whole table. It compares the current in-memory data against the last snapshot, computes the changed rows, and pushes only those.

Result: one save drops from "tens of MB" to "tens of KB".

Step 2: Incremental pull (host → client)

The host appends each change to a change_log. On each poll, the client asks the host "what's the current sequence number?", and pulls only the part newer than its local progress. If the client has been offline too long (log cleaned up), it automatically falls back to a full sync.

Result: each client sync drops from "full snapshot" to "the changed rows".

Step 3: Client applies only the delta

This is the most overlooked step — but it delivers the biggest gain. Many "incremental sync" implementations only solve the network side; the client still reloads its entire in-memory dataset on receiving the delta, which is just as slow.

PMClite does this: after writing the delta to the local database, only the affected rows in memory are updated; only the affected indexes and caches are rebuilt; only the currently visible page is re-rendered.

Result: in-memory processing per sync drops from 3-5 seconds to 100-300ms — a 10× gain.

4. Benchmarks: before vs after

Test environment (mainstream office spec): Intel i5-10400 (2020-era), 16 GB RAM, SATA SSD, gigabit switched LAN.

Test dataset (1-2 years of accumulation from a mid-sized electronics factory):

Per-sync latency

Network traffic

Multi-client concurrency

5. Honest boundaries

We don't claim it can handle every scale. Here are the real boundaries of this architecture:

Very few SMB-focused PMC systems combine "on-premise + LAN multi-PC + incremental sync". Most products are either heavy cloud ERPs (expensive, offline-unusable) or lightweight single-PC apps (no multi-PC). PMClite chose the middle path — push "local-first" to its limit while keeping multi-PC collaboration.

6. FAQ

Q1: Why not use WebSocket for real-time push?
WebSocket can deliver millisecond-level sync, but the complexity is high (async programming, reconnection, heartbeat keep-alive) and maintenance cost is significant. For SMB PMC scenarios, 5-second polling is more than enough — your order appears on a colleague's screen within 5 seconds, with zero business impact. So we're not doing it for now, and we'd rather put effort where it actually improves UX.

Q2: Why SQLite instead of MySQL?
SMB single-site collaboration has four requirements: single-file backup, zero ops, encrypted storage, offline usability. SQLite + SQLCipher fits all four better than MySQL. The trade-off is no high-concurrency writes — which is why the design ceiling is ~20 clients; beyond that, you need a different architecture.

Q3: What if two people edit the same record?
Current semantics are "last write wins", the same as most cloud ERPs: the later commit overwrites the earlier one. For the vast majority of PMC operations (order status changes, work-order progress reports, inventory adjustments), this is sufficient.

Q4: What if the host PC fails?
The host is a single point. When it restarts, all clients reconnect automatically (data lives on the host disk). If you need true high availability, you'd need a distributed architecture — but that goes beyond SMB requirements. We recommend regular use of the built-in "Backup database" feature to a USB drive or a second disk.

Q5: How is data security ensured?
The database is encrypted with SQLCipher; the key is derived from the local machine fingerprint (hardware-bound); the license file is signed with Ed25519; the DB file cannot be decrypted off the original machine. Even if someone copies your data file, it won't open without that machine's hardware fingerprint.

Q6: What's the biggest difference from a cloud ERP?
Cloud ERP is "thin client + central database": the client stores nothing, everything depends on the network. PMClite is "fat client + local-first": each client has its own encrypted database; daily operations don't depend on the network, and only changes are synced.
Upside: offline usable, local-speed response, data in your own hands. Downside: more complex sync logic, larger local storage footprint.

7. Final thoughts

After years building production management systems for SMB factories, the deepest realization is this: there is no "strongest" architecture — only the one that best matches the scenario.

Cloud ERP has its place — mid-to-large enterprises with cross-region, multi-entity, tight-control needs. On-premise + incremental sync also has its place — single-site SMB factories with 2-10 PCs that don't want the cloud.

PMClite is a product built to nail that scenario:

• Local-first architecture built on Tauri + Rust + SQLite
• Three-layer optimization: incremental push, incremental pull, incremental client apply
• 100-300ms per sync at 5,000 materials
• Comfortable at 5-10 PCs collaborating

We don't try to do everything — we try to be better, more stable, and better fit within this scale band.

Honesty beats hype. All benchmarks in this article were run on a mainstream office configuration (i5-10400 / 16 GB / SATA SSD), with a dataset comparable to 1-2 years of accumulation from a mid-sized electronics factory. PMClite is an independent product.