MeshCentral Optimization TODOs

High Priority: Switch from NeDB to PostgreSQL

Current State:

• MeshCentral uses NeDB (file-based database) for storing devices, groups, users, sessions
• Backend queries MeshCentral data via API calls and webhooks
• Persistent volume mounted at /opt/meshcentral/meshcentral-data

Problem:

• API calls add latency (~50-100ms per request)
• Webhook delays (not real-time)
• Complex sync logic required
• Separate data stores = potential inconsistencies

Proposed Solution: Switch MeshCentral to use PostgreSQL backend (same database as RMM backend)

Benefits:

• ✅ Direct database access - Backend can query device data directly (no API calls)
• ✅ Real-time data - No webhook delays or sync workers needed
• ✅ Single source of truth - All data in one database
• ✅ Better performance - 10-20x faster queries vs API calls
• ✅ Simpler architecture - Remove sync workers and webhook handlers
• ✅ Better scalability - PostgreSQL handles concurrent access better than NeDB

Implementation Steps:

1. Update MeshCentral Config

Edit config.json.template:

{
  "settings": {
    // ... existing settings ...
    
    // Add PostgreSQL backend
    "postgres": {
      "host": "${POSTGRES_HOST}",
      "port": "${POSTGRES_PORT}",
      "user": "${POSTGRES_USER}", 
      "password": "${POSTGRES_PASSWORD}",
      "database": "${POSTGRES_DB}",
      "ssl": true
    }
  }
}

2. Alternative: Environment Variables

MeshCentral supports these env vars:

USE_POSTGRESQL=true
POSTGRES_HOST=rmm-psa-db-do-user-28531160-0.i.db.ondigitalocean.com
POSTGRES_PORT=25060
POSTGRES_USER=doadmin
POSTGRES_PASSWORD=AVNS_J8RJAmsEwsHFG52_-F2
POSTGRES_DB=meshcentral  # Use separate DB or defaultdb

3. Database Schema

MeshCentral auto-creates tables:

• meshcentral_meshes - Device groups
• meshcentral_nodes - Devices
• meshcentral_users - Users
• meshcentral_events - Event log
• meshcentral_power - Power events
• meshcentral_smbios - Hardware info

4. Backend Code Changes

Remove/Simplify:

• routes/meshcentral.js - Direct DB queries instead of API calls
• workers/meshcentralSync.js - No longer needed
• routes/webhooks.js (MeshCentral section) - Direct DB updates
• startup/tenant-meshcentral-sync.js - Direct table queries

Example Direct Query:

// OLD: API call (slow)
const api = new MeshCentralAPI(...);
await api.login();
const devices = await api.getNodes();
 
// NEW: Direct DB query (fast)
const devices = await db.query(`
  SELECT * FROM meshcentral_nodes 
  WHERE meshid = $1 AND state = 1
`, [meshId]);

5. Migration Process

1. Test in dev first - Spin up test MeshCentral with PostgreSQL
2. Backup NeDB data - Export existing devices/groups if any
3. Update config - Add PostgreSQL settings
4. Deploy - Let MeshCentral create schema
5. Verify - Check devices appear in PostgreSQL
6. Update backend - Switch to direct queries
7. Remove old code - Delete sync workers, API wrappers

6. Rollback Plan

• Keep NeDB volume mounted as backup
• Can switch back by removing PostgreSQL config
• Webhook system still works as fallback

Estimated Effort: 4-6 hours Estimated Performance Gain: 10-20x faster device queries Risk Level: Medium (requires testing)

References:

• MeshCentral PostgreSQL docs: https://github.com/Ylianst/MeshCentral/blob/master/db.js
• Our fork: https://github.com/Independent-Business-Group/MeshCentral
• Docker env vars: https://github.com/Ylianst/MeshCentral/blob/master/docker/README.md

Status: 📋 TODO - Deferred until current system is fully tested

---

Other Optimizations

Medium Priority: Cache Frequently Accessed Data

• Redis cache for device status
• TTL: 30 seconds
• Invalidate on webhook events

Low Priority: WebSocket Direct Connection

• Replace webhook polling with persistent WebSocket
• Real-time device updates
• Lower latency

---

Last Updated: 2026-03-06 Next Review: After Agent v3 testing complete