> For the complete documentation index, see [llms.txt](https://help.security.gallagher.com/knowledge-hub/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.security.gallagher.com/knowledge-hub/products/cc-software/reference/databases-sizes-and-examples.md).

# Database sizes and examples

Estimate Command Centre database storage from site data and archiving needs.

## CCFTCentral

#### How large does the configuration database get, and what drives its size?

The configuration database size depends on the number of FT item entities (including cardholder PDF data such as images), so Gallagher does not recommend setting a fixed limit. Real-world examples:

| Site   | Cardholders | Controllers | Doors | CCFTCentral size |
| ------ | ----------- | ----------- | ----- | ---------------- |
| Site 1 | 109,000     | 215         | 1,058 | 5.25 GB          |
| Site 2 | 10,293      | 50          | 194   | 1.3 GB           |
| Site 3 | 14,000      | 300         | 925   | 7.7 GB           |

Factors that vary the size: cardholder images (and their size), site plan images (and their size), event generation rate, and Command Centre version (later versions add functionality). To slow growth: cardholder purge (remove inactive/disabled cardholders), database maintenance, and image compression.

## CCFTEvent

#### How large does the event database get?

Rough sizing: one database here held 3,714,606 events at 1.9 GB, so allow **roughly 512 bytes per event**.

#### How often should a site archive?

Event database size depends on the frequency of events received versus the frequency of archiving. This is a balancing act:

* Archiving too frequently slows retrieval and operational performance.
* Archiving too infrequently lets the event database grow.
* Rule of thumb: if the customer needs to view a week of events, archive every 2-3 weeks; if they need a month of events, archive every 2-3 months. For a mix, use the most important scenario as the baseline.

Once a site reaches its "Remove Events Older Than..." number of days, the event database does not vary greatly in size, as events archive out from that point. Archived data uses less space because the files are compressed. Note that an upgrade may grow the event database (tables may need enlarging to support new functionality), and during the upgrade it may temporarily double in size as part of rearranging the data.

{% hint style="warning" %}
**Caution:** Best-practice database maintenance should also be deployed, for example purging redundant event history. See [Databases - Compressing or Shrinking the DB](/knowledge-hub/products/cc-software/configure/databases-an-overview-of-command-centr/databases-compressing-or-shrinking-the.md) for the 10 GB SQL Express cap and how to shrink a database.
{% endhint %}

***

🔗 **Related**

* [Archiving - An Overview](/knowledge-hub/products/cc-software/configure/archiving-and-backups/archiving-an-overview.md). Keeping the event database in size.
* [Databases - Compressing or Shrinking the DB](/knowledge-hub/products/cc-software/configure/databases-an-overview-of-command-centr/databases-compressing-or-shrinking-the.md). Reclaiming space after archiving.
* [Databases - Structure](/knowledge-hub/products/cc-software/configure/databases-an-overview-of-command-centr/databases-structure.md). What each database holds.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://help.security.gallagher.com/knowledge-hub/products/cc-software/reference/databases-sizes-and-examples.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.