Managing large-scale projects: file volume and performance considerations

Overview

Smartcat can technically support projects with tens of thousands of files — customers have created projects with 30,000-40,000 files. At this scale, however, file ingestion speed, system processing limits, and UI responsiveness become real considerations for how you plan and run the project.

This article explains what to expect at high file-volume scale, Smartcat's recommended project structure, and how to safely test and roll out a large-scale project.

When to use it

• You are planning a project with tens of thousands of files, such as a locjson-based content workflow

• You want to know whether to build one large project or split your content across multiple smaller projects

• You are evaluating upload speed, project statistics, or UI performance before committing to a large-scale rollout

Requirements and limitations

• Recommended project structure: around 1,000 files per project and around 1,000 segments per file, for optimal stability and usability

• Recommended upload rate: upload files at approximately 5,000 files per hour — faster ingestion rates can trigger system throttling and cause slower processing, queue delays, and instability

• A single project of 40,000+ files is high-risk from a usability standpoint, primarily due to statistics and UI performance rather than file processing itself

How it works

File ingestion at scale

The primary constraint for very large projects is upload throughput. Uploading files faster than the recommended rate can trigger Smartcat's system throttling mechanisms, which are designed to protect processing stability — but which slow down your own ingestion if triggered. Staying within the recommended rate keeps ingestion smooth and avoids queue delays.

Project statistics and UI performance

For projects with 40,000 or more files, some UI components calculate statistics (word count, file count, and similar metrics) and render project views using a full retrieval of the document list. On very large projects, this can result in:

• Long loading times when opening a project

• Temporary unresponsiveness in the project view

• Delays when switching between tabs

💡 Smartcat is aware of this behavior at scale and continues to invest in improving performance for very large projects.

How to use it

Follow this sequence to safely bring a very large project (for example, a 40,000-file locjson workflow) into production.

1. Run a controlled test in staging with a subset of your content — start with approximately 5,000-10,000 files

2. Validate upload stability, analysis time, and UI responsiveness against that subset

3. Increase your file volume incrementally rather than uploading everything at once

4. Maintain an ingestion rate of approximately 5,000 files per hour or fewer while scaling up

5. Evaluate usability at each stage, especially project opening time, statistics visibility, and the linguist working experience

6. Decide on your production rollout based on what you observed during testing, not on assumptions about scale

Testing incrementally and observing real behavior at each stage gives you a validated path to production instead of an untested jump to full scale.

FAQs

Can Smartcat handle a project with 40,000+ files?

Yes, technically — customers have created projects at this scale. Performance and usability, not raw processing capability, are the main considerations.

What upload rate should I use for a large batch of files?

Around 5,000 files per hour. Uploading faster risks triggering throttling, which slows things down rather than speeding them up.

Should I use one large project or split into multiple smaller ones?

Smartcat recommends a target structure of around 1,000 files per project and around 1,000 segments per file. If your workflow (for example, locjson-based content) can't be split this way, treat a single very large project as high-risk for usability and test incrementally before a full rollout.

Why is my large project slow to load or unresponsive?

Projects with tens of thousands of files can be slow to load or temporarily unresponsive because some UI components retrieve the full document list to calculate statistics and render project views. This is a known consideration at this scale.