[Question][framework] Configuring DevLake for ~6.5k GitLab repos and company-wide metrics

La issue non indica file sorgente, test o punti di ingresso. Inizia esaminando le issue correlate #8448, #8802 e #8260, quindi raccogli dati sulle distribuzioni GitLab di grandi dimensioni, sulle strutture di progetti e blueprint, sul parallelismo delle pipeline e sui limiti dei database condivisi. Il lavoro sarà considerato completato quando saranno documentati la scala supportata, le indicazioni di configurazione, i colli di bottiglia e se è supportato il funzionamento multiistanza con MySQL condiviso.

We are sizing a DevLake deployment for a large GitLab estate and want to know whether a single instance is expected to handle this, and how we should configure projects/blueprints if so.

Scale

• One product org already has ~6,500 GitLab repos; we need to plan for tens of thousands across the company.
• Teams are disjoint (no shared repos between team projects).
• We still need org- and company-wide metrics (e.g. Cycle Time) from one database. We do not use Grafana; a metrics API reads the same MySQL.
• Splitting into isolated DevLake+MySQL stacks would speed collection, but then we could not compute org- or company-wide Cycle Time with a single query against one database.

What we think is the intended setup (please correct us) :

• One lake process, one MySQL (we know a second instance on the same DB_URL hits the exclusive _devlake_locking_stub lock).
• Many team-sized projects/blueprints (tens to ~150 repos each), not one project with 6,500 scopes.
• PIPELINE_MAX_PARALLEL > 1, staggered crons, incremental sync, skip heavy gitextractor options if needed.

Questions

1. Has anyone run DevLake successfully at a few thousand GitLab repos on one instance? What project size, PIPELINE_MAX_PARALLEL, and sync policy actually worked?
2. Is the guidance above right, or is there a better project/blueprint layout for this?
3. At this scale, is the bottleneck expected to be the single runner (sequential blueprints / sequential GitLab stages) rather than MySQL?
4. If one instance cannot keep a daily incremental cycle, is the intended path still “more hardware on one process”, or is multi-instance sharing one DB something the project would consider?

Related: #8448, #8802, #8260