Elementary does not currently provide a built-in lifecycle policy for managing the retention or automatic deletion of metadata stored in your S3 bucket or database. According to the available information, you are responsible for managing the growth and retention of these tables yourself. For example, you can delete old rows based on the created_at column to keep only the data you need for recent reports. However, be aware that the Elementary report relies on this metadata, so if you want to visualize data for the last X days, you must retain at least that much history in your storage. A practical approach is to implement an S3 lifecycle policy that expires objects older than your desired retention period (e.g., 30 or 60 days), ensuring you have enough data for your reporting needs but do not accumulate unnecessary historical data. This aligns with the advice to keep only the days you want to report on and delete older data as needed. There is no automated cleanup or retention management built into Elementary itself, so this must be handled externally via S3 lifecycle rules or scheduled cleanup jobs in your data warehouse, depending on where your metadata is stored. For more details, see the discussion on retention and manual cleanup in the documentation and community responses: [Elementary results lifecycle policy](https://slack.com/archives/C02CTC89LAX/p1689146074949549) and [Metadata cleanup options](https://slack.com/archives/C02CTC89LAX/p1687380949503199). In summary: - Set an S3 lifecycle policy to expire objects older than your reporting window (e.g., 30 days). - Ensure your retention period matches your reporting and visualization needs. - There is no built-in Elementary feature for this; it must be managed externally.

Having ~2 TB in each of the

dbt_run_results

and

dbt_invocations

tables after just one day is not typical based on the information available in the knowledge sources. While these tables are incremental and will grow as more runs are logged, most users report much smaller sizes, even after extended use. For example, one user with 806,350 rows in

elementary_test_results

was told this "doesn't sound a lot" and that the tables "shouldn't be that big," indicating that your observed size is unusually large and may point to an issue such as excessive logging, misconfiguration, or an unexpected volume of runs or tests being recorded [Community discussion on table size](https://slack.com/archives/C02CTC89LAX/p1674656787251049). If you are seeing such rapid growth, it is recommended to: - Check how many rows are in each table. - Review your dbt and Elementary configurations for anything that might be causing excessive data generation. - Consider whether you are running with a very high frequency or logging more detail than necessary. If this growth is unexpected, you may want to investigate further or reach out to Elementary support for help diagnosing the cause. The knowledge sources do not mention any scenario where 2 TB per table per day would be expected or normal.

Based on the knowledge sources, having only 5,626 rows in the

dbt_run_results

table but 2.5 TB and 133,286 objects in S3 is not normal or expected. There is no documentation or community report indicating that Elementary should generate such a large volume of S3 objects or data for this number of rows. A similar user case mentioned noticing hundreds of files for just a few megabytes of data in the

dbt_run_results

table and questioned if that was normal. The response from Elementary support was that this behavior was "pretty weird" and not something they had encountered before, and they suggested checking the number of rows in the table as a diagnostic step [Unexpected file count in dbt_run_results](https://slack.com/archives/C02CTC89LAX/p1693529286448229). Given your numbers, this suggests a possible misconfiguration, an issue with how data is being written to S3, or an underlying problem with the storage format or integration. This is not standard behavior for Elementary, and you should investigate further or reach out to Elementary support for assistance. Summary: - 5,626 rows should not result in 2.5 TB and 133,286 S3 objects. - This is not normal or expected based on available knowledge. - Further investigation is needed to identify the root cause.