Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

Please note the documentation below requires more technical expertise

The documentation below may require knowledge of more technical software management and development topics.

A frequent question about using CommCare is, "How many cases are too many?" This question has many dimensions, and this page is intended to help you think through them. The acceptable number of cases varies depending on several factors including Case Size, Device type, and desired Sync Time.

Case Size

Case Size refers to the amount of data and metadata associated with a particular case within the application. The size of a case can impact performance and storage, so it's helpful to understand what contributes to case size.

  • Number of Case Properties: The more properties a case has, the larger its size.

  • Data Types (e.g., text, integers, dates, multimedia): For example, text fields typically consume more space than integer fields.

  • Case History: CommCare tracks changes to case properties over time. A detailed case history with many updates can increase the overall size of the case.

  • Case Relationships: Parent-child relationships add metadata to the case, contributing to its size.

  • Multimedia Attachments: If a case includes multimedia files (e.g., images, audio recordings), these files significantly increase the size of the case.

  • Form Submissions: The number and complexity of form submissions linked to a case also affect its size. Each form submission can update case properties and add to the case history.

  • App Complexity: CommCare allows for incredibly complex apps–employing multiple data types, advanced functions, repeat groups, lookup tables, and more. This can result in redundancies, complex hierarchies, and an increase in the number of data fields that need to be stored.

  • Case sharing: This will not add to the Case Size, but may require more frequent syncing in order to maintain up-to-date information.

Device type (Web Apps vs Mobile)

Some projects use Web Apps only, some use Mobile only, and some use a combination of the two. The speed of syncing and app and its cases is dependent on:

  • Internet speed

  • Device speed

  • Memory

You might find that because of the type of device that you would use Web Apps on, the syncing is faster. There is also a more continuous syncing with Web Apps (vs syncing everything at once) that will allow for faster (and larger) syncing with Web Apps. 

The sync time with the server is affected by the total number of cases on the phone or Web App. Therefore, the first sync will be slower. However, subsequent syncs will be faster and are less likely to time out. The server calculates the data to be sent to the phone or Web App during the first sync request and will cache the data for subsequent requests even if the first sync times out.

Maximum Desired Sync Time

This refers to how long of a sync time your users can reasonably handle. There is, of course, the chance that the device will time out if the sync is taking too long, but also there is the experience of the user to consider. Waiting 15 minutes for a sync to complete may not be something that they can accommodate in their daily workflow. You may decide to sync fewer cases in order to shorten the sync time.

Best Practice

  • Reduce the number of Case Properties. All of the data you collect will be in your form, so only save the data necessary for identifying the case or for use in follow-up forms as Case Properties. 

  • Archive or Close Old Cases. Only open cases will sync to the app, keeping the sync time lower.

  • Upload Small Multimedia Files. Adjust your device’s camera to take smaller photos (<1 MB).

  • Reduce Case Updates. If a form does not change the value of an existing Case Property, don’t update it. This will keep the case history concise.

  • Carefully review your app to be sure that it is efficiently gathering the data you need, without redundancies. Organize your cases in such a way that users can sync all of the cases they will need to do their work before their next sync.

How many cases are too many?

Coming back to the original question, “How many cases are too many?” 

  • Technically feasible: 10,000

  • Best practice: 1,000

The best, best practice is to test this for yourself. A rough rule of thumb for an "average" case is that every 25 cases or so will add an additional second to the sync process.

How many Case Properties are too many?

There is no definitive answer, due to the variety in applications, but after about 500 you are definitely at risk of issues. And if your app is more complex, then even 500 may be too many. It’s important to test.

How to Test

Generally, we recommend testing your particular scenario with cases created using the Excel importer tool.

  • No labels