## Problem `issue_search_data` is **227.49 GiB** on GitLab.com, growing **~9.4 GiB/30d** (2.8x its 365-day median), at ~**$209/month** and **3,184 GiB** with replicas. Advanced Search is assumed to serve issue search already, with this table a fallback for instances without Elasticsearch. That is wrong, and it is why the table grew unattended. ES serves the **global search page**; this table serves the **issues/work-items list `?search=` filter**, and the paths do not meet. Over 7 days of logs: - **2,225,967** issue-list requests carried `search`. **Zero** made an Elasticsearch call. - **142,088** global searches scoped to issues, **95.9%** served by Elasticsearch. The Postgres path carries roughly **15x** the volume of ES-served issue search. The cause is structural, not a rollout gap. `Search::AdvancedFinders::WorkItemsFinder` is a **filter and sort offload**: it sends ES a match-all and lets it evaluate labels, milestone, assignee, weight, state, dates and iids. Free-text `search` is absent from `ALLOWED_ES_FILTERS`, and that absence is not passive — `allowed_main_filters?` requires every non-control param to be in the list, so a request carrying `search=` disqualifies itself from the ES path. A full rollout of `work_items_list_es_integration` would not move one text search off this table. ## Why now 1. **Partition skew is approaching a hard limit.** The table is already hash-partitioned 64 ways on `project_id`, so "partition it" is spent. Hashing distributes projects, not issues, and one partition holds 18.7% of the table: `issue_search_data_29` is **42.55 GiB** against a **2.70 GiB** median, filled by one customer that created ~900k issues in five days. p29 grew **+3.37 GiB in 29 days**, roughly **7 months** from the 50 GB threshold above which an index needs an exception. 2. **The table is invisible to size governance.** `db/docs/issue_search_data.yml` says `table_size: small`; the rule classifies a partitioned table by its largest partition, so it should read `medium`. It was right until a housekeeper update demoted ~90 tables in March 2025 ([#526457](https://gitlab.com/gitlab-org/gitlab/-/issues/526457)). Siblings self-healed; this one cannot, because the keep scopes its query to `public`, where the partitioned parent holds zero bytes. So the table appears **nowhere** in `rubocop-migrations.yml`, and a migration adding an index to a 42 GiB partition passes the cop unchallenged. 3. **Two code paths already retreated from this table** because project partitioning cannot prune on a namespace hierarchy ([!219957](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/219957), [!142888](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/142888)), and group-level work items never had rows. ## Scope This epic covers making free-text issue search servable by Advanced Search, then reducing the table. It does not commit to dropping it. Each step gates the next: 1. **Restore size governance.** Correct the dictionary entry and register the table with the migration cop — small, and it stops a future index migration landing unnoticed on the hot partition. 2. **Complete the work-items advanced finder so it accepts free-text search.** `Search::AdvancedFinders::` is an established pattern: eleven sibling finders already serve lists from ES instead of Postgres — two for SBOM dependencies, nine for vulnerabilities — each building its query through a `Search::Elastic::*QueryBuilder` and returning a `Search::Elastic::Relation`. Work items has a member of that family, and it is the one that stops short of text. The gap is narrower than it looks. `Search::Elastic::WorkItemQueryBuilder` already supports free text — its `FIELDS` are `iid^50 title^2 description`. The finder never passes a term: it hardcodes `QUERY = '*'`, discarding a capability the builder has today. The work is plumbing the caller's term into that builder, adding `search` to the allowed filters, and closing one mapping gap — `title` is `text` with no keyword sub-field, so title sorting is impossible in ES (already a TODO in the finder). 3. **Measure storage composition** before proposing any shrink: heap/TOAST versus GIN index per partition, and the description-length distribution that sizes a truncation lever. Today's figures are directional. 4. **Then evaluate skipping the write for ES-served namespaces.** The largest saving available and the only genuine one-way door: a row never written costs a full backfill to recover. A product decision, not an implementation one. The gate is per namespace, not per offering, and there are two: the licensed `:elastic_search` feature, then a row in `elasticsearch_indexed_namespaces`, created on GitLab.com only for paid hosted plans — `free` is not in `PAID_HOSTED_PLANS`, and indexing rolls out by percentage even within a plan, so a paid namespace is not automatically indexed. One predicate serves GitLab.com and self-managed alike. Over 7 days **8.08%** of issue and work-item searches on GitLab.com came from the basic Postgres path — 17.2% at project level, 3.4% at group, near zero globally. **Entry criterion: measure what share of rows sit in ES-indexed namespaces.** Unmeasured, and it alone decides whether the step earns its risk — if rows from unindexed namespaces dominate, the work carries full reversibility cost for a fraction of the storage. Traffic share cannot answer it, since paid namespaces search more than they store; the query joins `elasticsearch_indexed_namespaces` to `issue_search_data` row counts and needs replica SQL. One signal to verify, not assume: the partition holding 18.7% of the table was filled by one high-volume tenant, likely paid and already indexed, putting the largest saving nearest the threshold. Three conditions first: the ES finder must already serve free text (step 2); read and write gating must agree per namespace, since divergence returns silently empty results rather than an error; and a rebuild path must exist for what makes rows necessary again — plan downgrade, indexing paused or rolled back, or an ES outage. The outage weighs most: list search degrades today when ES is down, but after pruning would return nothing. ## Out of scope - **Dropping the table or `search_vector`.** A two-milestone removal that takes a Free-tier capability from instances with no ES behind it. - **Re-partitioning by `namespace_id`** — see open questions. - **Zoekt** — it indexes code, not issue text. - **The upstream growth driver.** `issues` inserts stepped from ~92k/day to ~265k/day in late August and the ratio here is locked at 0.96–0.98, so this table is a strict dependent — that belongs to `issues`. ## Open questions 1. **Why did the `namespace_id` re-partition stop?** MR [!128010](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/128010) added and backfilled the column, stating it would become the new partitioning key. The column is populated, `db/structure.sql` still reads `PARTITION BY HASH (project_id)`, and no decision record was found. Resuming it would fix the skew and unblock group-level work items at once. Needs a Database team answer before the sequencing is final. 2. **Who owns the rollout?** The two flags routing list traffic to ES (`work_items_list_es_integration`, `glql_es_integration`) belong to other groups, so building the capability does not put it in front of users. The first is still `default_enabled: false`, and over 24h the work-item list operations made **zero** ES calls across 175,369 responses. ## Related - Growth anomaly, open with an accepted diagnosis, owned by `group::global_search`: https://gitlab.com/gitlab-com/gl-infra/capacity-planning-trackers/gitlab-com/-/work_items/3063. Earlier anomalies 2687, 2527 and 2227 there were each root-caused to one project. - [#600604](https://gitlab.com/gitlab-org/gitlab/-/work_items/600604) — autocomplete timed out scanning all 64 partitions; [!71913](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/71913) added the table in 14.9.