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

El issue no menciona archivos fuente, pruebas ni puntos de entrada. Empieza revisando los issues relacionados #8448, #8802 y #8260; después, recopila evidencias sobre despliegues grandes de GitLab, las estructuras de proyectos y blueprints, el paralelismo de pipelines y los límites de las bases de datos compartidas. Se considerará terminado cuando se documenten la escala admitida, las indicaciones de configuración, los cuellos de botella y si se admite el funcionamiento multiinstancia con MySQL compartido.

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