Database sizing

What retention actually bounds

The database does not grow without limit. SecurSpaces applies MongoDB TTL indexes, and the retention window differs by data type:

Data	Retention	Effect on size
Audit and security events	360 days	The dominant long-lived category
Website activity logs	360 days	Grows with user activity
Error logs	30 days	Negligible at steady state
Raw Kubernetes usage samples	14 days	Bounded regardless of workspace count
Project activity, debug logs, cron records	7 days	Negligible

Data

Retention

Effect on size

Audit and security events

360 days

The dominant long-lived category

Website activity logs

360 days

Grows with user activity

Error logs

30 days

Negligible at steady state

Raw Kubernetes usage samples

14 days

Bounded regardless of workspace count

Project activity, debug logs, cron records

7 days

Negligible

This matters when sizing for a larger deployment. Per-workspace usage sampling is the data that scales hardest with workspace count, and it is discarded after 14 days, so it does not accumulate. Network events are also stored as summaries with a request count rather than one document per request.

The result is that the database tends toward a steady state of about one year of audit and event data, plus your relatively static configuration.

Estimated footprint

The following estimate is for an environment of 500 developers using 500 workspaces. For smaller deployments, including a proof of concept, see Smaller deployments.

Data category	Approximate footprint	Notes
Organizations, projects, settings	< 100 MB	Scales with project count, not workspace count.
Users, groups, roles	< 250 MB	Scales with user count.
Workspace and template metadata	< 500 MB	Scales with workspace and template-version count.
Credentials and API keys	< 250 MB	Lower if HashiCorp Vault stores your secrets.
Audit, event, usage, and reporting records	5–25 GB (steady state)	Largest category, bounded by the 360-day expiry. Varies most with how active the platform is.
Indexes and overhead	25–50% of data size	MongoDB indexes plus working-set overhead.

Data category

Approximate footprint

Notes

Organizations, projects, settings

< 100 MB

Scales with project count, not workspace count.

Users, groups, roles

< 250 MB

Scales with user count.

Workspace and template metadata

< 500 MB

Scales with workspace and template-version count.

Credentials and API keys

< 250 MB

Lower if HashiCorp Vault stores your secrets.

Audit, event, usage, and reporting records

5–25 GB (steady state)

Largest category, bounded by the 360-day expiry. Varies most with how active the platform is.

Indexes and overhead

25–50% of data size

MongoDB indexes plus working-set overhead.

Working estimate: configuration and metadata for 500 developers and 500 workspaces is on the order of 1 GB. With a year of audit and event data plus indexes, plan for 10–40 GB of actual data.

The spread is wide because activity level, not user count, drives the largest category. A platform where every workspace runs all day with network monitoring enabled sits at the top of that range; one used for a few hours a day sits near the bottom.

Provisioning guidance

Storage: Provision at least 100 GiB for the data volume at this scale. The headroom covers growth, the replication oplog, indexes, and the temporary space used during compaction and restore. The 10 GiB chart default suits only small or short-lived PoC environments.

Memory: Size MongoDB so the working set — frequently accessed documents plus indexes — fits in the WiredTiger cache. Provision to the 4 GiB limit rather than the 1 GiB request, and monitor cache pressure. Audit queries over a long window are what push it.

CPU: Provision to the 2 core limit rather than the 500m request. Steady-state load is low; the peaks are reporting queries, restores, and compaction.

Growth control: The 360-day expiry is fixed and not configurable. For longer retention, forward events to your SIEM. The in-database copy still expires at 360 days. See SIEM integration.

Note

These are planning figures for a typical workload of this size. Every environment is different, and some have a higher footprint. Use them for initial sizing, then monitor actual database size and growth during your PoC and in production, and adjust accordingly.

Smaller deployments

Environment	Estimated data	Provision
50 developers, 50 workspaces (PoC)	1–3 GB	At least 20 GiB
100 developers, 100 workspaces	2–6 GB	At least 20 GiB
500 developers, 500 workspaces	10–40 GB	At least 100 GiB

Environment

Estimated data

Provision

50 developers, 50 workspaces (PoC)

1–3 GB

At least 20 GiB

100 developers, 100 workspaces

2–6 GB

At least 20 GiB

500 developers, 500 workspaces

10–40 GB

At least 100 GiB

The 10 GiB chart default is enough only for a short-lived proof of concept. A pilot that runs for months accumulates audit data the whole time, and none of it expires until day 360 — so a proof of concept that starts comfortably inside 10 GiB can still outgrow it before anyone decides whether to buy. Provisioning 20 GiB from the start avoids resizing a volume mid-evaluation.

Note that storage does not scale with users in the way the data does. Most of the 20 GiB is headroom for the oplog, indexes, and the temporary space a restore needs, and those requirements barely change between 50 and 100 developers.

What retention actually bounds

Estimated footprint

Provisioning guidance

Smaller deployments

Related information

In this article