## Problem statement To achieve Organization Isolation, we need to attribute all customer data in the PG database to the correct Organization, directly or indirectly (project, namespace, organization,or user). We will also need all customer data to be sharded in order to be able to move an organization’s data to another cell. ## Exit criteria * [x] Shard or mitigate all of the [tables defined for Cohort A](https://docs.google.com/spreadsheets/d/1f4Vs4hMvjvfgKV0ekAetHB2-Ay9tJbAd4viu3NsCrl0/edit?gid=0#gid=0) ## Timeline Table sharding can take multiple milestones as batched background migrations require a [finalizing migration](https://docs.gitlab.com/development/database/batched_background_migrations/#finalize-a-batched-background-migration) after a required stop release version. In order to begin Protocells migrations "gameday" dry runs, we need all customer data sharded with migrations finalized. With gamedays currently planned for early FY27-Q1, our sharding timeline is: - `desired_sharding_key` must be set by 18.7 (i.e. included in the 18.7 release) - Backfill must be started in 18.7 - Backfills completed by end of 18.8 - Due date for finalization: 2 weeks before the end of 18.9 (on 2025-01-31) The impact of not sharding a table in this timeline would be potential delays to our current goal of starting Cohort 1 migration gamedays in early Q1 and executing the migrations in late Q1. We would have to spend time mitigating if possible. Even if we’re able to mitigate, our cohort size would be limited by unsharded tables. \* The work under this epic was also tracked as duplicate under https://gitlab.com/groups/gitlab-com/gl-infra/-/work_items/1757 ## DRI @tskorupa-gl ### Participants - @tskorupa-gl - @chen-gitlab - @tkuah <!-- STATUS NOTE START --> ## Status 2026-02-26 I will stop reporting on this epic as all [tables pertaining to cohort A](https://docs.google.com/spreadsheets/d/1f4Vs4hMvjvfgKV0ekAetHB2-Ay9tJbAd4viu3NsCrl0/edit?gid=0#gid=0) have been sharded or mitigated. I have yet to merge [one MR](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/218827) as part of this epic - although it's not preventing the table to be sharded. _Copied from https://gitlab.com/groups/gitlab-org/-/epics/11670#note_3114183699_ <!-- STATUS NOTE END -->