## Description We might be able to remove `ci_builds.trace` completely after we store this data somewhere in a safe place, if it is not stored in object storage already. The data was already migrated by https://gitlab.com/gitlab-com/gl-infra/reliability/-/issues/3658#note_63677251 and https://gitlab.com/gitlab-org/gitlab/-/commit/0d00d02e842a0c4b22d213e00143a08d97597000 The column removal needs to be done across [three releases](https://docs.gitlab.com/ee/development/database/avoiding_downtime_in_migrations.html#dropping-columns) to avoid downtime: ## Progress 1. Ignore the column - done in %15.4 - https://gitlab.com/gitlab-org/gitlab/-/merge_requests/96865 1. Drop the column from the database - done in %15.5 - https://gitlab.com/gitlab-org/gitlab/-/merge_requests/98646 1. Remove the ignore rule - in review %15.6 - https://gitlab.com/gitlab-org/gitlab/-/merge_requests/101744 ## Old content I did check on GitLab.com how much data is stored in `ci_builds.trace` column. This was used when GitLab CI was still separate product. We then moved to storing traces on disk. According to my queries, it is: ``` $ Ci::Build.where.not(trace: nil).count => 87636 $ Ci::Build.where.not(trace: nil).pluck('sum(octet_length(trace))') => [5608799010] ``` It is over 5.5GB, on average over 60k per build. We should prepare Background Migration to move that to disk.