Code search and intelligence: repositories, code-intel uploads, batch changes, insights, permissions. The frontend database's squashed migrations. Domains here are by table-name prefix, not by judgment.
180 tables · 1715 columns · 362 foreign keys · 31 domains | 23 errors · 340 warnings · 294 notes
Generated from sourcegraph-public-snapshot@main.sql on 2026-09-05.
Conventions are claims. Findings below are where the schema breaks them.
Without a primary key rows are not individually addressable: no safe UPDATE/DELETE of one row, no logical replication, ORMs misbehave, and duplicates are legal.
Fix Add a natural composite key or a surrogate id.
ALTER TABLE codeintel_inference_scripts ADD PRIMARY KEY (...);
Without a primary key rows are not individually addressable: no safe UPDATE/DELETE of one row, no logical replication, ORMs misbehave, and duplicates are legal.
Fix Add a natural composite key or a surrogate id.
ALTER TABLE codeintel_langugage_support_requests ADD PRIMARY KEY (...);
Without a primary key rows are not individually addressable: no safe UPDATE/DELETE of one row, no logical replication, ORMs misbehave, and duplicates are legal.
Fix Add a natural composite key or a surrogate id.
ALTER TABLE configuration_policies_audit_logs ADD PRIMARY KEY (...);
Without a primary key rows are not individually addressable: no safe UPDATE/DELETE of one row, no logical replication, ORMs misbehave, and duplicates are legal.
Fix Add a natural composite key or a surrogate id.
ALTER TABLE external_service_repos ADD PRIMARY KEY (...);
Without a primary key rows are not individually addressable: no safe UPDATE/DELETE of one row, no logical replication, ORMs misbehave, and duplicates are legal.
Fix Add a natural composite key or a surrogate id.
ALTER TABLE external_service_sync_jobs ADD PRIMARY KEY (...);
Without a primary key rows are not individually addressable: no safe UPDATE/DELETE of one row, no logical replication, ORMs misbehave, and duplicates are legal.
Fix Add a natural composite key or a surrogate id.
ALTER TABLE feature_flag_overrides ADD PRIMARY KEY (...);
Without a primary key rows are not individually addressable: no safe UPDATE/DELETE of one row, no logical replication, ORMs misbehave, and duplicates are legal.
Fix Add a natural composite key or a surrogate id.
ALTER TABLE gitserver_repos_statistics ADD PRIMARY KEY (...);
Without a primary key rows are not individually addressable: no safe UPDATE/DELETE of one row, no logical replication, ORMs misbehave, and duplicates are legal.
Fix Add a natural composite key or a surrogate id.
ALTER TABLE insights_settings_migration_jobs ADD PRIMARY KEY (...);
Without a primary key rows are not individually addressable: no safe UPDATE/DELETE of one row, no logical replication, ORMs misbehave, and duplicates are legal.
Fix Add a natural composite key or a surrogate id.
ALTER TABLE lsif_nearest_uploads ADD PRIMARY KEY (...);
Without a primary key rows are not individually addressable: no safe UPDATE/DELETE of one row, no logical replication, ORMs misbehave, and duplicates are legal.
Fix Add a natural composite key or a surrogate id.
ALTER TABLE lsif_nearest_uploads_links ADD PRIMARY KEY (...);
Without a primary key rows are not individually addressable: no safe UPDATE/DELETE of one row, no logical replication, ORMs misbehave, and duplicates are legal.
Fix Add a natural composite key or a surrogate id.
ALTER TABLE lsif_uploads_audit_logs ADD PRIMARY KEY (...);
Without a primary key rows are not individually addressable: no safe UPDATE/DELETE of one row, no logical replication, ORMs misbehave, and duplicates are legal.
Fix Add a natural composite key or a surrogate id.
ALTER TABLE lsif_uploads_reference_counts ADD PRIMARY KEY (...);
Without a primary key rows are not individually addressable: no safe UPDATE/DELETE of one row, no logical replication, ORMs misbehave, and duplicates are legal.
Fix Add a natural composite key or a surrogate id.
ALTER TABLE lsif_uploads_visible_at_tip ADD PRIMARY KEY (...);
Without a primary key rows are not individually addressable: no safe UPDATE/DELETE of one row, no logical replication, ORMs misbehave, and duplicates are legal.
Fix Add a natural composite key or a surrogate id.
ALTER TABLE query_runner_state ADD PRIMARY KEY (...);
Without a primary key rows are not individually addressable: no safe UPDATE/DELETE of one row, no logical replication, ORMs misbehave, and duplicates are legal.
Fix Add a natural composite key or a surrogate id.
ALTER TABLE repo_pending_permissions ADD PRIMARY KEY (...);
Without a primary key rows are not individually addressable: no safe UPDATE/DELETE of one row, no logical replication, ORMs misbehave, and duplicates are legal.
Fix Add a natural composite key or a surrogate id.
ALTER TABLE repo_permissions ADD PRIMARY KEY (...);
Without a primary key rows are not individually addressable: no safe UPDATE/DELETE of one row, no logical replication, ORMs misbehave, and duplicates are legal.
Fix Add a natural composite key or a surrogate id.
ALTER TABLE repo_statistics ADD PRIMARY KEY (...);
Without a primary key rows are not individually addressable: no safe UPDATE/DELETE of one row, no logical replication, ORMs misbehave, and duplicates are legal.
Fix Add a natural composite key or a surrogate id.
ALTER TABLE search_context_repos ADD PRIMARY KEY (...);
Without a primary key rows are not individually addressable: no safe UPDATE/DELETE of one row, no logical replication, ORMs misbehave, and duplicates are legal.
Fix Add a natural composite key or a surrogate id.
ALTER TABLE sub_repo_permissions ADD PRIMARY KEY (...);
Without a primary key rows are not individually addressable: no safe UPDATE/DELETE of one row, no logical replication, ORMs misbehave, and duplicates are legal.
Fix Add a natural composite key or a surrogate id.
ALTER TABLE user_emails ADD PRIMARY KEY (...);
Without a primary key rows are not individually addressable: no safe UPDATE/DELETE of one row, no logical replication, ORMs misbehave, and duplicates are legal.
Fix Add a natural composite key or a surrogate id.
ALTER TABLE user_pending_permissions ADD PRIMARY KEY (...);
Without a primary key rows are not individually addressable: no safe UPDATE/DELETE of one row, no logical replication, ORMs misbehave, and duplicates are legal.
Fix Add a natural composite key or a surrogate id.
ALTER TABLE user_permissions ADD PRIMARY KEY (...);
Without a primary key rows are not individually addressable: no safe UPDATE/DELETE of one row, no logical replication, ORMs misbehave, and duplicates are legal.
Fix Add a natural composite key or a surrogate id.
ALTER TABLE user_public_repos ADD PRIMARY KEY (...);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan access_requests to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to access_requests maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. decision_by_user_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_access_requests_decision_by_user_id ON access_requests(decision_by_user_id) WHERE decision_by_user_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan access_requests to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to access_requests maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_access_requests_tenant_id ON access_requests(tenant_id) WHERE tenant_id IS NOT NULL;
status is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE access_requests ADD CONSTRAINT access_requests_status_check CHECK (status IN (...));
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan access_tokens to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to access_tokens maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_access_tokens_creator_user_id ON access_tokens(creator_user_id);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan access_tokens to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to access_tokens maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_access_tokens_subject_user_id ON access_tokens(subject_user_id);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan access_tokens to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to access_tokens maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_access_tokens_tenant_id ON access_tokens(tenant_id) WHERE tenant_id IS NOT NULL;
access_tokens soft-deletes via deleted_at, but (value_sha256) is unique across live AND deleted rows. A user who deletes their account can never sign up again with the same value, and ON CONFLICT upserts will resurrect ghosts.
Fix Replace with a partial unique index scoped to live rows.
DROP CONSTRAINT/INDEX ...; CREATE UNIQUE INDEX access_tokens_value_sha256_live ON access_tokens(value_sha256) WHERE deleted_at IS NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan aggregated_user_statistics to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to aggregated_user_statistics maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_aggregated_user_statistics_tenant_id ON aggregated_user_statistics(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan assigned_owners to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to assigned_owners maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_assigned_owners_owner_user_id ON assigned_owners(owner_user_id);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan assigned_owners to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to assigned_owners maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_assigned_owners_tenant_id ON assigned_owners(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan assigned_owners to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to assigned_owners maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. who_assigned_user_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_assigned_owners_who_assigned_user_id ON assigned_owners(who_assigned_user_id) WHERE who_assigned_user_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on teams must scan assigned_teams to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to assigned_teams maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often teams rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_assigned_teams_owner_team_id ON assigned_teams(owner_team_id);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan assigned_teams to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to assigned_teams maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_assigned_teams_tenant_id ON assigned_teams(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan assigned_teams to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to assigned_teams maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. who_assigned_team_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_assigned_teams_who_assigned_team_id ON assigned_teams(who_assigned_team_id) WHERE who_assigned_team_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on batch_specs must scan batch_changes to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to batch_changes maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often batch_specs rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_batch_changes_batch_spec_id ON batch_changes(batch_spec_id);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan batch_changes to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to batch_changes maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. creator_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_batch_changes_creator_id ON batch_changes(creator_id) WHERE creator_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan batch_changes to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to batch_changes maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. last_applier_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_batch_changes_last_applier_id ON batch_changes(last_applier_id) WHERE last_applier_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan batch_changes to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to batch_changes maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_batch_changes_tenant_id ON batch_changes(tenant_id) WHERE tenant_id IS NOT NULL;
batch_changes → batch_specs → batch_changes. Rows must be inserted with a deferred constraint or a NULL-then-update dance; backups/restores and truncation have no valid order; ON DELETE CASCADE can loop.
Fix Break the cycle (move one FK to a link table) or mark one FK DEFERRABLE INITIALLY DEFERRED.
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on github_apps must scan batch_changes_site_credentials to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to batch_changes_site_credentials maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often github_apps rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. github_app_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_batch_changes_site_credentials_github_app_id ON batch_changes_site_credentials(github_app_id) WHERE github_app_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan batch_changes_site_credentials to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to batch_changes_site_credentials maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_batch_changes_site_credentials_tenant_id ON batch_changes_site_credentials(tenant_id) WHERE tenant_id IS NOT NULL;
external_service_type is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE batch_changes_site_credentials ADD CONSTRAINT batch_changes_site_credentials_external_service_type_check CHECK (external_service_type IN (...));
external_service_id points at different tables depending on external_service_type. No FK can express that, so orphans accumulate silently and every join needs a CASE. Acceptable for append-only audit data; painful anywhere the target must still exist.
Fix Either one nullable FK per target with a CHECK that exactly one is set, or a supertype table that the targets reference.
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan batch_spec_execution_cache_entries to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to batch_spec_execution_cache_entries maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_batch_spec_execution_cache_entries_tenant_id ON batch_spec_execution_cache_entries(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan batch_spec_resolution_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to batch_spec_resolution_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_batch_spec_resolution_jobs_initiator_id ON batch_spec_resolution_jobs(initiator_id);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan batch_spec_resolution_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to batch_spec_resolution_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_batch_spec_resolution_jobs_tenant_id ON batch_spec_resolution_jobs(tenant_id) WHERE tenant_id IS NOT NULL;
state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE batch_spec_resolution_jobs ADD CONSTRAINT batch_spec_resolution_jobs_state_check CHECK (state IN (...));
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan batch_spec_workspace_execution_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to batch_spec_workspace_execution_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_batch_spec_workspace_execution_jobs_tenant_id ON batch_spec_workspace_execution_jobs(tenant_id) WHERE tenant_id IS NOT NULL;
state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE batch_spec_workspace_execution_jobs ADD CONSTRAINT batch_spec_workspace_execution_jobs_state_check CHECK (state IN (...));
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan batch_spec_workspace_execution_last_dequeues to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to batch_spec_workspace_execution_last_dequeues maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_batch_spec_workspace_execution_last_dequeues_tenant_id ON batch_spec_workspace_execution_last_dequeues(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan batch_spec_workspace_files to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to batch_spec_workspace_files maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_batch_spec_workspace_files_tenant_id ON batch_spec_workspace_files(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on repo must scan batch_spec_workspaces to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to batch_spec_workspaces maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often repo rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_batch_spec_workspaces_repo_id ON batch_spec_workspaces(repo_id);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan batch_spec_workspaces to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to batch_spec_workspaces maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_batch_spec_workspaces_tenant_id ON batch_spec_workspaces(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on batch_changes must scan batch_specs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to batch_specs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often batch_changes rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. batch_change_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_batch_specs_batch_change_id ON batch_specs(batch_change_id) WHERE batch_change_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan batch_specs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to batch_specs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_batch_specs_tenant_id ON batch_specs(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan batch_specs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to batch_specs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. user_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_batch_specs_user_id ON batch_specs(user_id) WHERE user_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan cached_available_indexers to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cached_available_indexers maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_cached_available_indexers_tenant_id ON cached_available_indexers(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan changeset_events to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to changeset_events maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_changeset_events_tenant_id ON changeset_events(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on batch_changes must scan changeset_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to changeset_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often batch_changes rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_changeset_jobs_batch_change_id ON changeset_jobs(batch_change_id);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on changesets must scan changeset_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to changeset_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often changesets rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_changeset_jobs_changeset_id ON changeset_jobs(changeset_id);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan changeset_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to changeset_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_changeset_jobs_tenant_id ON changeset_jobs(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan changeset_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to changeset_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_changeset_jobs_user_id ON changeset_jobs(user_id);
job_type is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE changeset_jobs ADD CONSTRAINT changeset_jobs_job_type_check CHECK (job_type IN (...));
state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE changeset_jobs ADD CONSTRAINT changeset_jobs_state_check CHECK (state IN (...));
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on repo must scan changeset_specs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to changeset_specs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often repo rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_changeset_specs_repo_id ON changeset_specs(repo_id);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan changeset_specs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to changeset_specs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_changeset_specs_tenant_id ON changeset_specs(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan changeset_specs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to changeset_specs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. user_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_changeset_specs_user_id ON changeset_specs(user_id) WHERE user_id IS NOT NULL;
type is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE changeset_specs ADD CONSTRAINT changeset_specs_type_check CHECK (type IN (...));
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on batch_changes must scan changesets to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to changesets maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often batch_changes rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. owned_by_batch_change_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_changesets_owned_by_batch_change_id ON changesets(owned_by_batch_change_id) WHERE owned_by_batch_change_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on changeset_specs must scan changesets to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to changesets maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often changeset_specs rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. previous_spec_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_changesets_previous_spec_id ON changesets(previous_spec_id) WHERE previous_spec_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan changesets to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to changesets maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_changesets_tenant_id ON changesets(tenant_id) WHERE tenant_id IS NOT NULL;
external_state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE changesets ADD CONSTRAINT changesets_external_state_check CHECK (external_state IN (...));
external_review_state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE changesets ADD CONSTRAINT changesets_external_review_state_check CHECK (external_review_state IN (...));
external_check_state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE changesets ADD CONSTRAINT changesets_external_check_state_check CHECK (external_check_state IN (...));
publication_state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE changesets ADD CONSTRAINT changesets_publication_state_check CHECK (publication_state IN (...));
reconciler_state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE changesets ADD CONSTRAINT changesets_reconciler_state_check CHECK (reconciler_state IN (...));
computed_state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE changesets ADD CONSTRAINT changesets_computed_state_check CHECK (computed_state IN (...));
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on cm_emails must scan cm_action_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_action_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often cm_emails rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. email is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_cm_action_jobs_email ON cm_action_jobs(email) WHERE email IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on cm_slack_webhooks must scan cm_action_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_action_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often cm_slack_webhooks rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. slack_webhook is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_cm_action_jobs_slack_webhook ON cm_action_jobs(slack_webhook) WHERE slack_webhook IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan cm_action_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_action_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_cm_action_jobs_tenant_id ON cm_action_jobs(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on cm_webhooks must scan cm_action_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_action_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often cm_webhooks rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. webhook is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_cm_action_jobs_webhook ON cm_action_jobs(webhook) WHERE webhook IS NOT NULL;
state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE cm_action_jobs ADD CONSTRAINT cm_action_jobs_state_check CHECK (state IN (...));
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan cm_emails to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_emails maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_cm_emails_changed_by ON cm_emails(changed_by);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan cm_emails to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_emails maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_cm_emails_created_by ON cm_emails(created_by);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on cm_monitors must scan cm_emails to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_emails maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often cm_monitors rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_cm_emails_monitor ON cm_emails(monitor);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan cm_emails to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_emails maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_cm_emails_tenant_id ON cm_emails(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on repo must scan cm_last_searched to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_last_searched maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often repo rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_cm_last_searched_repo_id ON cm_last_searched(repo_id);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan cm_last_searched to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_last_searched maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_cm_last_searched_tenant_id ON cm_last_searched(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan cm_monitors to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_monitors maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_cm_monitors_changed_by ON cm_monitors(changed_by);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan cm_monitors to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_monitors maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_cm_monitors_created_by ON cm_monitors(created_by);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on orgs must scan cm_monitors to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_monitors maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often orgs rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. namespace_org_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_cm_monitors_namespace_org_id ON cm_monitors(namespace_org_id) WHERE namespace_org_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan cm_monitors to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_monitors maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_cm_monitors_tenant_id ON cm_monitors(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan cm_monitors to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_monitors maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_cm_monitors_namespace_user_id ON cm_monitors(namespace_user_id);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan cm_queries to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_queries maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_cm_queries_tenant_id ON cm_queries(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan cm_queries to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_queries maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_cm_queries_changed_by ON cm_queries(changed_by);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan cm_queries to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_queries maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_cm_queries_created_by ON cm_queries(created_by);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on cm_monitors must scan cm_queries to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_queries maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often cm_monitors rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_cm_queries_monitor ON cm_queries(monitor);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on cm_emails must scan cm_recipients to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_recipients maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often cm_emails rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_cm_recipients_email ON cm_recipients(email);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on orgs must scan cm_recipients to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_recipients maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often orgs rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. namespace_org_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_cm_recipients_namespace_org_id ON cm_recipients(namespace_org_id) WHERE namespace_org_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan cm_recipients to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_recipients maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_cm_recipients_tenant_id ON cm_recipients(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan cm_recipients to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_recipients maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. namespace_user_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_cm_recipients_namespace_user_id ON cm_recipients(namespace_user_id) WHERE namespace_user_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan cm_slack_webhooks to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_slack_webhooks maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_cm_slack_webhooks_changed_by ON cm_slack_webhooks(changed_by);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan cm_slack_webhooks to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_slack_webhooks maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_cm_slack_webhooks_created_by ON cm_slack_webhooks(created_by);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan cm_slack_webhooks to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_slack_webhooks maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_cm_slack_webhooks_tenant_id ON cm_slack_webhooks(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on cm_queries must scan cm_trigger_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_trigger_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often cm_queries rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_cm_trigger_jobs_query ON cm_trigger_jobs(query);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan cm_trigger_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_trigger_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_cm_trigger_jobs_tenant_id ON cm_trigger_jobs(tenant_id) WHERE tenant_id IS NOT NULL;
state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE cm_trigger_jobs ADD CONSTRAINT cm_trigger_jobs_state_check CHECK (state IN (...));
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan cm_webhooks to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_webhooks maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_cm_webhooks_changed_by ON cm_webhooks(changed_by);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan cm_webhooks to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_webhooks maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_cm_webhooks_created_by ON cm_webhooks(created_by);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan cm_webhooks to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_webhooks maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_cm_webhooks_tenant_id ON cm_webhooks(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan code_hosts to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to code_hosts maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_code_hosts_tenant_id ON code_hosts(tenant_id) WHERE tenant_id IS NOT NULL;
kind is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE code_hosts ADD CONSTRAINT code_hosts_kind_check CHECK (kind IN (...));
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan codeintel_autoindex_queue to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to codeintel_autoindex_queue maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_codeintel_autoindex_queue_tenant_id ON codeintel_autoindex_queue(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan codeintel_autoindexing_exceptions to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to codeintel_autoindexing_exceptions maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_codeintel_autoindexing_exceptions_tenant_id ON codeintel_autoindexing_exceptions(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan codeintel_commit_dates to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to codeintel_commit_dates maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_codeintel_commit_dates_tenant_id ON codeintel_commit_dates(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan codeintel_inference_scripts to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to codeintel_inference_scripts maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_codeintel_inference_scripts_tenant_id ON codeintel_inference_scripts(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan codeintel_initial_path_ranks to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to codeintel_initial_path_ranks maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_codeintel_initial_path_ranks_tenant_id ON codeintel_initial_path_ranks(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan codeintel_initial_path_ranks_processed to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to codeintel_initial_path_ranks_processed maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_codeintel_initial_path_ranks_processed_tenant_id ON codeintel_initial_path_ranks_processed(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan codeintel_langugage_support_requests to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to codeintel_langugage_support_requests maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_codeintel_langugage_support_requests_tenant_id ON codeintel_langugage_support_requests(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan codeintel_path_ranks to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to codeintel_path_ranks maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_codeintel_path_ranks_tenant_id ON codeintel_path_ranks(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan codeintel_ranking_definitions to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to codeintel_ranking_definitions maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_codeintel_ranking_definitions_tenant_id ON codeintel_ranking_definitions(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan codeintel_ranking_exports to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to codeintel_ranking_exports maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_codeintel_ranking_exports_tenant_id ON codeintel_ranking_exports(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on lsif_uploads must scan codeintel_ranking_exports to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to codeintel_ranking_exports maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often lsif_uploads rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. upload_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_codeintel_ranking_exports_upload_id ON codeintel_ranking_exports(upload_id) WHERE upload_id IS NOT NULL;
codeintel_ranking_exports soft-deletes via deleted_at, but (graph_key, upload_id) is unique across live AND deleted rows. A user who deletes their account can never sign up again with the same value, and ON CONFLICT upserts will resurrect ghosts.
Fix Replace with a partial unique index scoped to live rows.
DROP CONSTRAINT/INDEX ...; CREATE UNIQUE INDEX codeintel_ranking_exports_graph_key_upload_id_live ON codeintel_ranking_exports(graph_key, upload_id) WHERE deleted_at IS NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan codeintel_ranking_graph_keys to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to codeintel_ranking_graph_keys maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_codeintel_ranking_graph_keys_tenant_id ON codeintel_ranking_graph_keys(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan codeintel_ranking_path_counts_inputs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to codeintel_ranking_path_counts_inputs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_codeintel_ranking_path_counts_inputs_tenant_id ON codeintel_ranking_path_counts_inputs(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan codeintel_ranking_progress to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to codeintel_ranking_progress maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_codeintel_ranking_progress_tenant_id ON codeintel_ranking_progress(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan codeintel_ranking_references to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to codeintel_ranking_references maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_codeintel_ranking_references_tenant_id ON codeintel_ranking_references(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan codeintel_ranking_references_processed to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to codeintel_ranking_references_processed maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_codeintel_ranking_references_processed_tenant_id ON codeintel_ranking_references_processed(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan codeowners to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to codeowners maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_codeowners_tenant_id ON codeowners(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on codeowners_owners must scan codeowners_individual_stats to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to codeowners_individual_stats maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often codeowners_owners rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_codeowners_individual_stats_owner_id ON codeowners_individual_stats(owner_id);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan codeowners_individual_stats to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to codeowners_individual_stats maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_codeowners_individual_stats_tenant_id ON codeowners_individual_stats(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan codeowners_owners to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to codeowners_owners maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_codeowners_owners_tenant_id ON codeowners_owners(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan commit_authors to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to commit_authors maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_commit_authors_tenant_id ON commit_authors(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan configuration_policies_audit_logs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to configuration_policies_audit_logs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_configuration_policies_audit_logs_tenant_id ON configuration_policies_audit_logs(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan context_detection_embedding_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to context_detection_embedding_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_context_detection_embedding_jobs_tenant_id ON context_detection_embedding_jobs(tenant_id) WHERE tenant_id IS NOT NULL;
state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE context_detection_embedding_jobs ADD CONSTRAINT context_detection_embedding_jobs_state_check CHECK (state IN (...));
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan discussion_comments to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to discussion_comments maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_discussion_comments_tenant_id ON discussion_comments(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan discussion_mail_reply_tokens to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to discussion_mail_reply_tokens maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_discussion_mail_reply_tokens_tenant_id ON discussion_mail_reply_tokens(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on discussion_threads must scan discussion_mail_reply_tokens to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to discussion_mail_reply_tokens maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often discussion_threads rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_discussion_mail_reply_tokens_thread_id ON discussion_mail_reply_tokens(thread_id);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on discussion_threads_target_repo must scan discussion_threads to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to discussion_threads maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often discussion_threads_target_repo rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. target_repo_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_discussion_threads_target_repo_id ON discussion_threads(target_repo_id) WHERE target_repo_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan discussion_threads to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to discussion_threads maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_discussion_threads_tenant_id ON discussion_threads(tenant_id) WHERE tenant_id IS NOT NULL;
discussion_threads → discussion_threads_target_repo → discussion_threads. Rows must be inserted with a deferred constraint or a NULL-then-update dance; backups/restores and truncation have no valid order; ON DELETE CASCADE can loop.
Fix Break the cycle (move one FK to a link table) or mark one FK DEFERRABLE INITIALLY DEFERRED.
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan discussion_threads_target_repo to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to discussion_threads_target_repo maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_discussion_threads_target_repo_tenant_id ON discussion_threads_target_repo(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on discussion_threads must scan discussion_threads_target_repo to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to discussion_threads_target_repo maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often discussion_threads rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_discussion_threads_target_repo_thread_id ON discussion_threads_target_repo(thread_id);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan event_logs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to event_logs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_event_logs_tenant_id ON event_logs(tenant_id) WHERE tenant_id IS NOT NULL;
billing_product_category is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE event_logs ADD CONSTRAINT event_logs_billing_product_category_check CHECK (billing_product_category IN (...));
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan event_logs_export_allowlist to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to event_logs_export_allowlist maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_event_logs_export_allowlist_tenant_id ON event_logs_export_allowlist(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan event_logs_scrape_state to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to event_logs_scrape_state maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_event_logs_scrape_state_tenant_id ON event_logs_scrape_state(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan event_logs_scrape_state_own to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to event_logs_scrape_state_own maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_event_logs_scrape_state_own_tenant_id ON event_logs_scrape_state_own(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan executor_heartbeats to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to executor_heartbeats maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_executor_heartbeats_tenant_id ON executor_heartbeats(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan executor_job_tokens to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to executor_job_tokens maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_executor_job_tokens_tenant_id ON executor_job_tokens(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on executor_secrets must scan executor_secret_access_logs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to executor_secret_access_logs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often executor_secrets rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_executor_secret_access_logs_executor_secret_id ON executor_secret_access_logs(executor_secret_id);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan executor_secret_access_logs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to executor_secret_access_logs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_executor_secret_access_logs_tenant_id ON executor_secret_access_logs(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan executor_secret_access_logs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to executor_secret_access_logs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. user_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_executor_secret_access_logs_user_id ON executor_secret_access_logs(user_id) WHERE user_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan executor_secrets to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to executor_secrets maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. creator_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_executor_secrets_creator_id ON executor_secrets(creator_id) WHERE creator_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on orgs must scan executor_secrets to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to executor_secrets maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often orgs rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. namespace_org_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_executor_secrets_namespace_org_id ON executor_secrets(namespace_org_id) WHERE namespace_org_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan executor_secrets to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to executor_secrets maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. namespace_user_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_executor_secrets_namespace_user_id ON executor_secrets(namespace_user_id) WHERE namespace_user_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan executor_secrets to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to executor_secrets maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_executor_secrets_tenant_id ON executor_secrets(tenant_id) WHERE tenant_id IS NOT NULL;
scope is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE executor_secrets ADD CONSTRAINT executor_secrets_scope_check CHECK (scope IN (...));
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan exhaustive_search_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to exhaustive_search_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_exhaustive_search_jobs_initiator_id ON exhaustive_search_jobs(initiator_id);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan exhaustive_search_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to exhaustive_search_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_exhaustive_search_jobs_tenant_id ON exhaustive_search_jobs(tenant_id) WHERE tenant_id IS NOT NULL;
state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE exhaustive_search_jobs ADD CONSTRAINT exhaustive_search_jobs_state_check CHECK (state IN (...));
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on repo must scan exhaustive_search_repo_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to exhaustive_search_repo_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often repo rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_exhaustive_search_repo_jobs_repo_id ON exhaustive_search_repo_jobs(repo_id);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on exhaustive_search_jobs must scan exhaustive_search_repo_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to exhaustive_search_repo_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often exhaustive_search_jobs rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_exhaustive_search_repo_jobs_search_job_id ON exhaustive_search_repo_jobs(search_job_id);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan exhaustive_search_repo_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to exhaustive_search_repo_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_exhaustive_search_repo_jobs_tenant_id ON exhaustive_search_repo_jobs(tenant_id) WHERE tenant_id IS NOT NULL;
state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE exhaustive_search_repo_jobs ADD CONSTRAINT exhaustive_search_repo_jobs_state_check CHECK (state IN (...));
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on exhaustive_search_repo_jobs must scan exhaustive_search_repo_revision_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to exhaustive_search_repo_revision_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often exhaustive_search_repo_jobs rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_exhaustive_search_repo_revision_jobs_search_repo_job_id ON exhaustive_search_repo_revision_jobs(search_repo_job_id);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan exhaustive_search_repo_revision_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to exhaustive_search_repo_revision_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_exhaustive_search_repo_revision_jobs_tenant_id ON exhaustive_search_repo_revision_jobs(tenant_id) WHERE tenant_id IS NOT NULL;
state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE exhaustive_search_repo_revision_jobs ADD CONSTRAINT exhaustive_search_repo_revision_jobs_state_check CHECK (state IN (...));
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan explicit_permissions_bitbucket_projects_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to explicit_permissions_bitbucket_projects_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_explicit_permissions_bitbucket_projects_jobs_tenant_id ON explicit_permissions_bitbucket_projects_jobs(tenant_id) WHERE tenant_id IS NOT NULL;
state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE explicit_permissions_bitbucket_projects_jobs ADD CONSTRAINT explicit_permissions_bitbucket_projects_jobs_state_check CHECK (state IN (...));
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan external_service_repos to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to external_service_repos maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_external_service_repos_tenant_id ON external_service_repos(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan external_service_sync_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to external_service_sync_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_external_service_sync_jobs_tenant_id ON external_service_sync_jobs(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on external_services must scan external_service_sync_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to external_service_sync_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often external_services rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_external_service_sync_jobs_external_service_id ON external_service_sync_jobs(external_service_id);
state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE external_service_sync_jobs ADD CONSTRAINT external_service_sync_jobs_state_check CHECK (state IN (...));
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on code_hosts must scan external_services to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to external_services maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often code_hosts rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. code_host_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_external_services_code_host_id ON external_services(code_host_id) WHERE code_host_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan external_services to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to external_services maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. creator_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_external_services_creator_id ON external_services(creator_id) WHERE creator_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan external_services to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to external_services maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. last_updater_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_external_services_last_updater_id ON external_services(last_updater_id) WHERE last_updater_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan external_services to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to external_services maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_external_services_tenant_id ON external_services(tenant_id) WHERE tenant_id IS NOT NULL;
kind is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE external_services ADD CONSTRAINT external_services_kind_check CHECK (kind IN (...));
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan feature_flag_overrides to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to feature_flag_overrides maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_feature_flag_overrides_tenant_id ON feature_flag_overrides(tenant_id) WHERE tenant_id IS NOT NULL;
feature_flag_overrides soft-deletes via deleted_at, but (namespace_org_id, flag_name) is unique across live AND deleted rows. A user who deletes their account can never sign up again with the same value, and ON CONFLICT upserts will resurrect ghosts.
Fix Replace with a partial unique index scoped to live rows.
DROP CONSTRAINT/INDEX ...; CREATE UNIQUE INDEX feature_flag_overrides_namespace_org_id_flag_name_live ON feature_flag_overrides(namespace_org_id, flag_name) WHERE deleted_at IS NULL;
feature_flag_overrides soft-deletes via deleted_at, but (namespace_user_id, flag_name) is unique across live AND deleted rows. A user who deletes their account can never sign up again with the same value, and ON CONFLICT upserts will resurrect ghosts.
Fix Replace with a partial unique index scoped to live rows.
DROP CONSTRAINT/INDEX ...; CREATE UNIQUE INDEX feature_flag_overrides_namespace_user_id_flag_name_live ON feature_flag_overrides(namespace_user_id, flag_name) WHERE deleted_at IS NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan feature_flags to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to feature_flags maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_feature_flags_tenant_id ON feature_flags(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan github_app_installs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to github_app_installs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_github_app_installs_tenant_id ON github_app_installs(tenant_id) WHERE tenant_id IS NOT NULL;
account_type is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE github_app_installs ADD CONSTRAINT github_app_installs_account_type_check CHECK (account_type IN (...));
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan github_apps to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to github_apps maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_github_apps_tenant_id ON github_apps(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on webhooks must scan github_apps to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to github_apps maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often webhooks rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. webhook_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_github_apps_webhook_id ON github_apps(webhook_id) WHERE webhook_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan gitserver_relocator_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to gitserver_relocator_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_gitserver_relocator_jobs_tenant_id ON gitserver_relocator_jobs(tenant_id) WHERE tenant_id IS NOT NULL;
state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE gitserver_relocator_jobs ADD CONSTRAINT gitserver_relocator_jobs_state_check CHECK (state IN (...));
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan gitserver_repos to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to gitserver_repos maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_gitserver_repos_tenant_id ON gitserver_repos(tenant_id) WHERE tenant_id IS NOT NULL;
clone_status is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE gitserver_repos ADD CONSTRAINT gitserver_repos_clone_status_check CHECK (clone_status IN (...));
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan gitserver_repos_statistics to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to gitserver_repos_statistics maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_gitserver_repos_statistics_tenant_id ON gitserver_repos_statistics(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan gitserver_repos_sync_output to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to gitserver_repos_sync_output maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_gitserver_repos_sync_output_tenant_id ON gitserver_repos_sync_output(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan global_state to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to global_state maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_global_state_tenant_id ON global_state(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan insights_query_runner_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to insights_query_runner_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_insights_query_runner_jobs_tenant_id ON insights_query_runner_jobs(tenant_id) WHERE tenant_id IS NOT NULL;
state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE insights_query_runner_jobs ADD CONSTRAINT insights_query_runner_jobs_state_check CHECK (state IN (...));
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan insights_query_runner_jobs_dependencies to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to insights_query_runner_jobs_dependencies maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_insights_query_runner_jobs_dependencies_tenant_id ON insights_query_runner_jobs_dependencies(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan insights_settings_migration_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to insights_settings_migration_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_insights_settings_migration_jobs_tenant_id ON insights_settings_migration_jobs(tenant_id) WHERE tenant_id IS NOT NULL;
type is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code. The comment lists The type of Git object (e.g., COMMIT, BRANCH, TAG)., i.e. the values are known.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE lsif_configuration_policies ADD CONSTRAINT lsif_configuration_policies_type_check CHECK (type IN (...));
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on lsif_uploads must scan lsif_dependency_indexing_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to lsif_dependency_indexing_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often lsif_uploads rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. upload_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_lsif_dependency_indexing_jobs_upload_id ON lsif_dependency_indexing_jobs(upload_id) WHERE upload_id IS NOT NULL;
state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE lsif_dependency_indexing_jobs ADD CONSTRAINT lsif_dependency_indexing_jobs_state_check CHECK (state IN (...));
external_service_kind is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code. The comment lists Filter the external services for this kind to wait to have synced. If empty, external_service_sync is ignored and no external services are polled for their last sync time., i.e. the values are known.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE lsif_dependency_indexing_jobs ADD CONSTRAINT lsif_dependency_indexing_jobs_external_service_kind_check CHECK (external_service_kind IN (...));
state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE lsif_dependency_syncing_jobs ADD CONSTRAINT lsif_dependency_syncing_jobs_state_check CHECK (state IN (...));
state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE lsif_indexes ADD CONSTRAINT lsif_indexes_state_check CHECK (state IN (...));
state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE lsif_uploads ADD CONSTRAINT lsif_uploads_state_check CHECK (state IN (...));
content_type is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code. The comment lists The content type of the upload record. For now, the default value is application/x-ndjson+lsif to backfill existing records. This will change as we remove LSIF support., i.e. the values are known.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE lsif_uploads ADD CONSTRAINT lsif_uploads_content_type_check CHECK (content_type IN (...));
content_type is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE lsif_uploads_audit_logs ADD CONSTRAINT lsif_uploads_audit_logs_content_type_check CHECK (content_type IN (...));
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on orgs must scan names to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to names maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often orgs rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. org_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_names_org_id ON names(org_id) WHERE org_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on teams must scan names to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to names maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often teams rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. team_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_names_team_id ON names(team_id) WHERE team_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan names to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to names maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_names_tenant_id ON names(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan names to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to names maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. user_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_names_user_id ON names(user_id) WHERE user_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan namespace_permissions to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to namespace_permissions maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_namespace_permissions_tenant_id ON namespace_permissions(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan namespace_permissions to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to namespace_permissions maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_namespace_permissions_user_id ON namespace_permissions(user_id);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan notebook_stars to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to notebook_stars maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_notebook_stars_tenant_id ON notebook_stars(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan notebooks to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to notebooks maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. creator_user_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_notebooks_creator_user_id ON notebooks(creator_user_id) WHERE creator_user_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan notebooks to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to notebooks maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_notebooks_tenant_id ON notebooks(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan notebooks to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to notebooks maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. updater_user_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_notebooks_updater_user_id ON notebooks(updater_user_id) WHERE updater_user_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan org_invitations to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to org_invitations maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_org_invitations_sender_user_id ON org_invitations(sender_user_id);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan org_invitations to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to org_invitations maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_org_invitations_tenant_id ON org_invitations(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan org_members to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to org_members maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_org_members_tenant_id ON org_members(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan org_members to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to org_members maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_org_members_user_id ON org_members(user_id);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan org_stats to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to org_stats maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_org_stats_tenant_id ON org_stats(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan orgs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to orgs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_orgs_tenant_id ON orgs(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan orgs_open_beta_stats to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to orgs_open_beta_stats maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_orgs_open_beta_stats_tenant_id ON orgs_open_beta_stats(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan out_of_band_migrations to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to out_of_band_migrations maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_out_of_band_migrations_tenant_id ON out_of_band_migrations(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on out_of_band_migrations must scan out_of_band_migrations_errors to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to out_of_band_migrations_errors maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often out_of_band_migrations rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_out_of_band_migrations_errors_migration_id ON out_of_band_migrations_errors(migration_id);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan out_of_band_migrations_errors to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to out_of_band_migrations_errors maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_out_of_band_migrations_errors_tenant_id ON out_of_band_migrations_errors(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on outbound_webhooks must scan outbound_webhook_event_types to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to outbound_webhook_event_types maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often outbound_webhooks rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_outbound_webhook_event_types_outbound_webhook_id ON outbound_webhook_event_types(outbound_webhook_id);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan outbound_webhook_event_types to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to outbound_webhook_event_types maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_outbound_webhook_event_types_tenant_id ON outbound_webhook_event_types(tenant_id) WHERE tenant_id IS NOT NULL;
event_type is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE outbound_webhook_event_types ADD CONSTRAINT outbound_webhook_event_types_event_type_check CHECK (event_type IN (...));
scope is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE outbound_webhook_event_types ADD CONSTRAINT outbound_webhook_event_types_scope_check CHECK (scope IN (...));
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan outbound_webhook_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to outbound_webhook_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_outbound_webhook_jobs_tenant_id ON outbound_webhook_jobs(tenant_id) WHERE tenant_id IS NOT NULL;
event_type is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE outbound_webhook_jobs ADD CONSTRAINT outbound_webhook_jobs_event_type_check CHECK (event_type IN (...));
scope is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE outbound_webhook_jobs ADD CONSTRAINT outbound_webhook_jobs_scope_check CHECK (scope IN (...));
state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE outbound_webhook_jobs ADD CONSTRAINT outbound_webhook_jobs_state_check CHECK (state IN (...));
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on outbound_webhook_jobs must scan outbound_webhook_logs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to outbound_webhook_logs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often outbound_webhook_jobs rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_outbound_webhook_logs_job_id ON outbound_webhook_logs(job_id);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan outbound_webhook_logs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to outbound_webhook_logs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_outbound_webhook_logs_tenant_id ON outbound_webhook_logs(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan outbound_webhooks to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to outbound_webhooks maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. created_by is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_outbound_webhooks_created_by ON outbound_webhooks(created_by) WHERE created_by IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan outbound_webhooks to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to outbound_webhooks maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_outbound_webhooks_tenant_id ON outbound_webhooks(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan outbound_webhooks to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to outbound_webhooks maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. updated_by is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_outbound_webhooks_updated_by ON outbound_webhooks(updated_by) WHERE updated_by IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on commit_authors must scan own_aggregate_recent_contribution to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to own_aggregate_recent_contribution maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often commit_authors rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_own_aggregate_recent_contribution_commit_author_id ON own_aggregate_recent_contribution(commit_author_id);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan own_aggregate_recent_contribution to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to own_aggregate_recent_contribution maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_own_aggregate_recent_contribution_tenant_id ON own_aggregate_recent_contribution(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan own_aggregate_recent_view to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to own_aggregate_recent_view maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_own_aggregate_recent_view_tenant_id ON own_aggregate_recent_view(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan own_aggregate_recent_view to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to own_aggregate_recent_view maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_own_aggregate_recent_view_viewer_id ON own_aggregate_recent_view(viewer_id);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan own_background_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to own_background_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_own_background_jobs_tenant_id ON own_background_jobs(tenant_id) WHERE tenant_id IS NOT NULL;
state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE own_background_jobs ADD CONSTRAINT own_background_jobs_state_check CHECK (state IN (...));
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan own_signal_configurations to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to own_signal_configurations maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_own_signal_configurations_tenant_id ON own_signal_configurations(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on repo_paths must scan own_signal_recent_contribution to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to own_signal_recent_contribution maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often repo_paths rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_own_signal_recent_contribution_changed_file_path_id ON own_signal_recent_contribution(changed_file_path_id);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on commit_authors must scan own_signal_recent_contribution to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to own_signal_recent_contribution maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often commit_authors rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_own_signal_recent_contribution_commit_author_id ON own_signal_recent_contribution(commit_author_id);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan own_signal_recent_contribution to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to own_signal_recent_contribution maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_own_signal_recent_contribution_tenant_id ON own_signal_recent_contribution(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan ownership_path_stats to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to ownership_path_stats maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_ownership_path_stats_tenant_id ON ownership_path_stats(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan package_repo_filters to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to package_repo_filters maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_package_repo_filters_tenant_id ON package_repo_filters(tenant_id) WHERE tenant_id IS NOT NULL;
package_repo_filters soft-deletes via deleted_at, but (scheme, matcher) is unique across live AND deleted rows. A user who deletes their account can never sign up again with the same value, and ON CONFLICT upserts will resurrect ghosts.
Fix Replace with a partial unique index scoped to live rows.
DROP CONSTRAINT/INDEX ...; CREATE UNIQUE INDEX package_repo_filters_scheme_matcher_live ON package_repo_filters(scheme, matcher) WHERE deleted_at IS NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan package_repo_versions to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to package_repo_versions maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_package_repo_versions_tenant_id ON package_repo_versions(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan permission_sync_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to permission_sync_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_permission_sync_jobs_tenant_id ON permission_sync_jobs(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan permission_sync_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to permission_sync_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. triggered_by_user_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_permission_sync_jobs_triggered_by_user_id ON permission_sync_jobs(triggered_by_user_id) WHERE triggered_by_user_id IS NOT NULL;
state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE permission_sync_jobs ADD CONSTRAINT permission_sync_jobs_state_check CHECK (state IN (...));
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan permissions to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to permissions maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_permissions_tenant_id ON permissions(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan phabricator_repos to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to phabricator_repos maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_phabricator_repos_tenant_id ON phabricator_repos(tenant_id) WHERE tenant_id IS NOT NULL;
phabricator_repos soft-deletes via deleted_at, but (repo_name) is unique across live AND deleted rows. A user who deletes their account can never sign up again with the same value, and ON CONFLICT upserts will resurrect ghosts.
Fix Replace with a partial unique index scoped to live rows.
DROP CONSTRAINT/INDEX ...; CREATE UNIQUE INDEX phabricator_repos_repo_name_live ON phabricator_repos(repo_name) WHERE deleted_at IS NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on product_subscriptions must scan product_licenses to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to product_licenses maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often product_subscriptions rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_product_licenses_product_subscription_id ON product_licenses(product_subscription_id);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan product_licenses to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to product_licenses maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_product_licenses_tenant_id ON product_licenses(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan product_subscriptions to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to product_subscriptions maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_product_subscriptions_tenant_id ON product_subscriptions(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan product_subscriptions to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to product_subscriptions maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_product_subscriptions_user_id ON product_subscriptions(user_id);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan prompts to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to prompts maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. created_by is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_prompts_created_by ON prompts(created_by) WHERE created_by IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan prompts to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to prompts maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_prompts_tenant_id ON prompts(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan prompts to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to prompts maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. updated_by is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_prompts_updated_by ON prompts(updated_by) WHERE updated_by IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan query_runner_state to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to query_runner_state maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_query_runner_state_tenant_id ON query_runner_state(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan redis_key_value to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to redis_key_value maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_redis_key_value_tenant_id ON redis_key_value(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan registry_extension_releases to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to registry_extension_releases maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_registry_extension_releases_creator_user_id ON registry_extension_releases(creator_user_id);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan registry_extension_releases to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to registry_extension_releases maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_registry_extension_releases_tenant_id ON registry_extension_releases(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on orgs must scan registry_extensions to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to registry_extensions maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often orgs rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. publisher_org_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_registry_extensions_publisher_org_id ON registry_extensions(publisher_org_id) WHERE publisher_org_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan registry_extensions to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to registry_extensions maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. publisher_user_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_registry_extensions_publisher_user_id ON registry_extensions(publisher_user_id) WHERE publisher_user_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan registry_extensions to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to registry_extensions maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_registry_extensions_tenant_id ON registry_extensions(tenant_id) WHERE tenant_id IS NOT NULL;
registry_extensions soft-deletes via deleted_at, but (uuid) is unique across live AND deleted rows. A user who deletes their account can never sign up again with the same value, and ON CONFLICT upserts will resurrect ghosts.
Fix Replace with a partial unique index scoped to live rows.
DROP CONSTRAINT/INDEX ...; CREATE UNIQUE INDEX registry_extensions_uuid_live ON registry_extensions(uuid) WHERE deleted_at IS NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan repo to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to repo maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_repo_tenant_id ON repo(tenant_id) WHERE tenant_id IS NOT NULL;
external_service_type is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE repo ADD CONSTRAINT repo_external_service_type_check CHECK (external_service_type IN (...));
repo soft-deletes via deleted_at, but (external_service_type, external_service_id, external_id) is unique across live AND deleted rows. A user who deletes their account can never sign up again with the same value, and ON CONFLICT upserts will resurrect ghosts.
Fix Replace with a partial unique index scoped to live rows.
DROP CONSTRAINT/INDEX ...; CREATE UNIQUE INDEX repo_external_service_type_external_service_id_external_id_live ON repo(external_service_type, external_service_id, external_id) WHERE deleted_at IS NULL;
repo soft-deletes via deleted_at, but (name) is unique across live AND deleted rows. A user who deletes their account can never sign up again with the same value, and ON CONFLICT upserts will resurrect ghosts.
Fix Replace with a partial unique index scoped to live rows.
DROP CONSTRAINT/INDEX ...; CREATE UNIQUE INDEX repo_name_live ON repo(name) WHERE deleted_at IS NULL;
external_service_id points at different tables depending on external_service_type. No FK can express that, so orphans accumulate silently and every join needs a CASE. Acceptable for append-only audit data; painful anywhere the target must still exist.
Fix Either one nullable FK per target with a CHECK that exactly one is set, or a supertype table that the targets reference.
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan repo_commits_changelists to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to repo_commits_changelists maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_repo_commits_changelists_tenant_id ON repo_commits_changelists(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan repo_embedding_job_stats to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to repo_embedding_job_stats maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_repo_embedding_job_stats_tenant_id ON repo_embedding_job_stats(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan repo_embedding_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to repo_embedding_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_repo_embedding_jobs_tenant_id ON repo_embedding_jobs(tenant_id) WHERE tenant_id IS NOT NULL;
state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE repo_embedding_jobs ADD CONSTRAINT repo_embedding_jobs_state_check CHECK (state IN (...));
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan repo_kvps to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to repo_kvps maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_repo_kvps_tenant_id ON repo_kvps(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on repo_paths must scan repo_paths to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to repo_paths maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often repo_paths rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. parent_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_repo_paths_parent_id ON repo_paths(parent_id) WHERE parent_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan repo_paths to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to repo_paths maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_repo_paths_tenant_id ON repo_paths(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan repo_pending_permissions to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to repo_pending_permissions maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_repo_pending_permissions_tenant_id ON repo_pending_permissions(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan repo_permissions to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to repo_permissions maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_repo_permissions_tenant_id ON repo_permissions(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan repo_statistics to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to repo_statistics maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_repo_statistics_tenant_id ON repo_statistics(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on roles must scan role_permissions to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to role_permissions maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often roles rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_role_permissions_role_id ON role_permissions(role_id);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan role_permissions to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to role_permissions maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_role_permissions_tenant_id ON role_permissions(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan roles to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to roles maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_roles_tenant_id ON roles(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan saved_searches to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to saved_searches maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. created_by is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_saved_searches_created_by ON saved_searches(created_by) WHERE created_by IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on orgs must scan saved_searches to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to saved_searches maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often orgs rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. org_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_saved_searches_org_id ON saved_searches(org_id) WHERE org_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan saved_searches to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to saved_searches maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_saved_searches_tenant_id ON saved_searches(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan saved_searches to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to saved_searches maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. updated_by is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_saved_searches_updated_by ON saved_searches(updated_by) WHERE updated_by IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan saved_searches to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to saved_searches maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. user_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_saved_searches_user_id ON saved_searches(user_id) WHERE user_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on search_contexts must scan search_context_default to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to search_context_default maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often search_contexts rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_search_context_default_search_context_id ON search_context_default(search_context_id);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan search_context_default to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to search_context_default maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_search_context_default_tenant_id ON search_context_default(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on search_contexts must scan search_context_repos to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to search_context_repos maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often search_contexts rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_search_context_repos_search_context_id ON search_context_repos(search_context_id);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan search_context_repos to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to search_context_repos maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_search_context_repos_tenant_id ON search_context_repos(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan search_context_stars to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to search_context_stars maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_search_context_stars_tenant_id ON search_context_stars(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan search_context_stars to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to search_context_stars maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_search_context_stars_user_id ON search_context_stars(user_id);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on orgs must scan search_contexts to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to search_contexts maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often orgs rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. namespace_org_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_search_contexts_namespace_org_id ON search_contexts(namespace_org_id) WHERE namespace_org_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan search_contexts to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to search_contexts maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. namespace_user_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_search_contexts_namespace_user_id ON search_contexts(namespace_user_id) WHERE namespace_user_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan search_contexts to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to search_contexts maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_search_contexts_tenant_id ON search_contexts(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan security_event_logs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to security_event_logs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_security_event_logs_tenant_id ON security_event_logs(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan settings to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to settings maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. author_user_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_settings_author_user_id ON settings(author_user_id) WHERE author_user_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan settings to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to settings maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_settings_tenant_id ON settings(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan sub_repo_permissions to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to sub_repo_permissions maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_sub_repo_permissions_tenant_id ON sub_repo_permissions(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan survey_responses to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to survey_responses maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_survey_responses_tenant_id ON survey_responses(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan survey_responses to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to survey_responses maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. user_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_survey_responses_user_id ON survey_responses(user_id) WHERE user_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan syntactic_scip_indexing_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to syntactic_scip_indexing_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_syntactic_scip_indexing_jobs_tenant_id ON syntactic_scip_indexing_jobs(tenant_id) WHERE tenant_id IS NOT NULL;
state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE syntactic_scip_indexing_jobs ADD CONSTRAINT syntactic_scip_indexing_jobs_state_check CHECK (state IN (...));
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan syntactic_scip_last_index_scan to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to syntactic_scip_last_index_scan maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_syntactic_scip_last_index_scan_tenant_id ON syntactic_scip_last_index_scan(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan team_members to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to team_members maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_team_members_tenant_id ON team_members(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan team_members to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to team_members maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_team_members_user_id ON team_members(user_id);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan teams to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to teams maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. creator_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_teams_creator_id ON teams(creator_id) WHERE creator_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on teams must scan teams to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to teams maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often teams rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. parent_team_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_teams_parent_team_id ON teams(parent_team_id) WHERE parent_team_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan teams to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to teams maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_teams_tenant_id ON teams(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan telemetry_events_export_queue to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to telemetry_events_export_queue maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_telemetry_events_export_queue_tenant_id ON telemetry_events_export_queue(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan temporary_settings to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to temporary_settings maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_temporary_settings_tenant_id ON temporary_settings(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on github_apps must scan user_credentials to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to user_credentials maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often github_apps rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. github_app_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_user_credentials_github_app_id ON user_credentials(github_app_id) WHERE github_app_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan user_credentials to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to user_credentials maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_user_credentials_tenant_id ON user_credentials(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan user_credentials to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to user_credentials maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_user_credentials_user_id ON user_credentials(user_id);
external_service_type is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE user_credentials ADD CONSTRAINT user_credentials_external_service_type_check CHECK (external_service_type IN (...));
external_service_id points at different tables depending on external_service_type. No FK can express that, so orphans accumulate silently and every join needs a CASE. Acceptable for append-only audit data; painful anywhere the target must still exist.
Fix Either one nullable FK per target with a CHECK that exactly one is set, or a supertype table that the targets reference.
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan user_emails to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to user_emails maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_user_emails_tenant_id ON user_emails(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan user_external_accounts to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to user_external_accounts maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_user_external_accounts_tenant_id ON user_external_accounts(tenant_id) WHERE tenant_id IS NOT NULL;
service_type is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE user_external_accounts ADD CONSTRAINT user_external_accounts_service_type_check CHECK (service_type IN (...));
service_id points at different tables depending on service_type. No FK can express that, so orphans accumulate silently and every join needs a CASE. Acceptable for append-only audit data; painful anywhere the target must still exist.
Fix Either one nullable FK per target with a CHECK that exactly one is set, or a supertype table that the targets reference.
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan user_onboarding_tour to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to user_onboarding_tour maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_user_onboarding_tour_tenant_id ON user_onboarding_tour(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan user_onboarding_tour to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to user_onboarding_tour maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. updated_by is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_user_onboarding_tour_updated_by ON user_onboarding_tour(updated_by) WHERE updated_by IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan user_pending_permissions to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to user_pending_permissions maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_user_pending_permissions_tenant_id ON user_pending_permissions(tenant_id) WHERE tenant_id IS NOT NULL;
object_type is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE user_pending_permissions ADD CONSTRAINT user_pending_permissions_object_type_check CHECK (object_type IN (...));
service_type is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE user_pending_permissions ADD CONSTRAINT user_pending_permissions_service_type_check CHECK (service_type IN (...));
service_id points at different tables depending on service_type. No FK can express that, so orphans accumulate silently and every join needs a CASE. Acceptable for append-only audit data; painful anywhere the target must still exist.
Fix Either one nullable FK per target with a CHECK that exactly one is set, or a supertype table that the targets reference.
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan user_permissions to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to user_permissions maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_user_permissions_tenant_id ON user_permissions(tenant_id) WHERE tenant_id IS NOT NULL;
object_type is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE user_permissions ADD CONSTRAINT user_permissions_object_type_check CHECK (object_type IN (...));
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on repo must scan user_public_repos to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to user_public_repos maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often repo rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_user_public_repos_repo_id ON user_public_repos(repo_id);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan user_public_repos to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to user_public_repos maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_user_public_repos_tenant_id ON user_public_repos(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan user_repo_permissions to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to user_repo_permissions maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_user_repo_permissions_tenant_id ON user_repo_permissions(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on roles must scan user_roles to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to user_roles maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often roles rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add an index on the FK column(s).
CREATE INDEX CONCURRENTLY idx_user_roles_role_id ON user_roles(role_id);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan user_roles to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to user_roles maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_user_roles_tenant_id ON user_roles(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan users to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to users maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_users_tenant_id ON users(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan vulnerabilities to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to vulnerabilities maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_vulnerabilities_tenant_id ON vulnerabilities(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan vulnerability_affected_packages to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to vulnerability_affected_packages maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_vulnerability_affected_packages_tenant_id ON vulnerability_affected_packages(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan vulnerability_affected_symbols to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to vulnerability_affected_symbols maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_vulnerability_affected_symbols_tenant_id ON vulnerability_affected_symbols(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan vulnerability_matches to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to vulnerability_matches maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_vulnerability_matches_tenant_id ON vulnerability_matches(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan webhook_logs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to webhook_logs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_webhook_logs_tenant_id ON webhook_logs(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on webhooks must scan webhook_logs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to webhook_logs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often webhooks rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. webhook_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_webhook_logs_webhook_id ON webhook_logs(webhook_id) WHERE webhook_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan webhooks to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to webhooks maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. created_by_user_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_webhooks_created_by_user_id ON webhooks(created_by_user_id) WHERE created_by_user_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan webhooks to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to webhooks maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_webhooks_tenant_id ON webhooks(tenant_id) WHERE tenant_id IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan webhooks to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to webhooks maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. updated_by_user_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_webhooks_updated_by_user_id ON webhooks(updated_by_user_id) WHERE updated_by_user_id IS NOT NULL;
code_host_kind is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code. The comment lists Kind of an external service for which webhooks are registered., i.e. the values are known.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE webhooks ADD CONSTRAINT webhooks_code_host_kind_check CHECK (code_host_kind IN (...));
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan zoekt_repos to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to zoekt_repos maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.
Fix Add a partial index, scoped to the rows that have a value. tenant_id is nullable, so the NULL rows are not indexed at all and the write cost is a fraction of a full index, while the constraint check still uses it.
CREATE INDEX CONCURRENTLY idx_zoekt_repos_tenant_id ON zoekt_repos(tenant_id) WHERE tenant_id IS NOT NULL;
index_status is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.
Fix Add a CHECK constraint (cheap, easy to evolve) or a lookup table if values need metadata. Avoid native ENUM types unless the set is truly frozen.
ALTER TABLE zoekt_repos ADD CONSTRAINT zoekt_repos_index_status_check CHECK (index_status IN (...));
access_requests.decision_by_user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
access_requests.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
access_requests has several nullable FKs (decision_by_user_id, tenant_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.
Fix Add a CHECK that exactly one is non-null, or restructure with a supertype.
ALTER TABLE access_requests ADD CONSTRAINT access_requests_one_target CHECK ((decision_by_user_id IS NOT NULL)::int + (tenant_id IS NOT NULL)::int = 1);
access_tokens.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
aggregated_user_statistics.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
assigned_owners.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
assigned_owners.who_assigned_user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
assigned_owners has several nullable FKs (tenant_id, who_assigned_user_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.
Fix Add a CHECK that exactly one is non-null, or restructure with a supertype.
ALTER TABLE assigned_owners ADD CONSTRAINT assigned_owners_one_target CHECK ((tenant_id IS NOT NULL)::int + (who_assigned_user_id IS NOT NULL)::int = 1);
assigned_at stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.
Fix Use TIMESTAMPTZ.
ALTER TABLE assigned_owners ALTER COLUMN assigned_at TYPE timestamptz;
assigned_teams.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
assigned_teams.who_assigned_team_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
assigned_teams has several nullable FKs (tenant_id, who_assigned_team_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.
Fix Add a CHECK that exactly one is non-null, or restructure with a supertype.
ALTER TABLE assigned_teams ADD CONSTRAINT assigned_teams_one_target CHECK ((tenant_id IS NOT NULL)::int + (who_assigned_team_id IS NOT NULL)::int = 1);
assigned_at stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.
Fix Use TIMESTAMPTZ.
ALTER TABLE assigned_teams ALTER COLUMN assigned_at TYPE timestamptz;
batch_changes.creator_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
batch_changes.last_applier_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
batch_changes.namespace_org_id may be NULL, so the relationship to orgs is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
batch_changes.namespace_user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
batch_changes.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
creator_id, last_applier_id, namespace_org_id, namespace_user_id, tenant_idexclusive-arcbatch_changes has several nullable FKs (creator_id, last_applier_id, namespace_org_id, namespace_user_id, tenant_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.
Fix Add a CHECK that exactly one is non-null, or restructure with a supertype.
ALTER TABLE batch_changes ADD CONSTRAINT batch_changes_one_target CHECK ((creator_id IS NOT NULL)::int + (last_applier_id IS NOT NULL)::int + (namespace_org_id IS NOT NULL)::int + (namespace_user_id IS NOT NULL)::int + (tenant_id IS NOT NULL)::int = 1);
batch_changes_site_credentials.github_app_id may be NULL, so the relationship to github_apps is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
batch_changes_site_credentials.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
batch_changes_site_credentials has several nullable FKs (github_app_id, tenant_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.
Fix Add a CHECK that exactly one is non-null, or restructure with a supertype.
ALTER TABLE batch_changes_site_credentials ADD CONSTRAINT batch_changes_site_credentials_one_target CHECK ((github_app_id IS NOT NULL)::int + (tenant_id IS NOT NULL)::int = 1);
batch_spec_execution_cache_entries.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
batch_spec_resolution_jobs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
batch_spec_workspace_execution_jobs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
batch_spec_workspace_execution_last_dequeues.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
batch_spec_workspace_files.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
batch_spec_workspaces.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
batch_specs.batch_change_id may be NULL, so the relationship to batch_changes is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
batch_specs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
batch_specs.user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
batch_specs has several nullable FKs (batch_change_id, tenant_id, user_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.
Fix Add a CHECK that exactly one is non-null, or restructure with a supertype.
ALTER TABLE batch_specs ADD CONSTRAINT batch_specs_one_target CHECK ((batch_change_id IS NOT NULL)::int + (tenant_id IS NOT NULL)::int + (user_id IS NOT NULL)::int = 1);
cached_available_indexers.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
changeset_events.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
changeset_jobs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
changeset_specs.batch_spec_id may be NULL, so the relationship to batch_specs is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
changeset_specs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
changeset_specs.user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
changeset_specs has several nullable FKs (batch_spec_id, tenant_id, user_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.
Fix Add a CHECK that exactly one is non-null, or restructure with a supertype.
ALTER TABLE changeset_specs ADD CONSTRAINT changeset_specs_one_target CHECK ((batch_spec_id IS NOT NULL)::int + (tenant_id IS NOT NULL)::int + (user_id IS NOT NULL)::int = 1);
changesets.current_spec_id may be NULL, so the relationship to changeset_specs is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
changesets.owned_by_batch_change_id may be NULL, so the relationship to batch_changes is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
changesets.previous_spec_id may be NULL, so the relationship to changeset_specs is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
changesets.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
changesets has several nullable FKs (current_spec_id, owned_by_batch_change_id, previous_spec_id, tenant_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.
Fix Add a CHECK that exactly one is non-null, or restructure with a supertype.
ALTER TABLE changesets ADD CONSTRAINT changesets_one_target CHECK ((current_spec_id IS NOT NULL)::int + (owned_by_batch_change_id IS NOT NULL)::int + (previous_spec_id IS NOT NULL)::int + (tenant_id IS NOT NULL)::int = 1);
Tables this wide usually hide several entities (or a JSON column that wants to be one). Every row update rewrites the whole tuple; TOAST kicks in; indexes bloat.
Fix Look for column groups that always change together and split them out.
cm_action_jobs.email may be NULL, so the relationship to cm_emails is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
cm_action_jobs.slack_webhook may be NULL, so the relationship to cm_slack_webhooks is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
cm_action_jobs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
cm_action_jobs.trigger_event may be NULL, so the relationship to cm_trigger_jobs is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
cm_action_jobs.webhook may be NULL, so the relationship to cm_webhooks is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
cm_action_jobs has several nullable FKs (email, slack_webhook, tenant_id, trigger_event, webhook) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.
Fix Add a CHECK that exactly one is non-null, or restructure with a supertype.
ALTER TABLE cm_action_jobs ADD CONSTRAINT cm_action_jobs_one_target CHECK ((email IS NOT NULL)::int + (slack_webhook IS NOT NULL)::int + (tenant_id IS NOT NULL)::int + (trigger_event IS NOT NULL)::int + (webhook IS NOT NULL)::int = 1);
cm_emails.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
cm_last_searched.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
cm_monitors.namespace_org_id may be NULL, so the relationship to orgs is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
cm_monitors.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
cm_monitors has several nullable FKs (namespace_org_id, tenant_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.
Fix Add a CHECK that exactly one is non-null, or restructure with a supertype.
ALTER TABLE cm_monitors ADD CONSTRAINT cm_monitors_one_target CHECK ((namespace_org_id IS NOT NULL)::int + (tenant_id IS NOT NULL)::int = 1);
cm_queries.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
cm_recipients.namespace_org_id may be NULL, so the relationship to orgs is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
cm_recipients.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
cm_recipients.namespace_user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
cm_recipients has several nullable FKs (namespace_org_id, tenant_id, namespace_user_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.
Fix Add a CHECK that exactly one is non-null, or restructure with a supertype.
ALTER TABLE cm_recipients ADD CONSTRAINT cm_recipients_one_target CHECK ((namespace_org_id IS NOT NULL)::int + (tenant_id IS NOT NULL)::int + (namespace_user_id IS NOT NULL)::int = 1);
cm_slack_webhooks.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
cm_trigger_jobs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
cm_webhooks.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
code_hosts.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
codeintel_autoindex_queue.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
codeintel_autoindexing_exceptions.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
codeintel_commit_dates.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
codeintel_inference_scripts.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
codeintel_initial_path_ranks.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
codeintel_initial_path_ranks_processed.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
codeintel_langugage_support_requests.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
codeintel_path_ranks.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
codeintel_ranking_definitions.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
codeintel_ranking_exports.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
codeintel_ranking_exports.upload_id may be NULL, so the relationship to lsif_uploads is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
codeintel_ranking_exports has several nullable FKs (tenant_id, upload_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.
Fix Add a CHECK that exactly one is non-null, or restructure with a supertype.
ALTER TABLE codeintel_ranking_exports ADD CONSTRAINT codeintel_ranking_exports_one_target CHECK ((tenant_id IS NOT NULL)::int + (upload_id IS NOT NULL)::int = 1);
codeintel_ranking_graph_keys.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
codeintel_ranking_path_counts_inputs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
codeintel_ranking_progress.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
codeintel_ranking_references.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
codeintel_ranking_references_processed.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
codeowners.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
codeowners_individual_stats.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
updated_at stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.
Fix Use TIMESTAMPTZ.
ALTER TABLE codeowners_individual_stats ALTER COLUMN updated_at TYPE timestamptz;
codeowners_owners.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
commit_authors.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
configuration_policies_audit_logs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
context_detection_embedding_jobs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
critical_and_site_config references nothing and nothing references it. Either it is a staging/log table (fine, say so), or it is dead, or it is the seed of a second data model growing beside the first.
Fix Document its purpose or drop it.
discussion_comments.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
discussion_mail_reply_tokens.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
discussion_threads.target_repo_id may be NULL, so the relationship to discussion_threads_target_repo is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
discussion_threads.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
discussion_threads has several nullable FKs (target_repo_id, tenant_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.
Fix Add a CHECK that exactly one is non-null, or restructure with a supertype.
ALTER TABLE discussion_threads ADD CONSTRAINT discussion_threads_one_target CHECK ((target_repo_id IS NOT NULL)::int + (tenant_id IS NOT NULL)::int = 1);
discussion_threads_target_repo.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
event_logs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
event_logs_export_allowlist.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
event_logs_scrape_state.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
event_logs_scrape_state_own.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
executor_heartbeats.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
executor_job_tokens.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
executor_secret_access_logs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
executor_secret_access_logs.user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
executor_secret_access_logs has several nullable FKs (tenant_id, user_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.
Fix Add a CHECK that exactly one is non-null, or restructure with a supertype.
ALTER TABLE executor_secret_access_logs ADD CONSTRAINT executor_secret_access_logs_one_target CHECK ((tenant_id IS NOT NULL)::int + (user_id IS NOT NULL)::int = 1);
executor_secrets.creator_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
executor_secrets.namespace_org_id may be NULL, so the relationship to orgs is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
executor_secrets.namespace_user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
executor_secrets.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
executor_secrets has several nullable FKs (creator_id, namespace_org_id, namespace_user_id, tenant_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.
Fix Add a CHECK that exactly one is non-null, or restructure with a supertype.
ALTER TABLE executor_secrets ADD CONSTRAINT executor_secrets_one_target CHECK ((creator_id IS NOT NULL)::int + (namespace_org_id IS NOT NULL)::int + (namespace_user_id IS NOT NULL)::int + (tenant_id IS NOT NULL)::int = 1);
exhaustive_search_jobs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
exhaustive_search_repo_jobs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
exhaustive_search_repo_revision_jobs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
explicit_permissions_bitbucket_projects_jobs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
external_service_repos.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
external_service_sync_jobs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
external_services.code_host_id may be NULL, so the relationship to code_hosts is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
external_services.creator_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
external_services.last_updater_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
external_services.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
external_services has several nullable FKs (code_host_id, creator_id, last_updater_id, tenant_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.
Fix Add a CHECK that exactly one is non-null, or restructure with a supertype.
ALTER TABLE external_services ADD CONSTRAINT external_services_one_target CHECK ((code_host_id IS NOT NULL)::int + (creator_id IS NOT NULL)::int + (last_updater_id IS NOT NULL)::int + (tenant_id IS NOT NULL)::int = 1);
feature_flag_overrides.namespace_org_id may be NULL, so the relationship to orgs is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
feature_flag_overrides.namespace_user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
feature_flag_overrides.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
feature_flag_overrides has several nullable FKs (namespace_org_id, namespace_user_id, tenant_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.
Fix Add a CHECK that exactly one is non-null, or restructure with a supertype.
ALTER TABLE feature_flag_overrides ADD CONSTRAINT feature_flag_overrides_one_target CHECK ((namespace_org_id IS NOT NULL)::int + (namespace_user_id IS NOT NULL)::int + (tenant_id IS NOT NULL)::int = 1);
feature_flags.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
github_app_installs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
github_apps.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
github_apps.webhook_id may be NULL, so the relationship to webhooks is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
github_apps has several nullable FKs (tenant_id, webhook_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.
Fix Add a CHECK that exactly one is non-null, or restructure with a supertype.
ALTER TABLE github_apps ADD CONSTRAINT github_apps_one_target CHECK ((tenant_id IS NOT NULL)::int + (webhook_id IS NOT NULL)::int = 1);
gitserver_relocator_jobs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
gitserver_repos.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
gitserver_repos_statistics.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
gitserver_repos_sync_output.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
global_state.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
insights_query_runner_jobs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
insights_query_runner_jobs_dependencies.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
recording_time stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.
Fix Use TIMESTAMPTZ.
ALTER TABLE insights_query_runner_jobs_dependencies ALTER COLUMN recording_time TYPE timestamptz;
insights_settings_migration_jobs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
completed_at stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.
Fix Use TIMESTAMPTZ.
ALTER TABLE insights_settings_migration_jobs ALTER COLUMN completed_at TYPE timestamptz;
lsif_configuration_policies references nothing and nothing references it. Either it is a staging/log table (fine, say so), or it is dead, or it is the seed of a second data model growing beside the first.
Fix Document its purpose or drop it.
lsif_configuration_policies_repository_pattern_lookup references nothing and nothing references it. Either it is a staging/log table (fine, say so), or it is dead, or it is the seed of a second data model growing beside the first.
Fix Document its purpose or drop it.
lsif_dependency_indexing_jobs.upload_id may be NULL, so the relationship to lsif_uploads is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
lsif_dependency_syncing_jobs.upload_id may be NULL, so the relationship to lsif_uploads is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
lsif_dirty_repositories references nothing and nothing references it. Either it is a staging/log table (fine, say so), or it is dead, or it is the seed of a second data model growing beside the first.
Fix Document its purpose or drop it.
lsif_indexes references nothing and nothing references it. Either it is a staging/log table (fine, say so), or it is dead, or it is the seed of a second data model growing beside the first.
Fix Document its purpose or drop it.
lsif_last_index_scan references nothing and nothing references it. Either it is a staging/log table (fine, say so), or it is dead, or it is the seed of a second data model growing beside the first.
Fix Document its purpose or drop it.
lsif_last_retention_scan references nothing and nothing references it. Either it is a staging/log table (fine, say so), or it is dead, or it is the seed of a second data model growing beside the first.
Fix Document its purpose or drop it.
lsif_nearest_uploads references nothing and nothing references it. Either it is a staging/log table (fine, say so), or it is dead, or it is the seed of a second data model growing beside the first.
Fix Document its purpose or drop it.
lsif_nearest_uploads_links references nothing and nothing references it. Either it is a staging/log table (fine, say so), or it is dead, or it is the seed of a second data model growing beside the first.
Fix Document its purpose or drop it.
Tables this wide usually hide several entities (or a JSON column that wants to be one). Every row update rewrites the whole tuple; TOAST kicks in; indexes bloat.
Fix Look for column groups that always change together and split them out.
lsif_uploads_audit_logs references nothing and nothing references it. Either it is a staging/log table (fine, say so), or it is dead, or it is the seed of a second data model growing beside the first.
Fix Document its purpose or drop it.
lsif_uploads_visible_at_tip references nothing and nothing references it. Either it is a staging/log table (fine, say so), or it is dead, or it is the seed of a second data model growing beside the first.
Fix Document its purpose or drop it.
last_scanned_at stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.
Fix Use TIMESTAMPTZ.
ALTER TABLE lsif_uploads_vulnerability_scan ALTER COLUMN last_scanned_at TYPE timestamptz;
names.org_id may be NULL, so the relationship to orgs is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
names.team_id may be NULL, so the relationship to teams is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
names.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
names.user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
names has several nullable FKs (org_id, team_id, tenant_id, user_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.
Fix Add a CHECK that exactly one is non-null, or restructure with a supertype.
ALTER TABLE names ADD CONSTRAINT names_one_target CHECK ((org_id IS NOT NULL)::int + (team_id IS NOT NULL)::int + (tenant_id IS NOT NULL)::int + (user_id IS NOT NULL)::int = 1);
namespace_permissions.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
notebook_stars.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
notebooks.creator_user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
notebooks.namespace_org_id may be NULL, so the relationship to orgs is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
notebooks.namespace_user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
notebooks.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
notebooks.updater_user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
creator_user_id, namespace_org_id, namespace_user_id, tenant_id, updater_user_idexclusive-arcnotebooks has several nullable FKs (creator_user_id, namespace_org_id, namespace_user_id, tenant_id, updater_user_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.
Fix Add a CHECK that exactly one is non-null, or restructure with a supertype.
ALTER TABLE notebooks ADD CONSTRAINT notebooks_one_target CHECK ((creator_user_id IS NOT NULL)::int + (namespace_org_id IS NOT NULL)::int + (namespace_user_id IS NOT NULL)::int + (tenant_id IS NOT NULL)::int + (updater_user_id IS NOT NULL)::int = 1);
org_invitations.recipient_user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
org_invitations.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
org_invitations has several nullable FKs (recipient_user_id, tenant_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.
Fix Add a CHECK that exactly one is non-null, or restructure with a supertype.
ALTER TABLE org_invitations ADD CONSTRAINT org_invitations_one_target CHECK ((recipient_user_id IS NOT NULL)::int + (tenant_id IS NOT NULL)::int = 1);
org_members.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
org_stats.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
orgs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
orgs_open_beta_stats.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
out_of_band_migrations.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
out_of_band_migrations_errors.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
outbound_webhook_event_types.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
outbound_webhook_jobs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
outbound_webhook_logs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
outbound_webhooks.created_by may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
outbound_webhooks.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
outbound_webhooks.updated_by may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
own_aggregate_recent_contribution.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
own_aggregate_recent_view.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
own_background_jobs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
own_signal_configurations.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
own_signal_recent_contribution.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
commit_timestamp stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.
Fix Use TIMESTAMPTZ.
ALTER TABLE own_signal_recent_contribution ALTER COLUMN commit_timestamp TYPE timestamptz;
ownership_path_stats.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
last_updated_at stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.
Fix Use TIMESTAMPTZ.
ALTER TABLE ownership_path_stats ALTER COLUMN last_updated_at TYPE timestamptz;
package_repo_filters.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
package_repo_versions.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
permission_sync_jobs.repository_id may be NULL, so the relationship to repo is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
permission_sync_jobs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
permission_sync_jobs.triggered_by_user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
permission_sync_jobs.user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
permission_sync_jobs has several nullable FKs (repository_id, tenant_id, triggered_by_user_id, user_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.
Fix Add a CHECK that exactly one is non-null, or restructure with a supertype.
ALTER TABLE permission_sync_jobs ADD CONSTRAINT permission_sync_jobs_one_target CHECK ((repository_id IS NOT NULL)::int + (tenant_id IS NOT NULL)::int + (triggered_by_user_id IS NOT NULL)::int + (user_id IS NOT NULL)::int = 1);
permissions.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
phabricator_repos.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
product_licenses.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
product_subscriptions.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
prompts.created_by may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
prompts.owner_org_id may be NULL, so the relationship to orgs is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
prompts.owner_user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
prompts.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
prompts.updated_by may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
prompts has several nullable FKs (owner_org_id, owner_user_id, tenant_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.
Fix Add a CHECK that exactly one is non-null, or restructure with a supertype.
ALTER TABLE prompts ADD CONSTRAINT prompts_one_target CHECK ((owner_org_id IS NOT NULL)::int + (owner_user_id IS NOT NULL)::int + (tenant_id IS NOT NULL)::int = 1);
query_runner_state.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
redis_key_value.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
registry_extension_releases.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
registry_extensions.publisher_org_id may be NULL, so the relationship to orgs is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
registry_extensions.publisher_user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
registry_extensions.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
registry_extensions has several nullable FKs (publisher_org_id, publisher_user_id, tenant_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.
Fix Add a CHECK that exactly one is non-null, or restructure with a supertype.
ALTER TABLE registry_extensions ADD CONSTRAINT registry_extensions_one_target CHECK ((publisher_org_id IS NOT NULL)::int + (publisher_user_id IS NOT NULL)::int + (tenant_id IS NOT NULL)::int = 1);
repo.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
Any change to its key, its delete semantics, or its partitioning touches every dependent. Migrations on hub tables need the longest lock windows and the most careful rollout.
Fix Treat schema changes here as breaking changes with a written rollout plan.
repo_commits_changelists.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
repo_embedding_job_stats.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
repo_embedding_jobs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
repo_kvps.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
repo_paths.parent_id may be NULL, so the relationship to repo_paths is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
repo_paths.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
repo_paths has several nullable FKs (parent_id, tenant_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.
Fix Add a CHECK that exactly one is non-null, or restructure with a supertype.
ALTER TABLE repo_paths ADD CONSTRAINT repo_paths_one_target CHECK ((parent_id IS NOT NULL)::int + (tenant_id IS NOT NULL)::int = 1);
tree_files_counts_updated_at stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.
Fix Use TIMESTAMPTZ.
ALTER TABLE repo_paths ALTER COLUMN tree_files_counts_updated_at TYPE timestamptz;
repo_pending_permissions.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
repo_permissions.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
repo_statistics.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
role_permissions.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
roles.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
saved_searches.created_by may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
saved_searches.org_id may be NULL, so the relationship to orgs is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
saved_searches.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
saved_searches.updated_by may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
saved_searches.user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
saved_searches has several nullable FKs (org_id, tenant_id, user_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.
Fix Add a CHECK that exactly one is non-null, or restructure with a supertype.
ALTER TABLE saved_searches ADD CONSTRAINT saved_searches_one_target CHECK ((org_id IS NOT NULL)::int + (tenant_id IS NOT NULL)::int + (user_id IS NOT NULL)::int = 1);
search_context_default.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
search_context_repos.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
search_context_stars.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
search_contexts.namespace_org_id may be NULL, so the relationship to orgs is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
search_contexts.namespace_user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
search_contexts.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
search_contexts has several nullable FKs (namespace_org_id, namespace_user_id, tenant_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.
Fix Add a CHECK that exactly one is non-null, or restructure with a supertype.
ALTER TABLE search_contexts ADD CONSTRAINT search_contexts_one_target CHECK ((namespace_org_id IS NOT NULL)::int + (namespace_user_id IS NOT NULL)::int + (tenant_id IS NOT NULL)::int = 1);
security_event_logs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
settings.author_user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
settings.org_id may be NULL, so the relationship to orgs is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
settings.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
settings.user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
settings has several nullable FKs (author_user_id, org_id, tenant_id, user_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.
Fix Add a CHECK that exactly one is non-null, or restructure with a supertype.
ALTER TABLE settings ADD CONSTRAINT settings_one_target CHECK ((author_user_id IS NOT NULL)::int + (org_id IS NOT NULL)::int + (tenant_id IS NOT NULL)::int + (user_id IS NOT NULL)::int = 1);
sub_repo_permissions.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
survey_responses.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
survey_responses.user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
survey_responses has several nullable FKs (tenant_id, user_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.
Fix Add a CHECK that exactly one is non-null, or restructure with a supertype.
ALTER TABLE survey_responses ADD CONSTRAINT survey_responses_one_target CHECK ((tenant_id IS NOT NULL)::int + (user_id IS NOT NULL)::int = 1);
syntactic_scip_indexing_jobs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
syntactic_scip_last_index_scan.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
team_members.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
teams.creator_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
teams.parent_team_id may be NULL, so the relationship to teams is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
teams.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
teams has several nullable FKs (creator_id, parent_team_id, tenant_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.
Fix Add a CHECK that exactly one is non-null, or restructure with a supertype.
ALTER TABLE teams ADD CONSTRAINT teams_one_target CHECK ((creator_id IS NOT NULL)::int + (parent_team_id IS NOT NULL)::int + (tenant_id IS NOT NULL)::int = 1);
telemetry_events_export_queue.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
temporary_settings.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
Any change to its key, its delete semantics, or its partitioning touches every dependent. Migrations on hub tables need the longest lock windows and the most careful rollout.
Fix Treat schema changes here as breaking changes with a written rollout plan.
user_credentials.github_app_id may be NULL, so the relationship to github_apps is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
user_credentials.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
user_credentials has several nullable FKs (github_app_id, tenant_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.
Fix Add a CHECK that exactly one is non-null, or restructure with a supertype.
ALTER TABLE user_credentials ADD CONSTRAINT user_credentials_one_target CHECK ((github_app_id IS NOT NULL)::int + (tenant_id IS NOT NULL)::int = 1);
user_emails.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
user_external_accounts.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
user_onboarding_tour.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
user_onboarding_tour.updated_by may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
created_at stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.
Fix Use TIMESTAMPTZ.
ALTER TABLE user_onboarding_tour ALTER COLUMN created_at TYPE timestamptz;
user_pending_permissions.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
user_permissions.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
user_public_repos.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
user_repo_permissions.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
user_repo_permissions.user_external_account_id may be NULL, so the relationship to user_external_accounts is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
user_repo_permissions.user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
user_repo_permissions has several nullable FKs (tenant_id, user_external_account_id, user_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.
Fix Add a CHECK that exactly one is non-null, or restructure with a supertype.
ALTER TABLE user_repo_permissions ADD CONSTRAINT user_repo_permissions_one_target CHECK ((tenant_id IS NOT NULL)::int + (user_external_account_id IS NOT NULL)::int + (user_id IS NOT NULL)::int = 1);
user_roles.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
users.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
Any change to its key, its delete semantics, or its partitioning touches every dependent. Migrations on hub tables need the longest lock windows and the most careful rollout.
Fix Treat schema changes here as breaking changes with a written rollout plan.
versions references nothing and nothing references it. Either it is a staging/log table (fine, say so), or it is dead, or it is the seed of a second data model growing beside the first.
Fix Document its purpose or drop it.
vulnerabilities.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
vulnerability_affected_packages.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
vulnerability_affected_symbols.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
vulnerability_matches.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
webhook_logs.external_service_id may be NULL, so the relationship to external_services is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
webhook_logs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
webhook_logs.webhook_id may be NULL, so the relationship to webhooks is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
webhook_logs has several nullable FKs (external_service_id, tenant_id, webhook_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.
Fix Add a CHECK that exactly one is non-null, or restructure with a supertype.
ALTER TABLE webhook_logs ADD CONSTRAINT webhook_logs_one_target CHECK ((external_service_id IS NOT NULL)::int + (tenant_id IS NOT NULL)::int + (webhook_id IS NOT NULL)::int = 1);
webhooks.created_by_user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
webhooks.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
webhooks.updated_by_user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
webhooks has several nullable FKs (created_by_user_id, tenant_id, updated_by_user_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.
Fix Add a CHECK that exactly one is non-null, or restructure with a supertype.
ALTER TABLE webhooks ADD CONSTRAINT webhooks_one_target CHECK ((created_by_user_id IS NOT NULL)::int + (tenant_id IS NOT NULL)::int + (updated_by_user_id IS NOT NULL)::int = 1);
zoekt_repos.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.
Fix Confirm the optionality is a domain rule; document it in the column comment.
180 tables · 362 foreign keys · 31 domains. Open the 3D explorer: rotate, zoom, click any table or relationship.
Tables whose names start with access_.
access_requests.decision_by_user_id → users.id — one users, many access_requests · optional · ON DELETE SET NULL · not indexedaccess_requests.tenant_id → tenants.id — one tenants, many access_requests · optional · ON DELETE CASCADE · not indexedaccess_tokens.creator_user_id → users.id — one users, many access_tokens · required · ON DELETE NO ACTION · not indexedaccess_tokens.subject_user_id → users.id — one users, many access_tokens · required · ON DELETE NO ACTION · not indexedaccess_tokens.tenant_id → tenants.id — one tenants, many access_tokens · optional · ON DELETE CASCADE · not indexeddecision_by_user_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan access_requests to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to access_requests maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan access_requests to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to access_requests maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.decision_by_user_id — access_requests.decision_by_user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.tenant_id — access_requests.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.status — status is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.decision_by_user_id, tenant_id — access_requests has several nullable FKs (decision_by_user_id, tenant_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
name | text | NOT NULL | |||
email UK | text | NOT NULL | |||
additional_info | text | null | |||
status | text | NOT NULL | |||
decision_by_user_id | integer | null | users.id 1:N · SET NULL | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
creator_user_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan access_tokens to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to access_tokens maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.subject_user_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan access_tokens to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to access_tokens maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan access_tokens to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to access_tokens maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — access_tokens.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.value_sha256 — access_tokens soft-deletes via deleted_at, but (value_sha256) is unique across live AND deleted rows. A user who deletes their account can never sign up again with the same value, and ON CONFLICT upserts will resurrect ghosts.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
subject_user_id | integer | NOT NULL | users.id 1:N | ||
value_sha256 UK | bytea | NOT NULL | |||
note | text | NOT NULL | |||
created_at | timestamptz | NOT NULL | now() | ||
last_used_at | timestamptz | null | |||
deleted_at | timestamptz | null | |||
creator_user_id | integer | NOT NULL | users.id 1:N | ||
scopes | text[] | NOT NULL | |||
internal | boolean | null | FALSE | ||
expires_at | timestamptz | null | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Tables whose names start with assigned_.
assigned_owners.file_path_id → repo_paths.id — one repo_paths, many assigned_owners · required · ON DELETE NO ACTION · indexedassigned_owners.owner_user_id → users.id — one users, many assigned_owners · required · ON DELETE CASCADE · not indexedassigned_owners.tenant_id → tenants.id — one tenants, many assigned_owners · optional · ON DELETE CASCADE · not indexedassigned_owners.who_assigned_user_id → users.id — one users, many assigned_owners · optional · ON DELETE SET NULL · not indexedassigned_teams.file_path_id → repo_paths.id — one repo_paths, many assigned_teams · required · ON DELETE NO ACTION · indexedassigned_teams.owner_team_id → teams.id — one teams, many assigned_teams · required · ON DELETE CASCADE · not indexedassigned_teams.tenant_id → tenants.id — one tenants, many assigned_teams · optional · ON DELETE CASCADE · not indexedassigned_teams.who_assigned_team_id → users.id — one users, many assigned_teams · optional · ON DELETE SET NULL · not indexedTable for ownership assignments, one entry contains an assigned user ID, which repo_path is assigned and the date and user who assigned the owner.
owner_user_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan assigned_owners to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to assigned_owners maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan assigned_owners to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to assigned_owners maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.who_assigned_user_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan assigned_owners to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to assigned_owners maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — assigned_owners.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.who_assigned_user_id — assigned_owners.who_assigned_user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.tenant_id, who_assigned_user_id — assigned_owners has several nullable FKs (tenant_id, who_assigned_user_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.assigned_at — assigned_at stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
owner_user_id | integer | NOT NULL | users.id 1:N · CASCADE | ||
file_path_id | integer | NOT NULL | repo_paths.id 1:N | ||
who_assigned_user_id | integer | null | users.id 1:N · SET NULL | ||
assigned_at | timestamp | NOT NULL | now() | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Table for team ownership assignments, one entry contains an assigned team ID, which repo_path is assigned and the date and user who assigned the owner team.
owner_team_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on teams must scan assigned_teams to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to assigned_teams maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often teams rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan assigned_teams to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to assigned_teams maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.who_assigned_team_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan assigned_teams to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to assigned_teams maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — assigned_teams.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.who_assigned_team_id — assigned_teams.who_assigned_team_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.tenant_id, who_assigned_team_id — assigned_teams has several nullable FKs (tenant_id, who_assigned_team_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.assigned_at — assigned_at stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
owner_team_id | integer | NOT NULL | teams.id 1:N · CASCADE | ||
file_path_id | integer | NOT NULL | repo_paths.id 1:N | ||
who_assigned_team_id | integer | null | users.id 1:N · SET NULL | ||
assigned_at | timestamp | NOT NULL | now() | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Tables whose names start with batch_.
batch_changes.batch_spec_id → batch_specs.id — one batch_specs, many batch_changes · required · ON DELETE NO ACTION · not indexedbatch_changes.creator_id → users.id — one users, many batch_changes · optional · ON DELETE SET NULL · not indexedbatch_changes.last_applier_id → users.id — one users, many batch_changes · optional · ON DELETE SET NULL · not indexedbatch_changes.namespace_org_id → orgs.id — one orgs, many batch_changes · optional · ON DELETE CASCADE · indexedbatch_changes.namespace_user_id → users.id — one users, many batch_changes · optional · ON DELETE CASCADE · indexedbatch_changes.tenant_id → tenants.id — one tenants, many batch_changes · optional · ON DELETE CASCADE · not indexedbatch_changes_site_credentials.github_app_id → github_apps.id — one github_apps, many batch_changes_site_credentials · optional · ON DELETE CASCADE · not indexedbatch_changes_site_credentials.tenant_id → tenants.id — one tenants, many batch_changes_site_credentials · optional · ON DELETE CASCADE · not indexedbatch_spec_execution_cache_entries.tenant_id → tenants.id — one tenants, many batch_spec_execution_cache_entries · optional · ON DELETE CASCADE · not indexedbatch_spec_execution_cache_entries.user_id → users.id — one users, many batch_spec_execution_cache_entries · required · ON DELETE CASCADE · indexedbatch_spec_resolution_jobs.batch_spec_id → batch_specs.id — one batch_specs, at most one batch_spec_resolution_jobs · required · ON DELETE CASCADE · indexedbatch_spec_resolution_jobs.initiator_id → users.id — one users, many batch_spec_resolution_jobs · required · ON DELETE CASCADE · not indexedbatch_spec_resolution_jobs.tenant_id → tenants.id — one tenants, many batch_spec_resolution_jobs · optional · ON DELETE CASCADE · not indexedbatch_spec_workspace_execution_jobs.batch_spec_workspace_id → batch_spec_workspaces.id — one batch_spec_workspaces, many batch_spec_workspace_execution_jobs · required · ON DELETE CASCADE · indexedbatch_spec_workspace_execution_jobs.tenant_id → tenants.id — one tenants, many batch_spec_workspace_execution_jobs · optional · ON DELETE CASCADE · not indexedbatch_spec_workspace_execution_last_dequeues.tenant_id → tenants.id — one tenants, many batch_spec_workspace_execution_last_dequeues · optional · ON DELETE CASCADE · not indexedbatch_spec_workspace_execution_last_dequeues.user_id → users.id — one users, at most one batch_spec_workspace_execution_last_dequeues · required · ON DELETE CASCADE · indexedbatch_spec_workspace_files.batch_spec_id → batch_specs.id — one batch_specs, many batch_spec_workspace_files · required · ON DELETE CASCADE · indexedbatch_spec_workspace_files.tenant_id → tenants.id — one tenants, many batch_spec_workspace_files · optional · ON DELETE CASCADE · not indexedbatch_spec_workspaces.batch_spec_id → batch_specs.id — one batch_specs, many batch_spec_workspaces · required · ON DELETE CASCADE · indexedbatch_spec_workspaces.repo_id → repo.id — one repo, many batch_spec_workspaces · required · ON DELETE NO ACTION · not indexedbatch_spec_workspaces.tenant_id → tenants.id — one tenants, many batch_spec_workspaces · optional · ON DELETE CASCADE · not indexedbatch_specs.batch_change_id → batch_changes.id — one batch_changes, many batch_specs · optional · ON DELETE SET NULL · not indexedbatch_specs.tenant_id → tenants.id — one tenants, many batch_specs · optional · ON DELETE CASCADE · not indexedbatch_specs.user_id → users.id — one users, many batch_specs · optional · ON DELETE SET NULL · not indexedbatch_spec_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on batch_specs must scan batch_changes to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to batch_changes maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often batch_specs rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.creator_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan batch_changes to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to batch_changes maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.last_applier_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan batch_changes to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to batch_changes maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan batch_changes to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to batch_changes maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.creator_id — batch_changes.creator_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.last_applier_id — batch_changes.last_applier_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.namespace_org_id — batch_changes.namespace_org_id may be NULL, so the relationship to orgs is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.namespace_user_id — batch_changes.namespace_user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.tenant_id — batch_changes.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.creator_id, last_applier_id, namespace_org_id, namespace_user_id, tenant_id — batch_changes has several nullable FKs (creator_id, last_applier_id, namespace_org_id, namespace_user_id, tenant_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
name | text | NOT NULL | CHECK name ~ CAST('^[\w.-]+$' AS text) | ||
description | text | null | |||
creator_id | integer | null | users.id 1:N · SET NULL | ||
namespace_user_id | integer | null | users.id 1:N · CASCADE | ||
namespace_org_id | integer | null | orgs.id 1:N · CASCADE | ||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
closed_at | timestamptz | null | |||
batch_spec_id | bigint | NOT NULL | batch_specs.id 1:N | ||
last_applier_id | bigint | null | users.id 1:N · SET NULL | ||
last_applied_at | timestamptz | null | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Table checks: name ~ CAST('^[\w.-]+$' AS text); namespace_user_id IS NULL <> namespace_org_id IS NULL; name <> CAST('' AS text)
github_app_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on github_apps must scan batch_changes_site_credentials to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to batch_changes_site_credentials maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often github_apps rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan batch_changes_site_credentials to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to batch_changes_site_credentials maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.github_app_id — batch_changes_site_credentials.github_app_id may be NULL, so the relationship to github_apps is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.tenant_id — batch_changes_site_credentials.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.external_service_type — external_service_type is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.external_service_type, external_service_id — external_service_id points at different tables depending on external_service_type. No FK can express that, so orphans accumulate silently and every join needs a CASE. Acceptable for append-only audit data; painful anywhere the target must still exist.github_app_id, tenant_id — batch_changes_site_credentials has several nullable FKs (github_app_id, tenant_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
external_service_type | text | NOT NULL | |||
external_service_id | text | NOT NULL | |||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
credential | bytea | NOT NULL | |||
encryption_key_id | text | NOT NULL | CAST('' AS text) | ||
github_app_id | integer | null | github_apps.id 1:N · CASCADE | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Table checks: github_app_id IS NULL OR external_service_type = CAST('github' AS text)
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan batch_spec_execution_cache_entries to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to batch_spec_execution_cache_entries maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — batch_spec_execution_cache_entries.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
key | text | NOT NULL | |||
value | text | NOT NULL | |||
version | integer | NOT NULL | |||
last_used_at | timestamptz | null | |||
created_at | timestamptz | NOT NULL | now() | ||
user_id | integer | NOT NULL | users.id 1:N · CASCADE | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
initiator_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan batch_spec_resolution_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to batch_spec_resolution_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan batch_spec_resolution_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to batch_spec_resolution_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — batch_spec_resolution_jobs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.state — state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
batch_spec_id UK | integer | NOT NULL | batch_specs.id 1:1 · CASCADE | ||
state | text | NOT NULL | CAST('queued' AS text) | ||
failure_message | text | null | |||
started_at | timestamptz | null | |||
finished_at | timestamptz | null | |||
process_after | timestamptz | null | |||
num_resets | integer | NOT NULL | 0 | ||
num_failures | integer | NOT NULL | 0 | ||
execution_logs | json[] | null | |||
worker_hostname | text | NOT NULL | CAST('' AS text) | ||
last_heartbeat_at | timestamptz | null | |||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
queued_at | timestamptz | null | now() | ||
initiator_id | integer | NOT NULL | users.id 1:N · CASCADE | ||
cancel | boolean | NOT NULL | FALSE | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan batch_spec_workspace_execution_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to batch_spec_workspace_execution_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — batch_spec_workspace_execution_jobs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.state — state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
batch_spec_workspace_id | integer | NOT NULL | batch_spec_workspaces.id 1:N · CASCADE | ||
state | text | NOT NULL | CAST('queued' AS text) | ||
failure_message | text | null | |||
started_at | timestamptz | null | |||
finished_at | timestamptz | null | |||
process_after | timestamptz | null | |||
num_resets | integer | NOT NULL | 0 | ||
num_failures | integer | NOT NULL | 0 | ||
execution_logs | json[] | null | |||
worker_hostname | text | NOT NULL | CAST('' AS text) | ||
last_heartbeat_at | timestamptz | null | |||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
cancel | boolean | NOT NULL | FALSE | ||
queued_at | timestamptz | null | now() | ||
user_id | integer | NOT NULL | |||
version | integer | NOT NULL | 1 | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan batch_spec_workspace_execution_last_dequeues to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to batch_spec_workspace_execution_last_dequeues maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — batch_spec_workspace_execution_last_dequeues.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
user_id PK | integer | NOT NULL | users.id 1:1 · CASCADE | ||
latest_dequeue | timestamptz | null | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan batch_spec_workspace_files to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to batch_spec_workspace_files maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — batch_spec_workspace_files.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
rand_id | text | NOT NULL | |||
batch_spec_id | bigint | NOT NULL | batch_specs.id 1:N · CASCADE | ||
filename | text | NOT NULL | |||
path | text | NOT NULL | |||
size | bigint | NOT NULL | |||
content | bytea | NOT NULL | |||
modified_at | timestamptz | NOT NULL | |||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
repo_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on repo must scan batch_spec_workspaces to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to batch_spec_workspaces maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often repo rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan batch_spec_workspaces to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to batch_spec_workspaces maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — batch_spec_workspaces.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
batch_spec_id | integer | NOT NULL | batch_specs.id 1:N · CASCADE | ||
changeset_spec_ids | jsonb | NOT NULL | CAST('{}' AS jsonb) | ||
repo_id | integer | NOT NULL | repo.id 1:N | ||
branch | text | NOT NULL | |||
commit | text | NOT NULL | |||
path | text | NOT NULL | |||
file_matches | text[] | NOT NULL | |||
only_fetch_workspace | boolean | NOT NULL | FALSE | ||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
ignored | boolean | NOT NULL | FALSE | ||
unsupported | boolean | NOT NULL | FALSE | ||
skipped | boolean | NOT NULL | FALSE | ||
cached_result_found | boolean | NOT NULL | FALSE | ||
step_cache_results | jsonb | NOT NULL | CAST('{}' AS jsonb) | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
batch_change_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on batch_changes must scan batch_specs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to batch_specs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often batch_changes rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan batch_specs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to batch_specs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.user_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan batch_specs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to batch_specs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.batch_change_id — batch_specs.batch_change_id may be NULL, so the relationship to batch_changes is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.tenant_id — batch_specs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.user_id — batch_specs.user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.batch_change_id, tenant_id, user_id — batch_specs has several nullable FKs (batch_change_id, tenant_id, user_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
rand_id | text | NOT NULL | |||
raw_spec | text | NOT NULL | |||
spec | jsonb | NOT NULL | CAST('{}' AS jsonb) | ||
namespace_user_id | integer | null | |||
namespace_org_id | integer | null | |||
user_id | integer | null | users.id 1:N · SET NULL | ||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
created_from_raw | boolean | NOT NULL | FALSE | ||
allow_unsupported | boolean | NOT NULL | FALSE | ||
allow_ignored | boolean | NOT NULL | FALSE | ||
no_cache | boolean | NOT NULL | FALSE | ||
batch_change_id | bigint | null | batch_changes.id 1:N · SET NULL | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Table checks: namespace_user_id IS NULL <> namespace_org_id IS NULL
Tables whose names start with changeset_.
changeset_specs.batch_spec_id → batch_specs.id — one batch_specs, many changeset_specs · optional · ON DELETE CASCADE · indexedchangeset_specs.repo_id → repo.id — one repo, many changeset_specs · required · ON DELETE NO ACTION · not indexedchangeset_specs.tenant_id → tenants.id — one tenants, many changeset_specs · optional · ON DELETE CASCADE · not indexedchangeset_specs.user_id → users.id — one users, many changeset_specs · optional · ON DELETE SET NULL · not indexedchangeset_events.changeset_id → changesets.id — one changesets, many changeset_events · required · ON DELETE CASCADE · indexedchangeset_events.tenant_id → tenants.id — one tenants, many changeset_events · optional · ON DELETE CASCADE · not indexedchangeset_jobs.batch_change_id → batch_changes.id — one batch_changes, many changeset_jobs · required · ON DELETE CASCADE · not indexedchangeset_jobs.changeset_id → changesets.id — one changesets, many changeset_jobs · required · ON DELETE CASCADE · not indexedchangeset_jobs.tenant_id → tenants.id — one tenants, many changeset_jobs · optional · ON DELETE CASCADE · not indexedchangeset_jobs.user_id → users.id — one users, many changeset_jobs · required · ON DELETE CASCADE · not indexedrepo_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on repo must scan changeset_specs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to changeset_specs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often repo rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan changeset_specs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to changeset_specs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.user_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan changeset_specs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to changeset_specs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.batch_spec_id — changeset_specs.batch_spec_id may be NULL, so the relationship to batch_specs is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.tenant_id — changeset_specs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.user_id — changeset_specs.user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.type — type is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.batch_spec_id, tenant_id, user_id — changeset_specs has several nullable FKs (batch_spec_id, tenant_id, user_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
rand_id | text | NOT NULL | |||
spec | jsonb | null | CAST('{}' AS jsonb) | ||
batch_spec_id | bigint | null | batch_specs.id 1:N · CASCADE | ||
repo_id | integer | NOT NULL | repo.id 1:N | ||
user_id | integer | null | users.id 1:N · SET NULL | ||
diff_stat_added | integer | null | |||
diff_stat_deleted | integer | null | |||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
head_ref | text | null | |||
title | text | null | |||
external_id | text | null | |||
fork_namespace | citext | null | |||
diff | bytea | null | |||
base_rev | text | null | |||
base_ref | text | null | |||
body | text | null | |||
published | text | null | CHECK published = CAST('true' AS text) OR published = CAST('false' AS text) OR published = CAST('"draft"' AS text) OR published IS NULL | ||
commit_message | text | null | |||
commit_author_name | text | null | |||
commit_author_email | text | null | |||
type | text | NOT NULL | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Table checks: published = CAST('true' AS text) OR published = CAST('false' AS text) OR published = CAST('"draft"' AS text) OR published IS NULL
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan changeset_events to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to changeset_events maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — changeset_events.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
changeset_id | bigint | NOT NULL | changesets.id 1:N · CASCADE | ||
kind | text | NOT NULL | CHECK kind <> CAST('' AS text) | ||
key | text | NOT NULL | CHECK key <> CAST('' AS text) | ||
created_at | timestamptz | NOT NULL | now() | ||
metadata | jsonb | NOT NULL | CAST('{}' AS jsonb) | CHECK jsonb_typeof(metadata) = CAST('object' AS text) | |
updated_at | timestamptz | NOT NULL | now() | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Table checks: key <> CAST('' AS text); kind <> CAST('' AS text); jsonb_typeof(metadata) = CAST('object' AS text)
batch_change_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on batch_changes must scan changeset_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to changeset_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often batch_changes rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.changeset_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on changesets must scan changeset_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to changeset_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often changesets rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan changeset_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to changeset_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.user_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan changeset_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to changeset_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — changeset_jobs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.job_type — job_type is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.state — state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
bulk_group | text | NOT NULL | |||
user_id | integer | NOT NULL | users.id 1:N · CASCADE | ||
batch_change_id | integer | NOT NULL | batch_changes.id 1:N · CASCADE | ||
changeset_id | integer | NOT NULL | changesets.id 1:N · CASCADE | ||
job_type | text | NOT NULL | |||
payload | jsonb | null | CAST('{}' AS jsonb) | CHECK jsonb_typeof(payload) = CAST('object' AS text) | |
state | text | NOT NULL | CAST('queued' AS text) | ||
failure_message | text | null | |||
started_at | timestamptz | null | |||
finished_at | timestamptz | null | |||
process_after | timestamptz | null | |||
num_resets | integer | NOT NULL | 0 | ||
num_failures | integer | NOT NULL | 0 | ||
execution_logs | json[] | null | |||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
worker_hostname | text | NOT NULL | CAST('' AS text) | ||
last_heartbeat_at | timestamptz | null | |||
queued_at | timestamptz | null | now() | ||
cancel | boolean | NOT NULL | FALSE | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Table checks: jsonb_typeof(payload) = CAST('object' AS text)
Tables whose names start with repo_.
repo.tenant_id → tenants.id — one tenants, many repo · optional · ON DELETE CASCADE · not indexedrepo_commits_changelists.repo_id → repo.id — one repo, many repo_commits_changelists · required · ON DELETE CASCADE · indexedrepo_commits_changelists.tenant_id → tenants.id — one tenants, many repo_commits_changelists · optional · ON DELETE CASCADE · not indexedrepo_embedding_job_stats.job_id → repo_embedding_jobs.id — one repo_embedding_jobs, at most one repo_embedding_job_stats · required · ON DELETE CASCADE · indexedrepo_embedding_job_stats.tenant_id → tenants.id — one tenants, many repo_embedding_job_stats · optional · ON DELETE CASCADE · not indexedrepo_embedding_jobs.tenant_id → tenants.id — one tenants, many repo_embedding_jobs · optional · ON DELETE CASCADE · not indexedrepo_kvps.repo_id → repo.id — one repo, many repo_kvps · required · ON DELETE CASCADE · indexedrepo_kvps.tenant_id → tenants.id — one tenants, many repo_kvps · optional · ON DELETE CASCADE · not indexedrepo_paths.parent_id → repo_paths.id — one repo_paths, many repo_paths · optional · ON DELETE NO ACTION · not indexedrepo_paths.repo_id → repo.id — one repo, many repo_paths · required · ON DELETE CASCADE · indexedrepo_paths.tenant_id → tenants.id — one tenants, many repo_paths · optional · ON DELETE CASCADE · not indexedrepo_pending_permissions.tenant_id → tenants.id — one tenants, many repo_pending_permissions · optional · ON DELETE CASCADE · not indexedrepo_permissions.tenant_id → tenants.id — one tenants, many repo_permissions · optional · ON DELETE CASCADE · not indexedrepo_statistics.tenant_id → tenants.id — one tenants, many repo_statistics · optional · ON DELETE CASCADE · not indexedtenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan repo to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to repo maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — repo.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.external_service_type — external_service_type is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.external_service_type, external_service_id, external_id — repo soft-deletes via deleted_at, but (external_service_type, external_service_id, external_id) is unique across live AND deleted rows. A user who deletes their account can never sign up again with the same value, and ON CONFLICT upserts will resurrect ghosts.name — repo soft-deletes via deleted_at, but (name) is unique across live AND deleted rows. A user who deletes their account can never sign up again with the same value, and ON CONFLICT upserts will resurrect ghosts.external_service_type, external_service_id — external_service_id points at different tables depending on external_service_type. No FK can express that, so orphans accumulate silently and every join needs a CASE. Acceptable for append-only audit data; painful anywhere the target must still exist.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
name UK | citext | NOT NULL | CHECK name <> CAST('' AS citext) | ||
description | text | null | |||
fork | boolean | NOT NULL | FALSE | ||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | null | |||
external_id | text | null | |||
external_service_type | text | null | |||
external_service_id | text | null | |||
archived | boolean | NOT NULL | FALSE | ||
uri | citext | null | |||
deleted_at | timestamptz | null | |||
metadata | jsonb | NOT NULL | CAST('{}' AS jsonb) | CHECK jsonb_typeof(metadata) = CAST('object' AS text) | |
private | boolean | NOT NULL | FALSE | ||
stars | integer | NOT NULL | 0 | ||
blocked | jsonb | null | |||
topics | text[] | null | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Table checks: name <> CAST('' AS citext); jsonb_typeof(metadata) = CAST('object' AS text)
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan repo_commits_changelists to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to repo_commits_changelists maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — repo_commits_changelists.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
repo_id | integer | NOT NULL | repo.id 1:N · CASCADE | ||
commit_sha | bytea | NOT NULL | |||
perforce_changelist_id | integer | NOT NULL | |||
created_at | timestamptz | NOT NULL | now() | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan repo_embedding_job_stats to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to repo_embedding_job_stats maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — repo_embedding_job_stats.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
job_id PK | integer | NOT NULL | repo_embedding_jobs.id 1:1 · CASCADE | ||
is_incremental | boolean | NOT NULL | FALSE | ||
code_files_total | integer | NOT NULL | 0 | ||
code_files_embedded | integer | NOT NULL | 0 | ||
code_chunks_embedded | integer | NOT NULL | 0 | ||
code_files_skipped | jsonb | NOT NULL | CAST('{}' AS jsonb) | ||
code_bytes_embedded | bigint | NOT NULL | 0 | ||
text_files_total | integer | NOT NULL | 0 | ||
text_files_embedded | integer | NOT NULL | 0 | ||
text_chunks_embedded | integer | NOT NULL | 0 | ||
text_files_skipped | jsonb | NOT NULL | CAST('{}' AS jsonb) | ||
text_bytes_embedded | bigint | NOT NULL | 0 | ||
code_chunks_excluded | integer | NOT NULL | 0 | ||
text_chunks_excluded | integer | NOT NULL | 0 | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan repo_embedding_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to repo_embedding_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — repo_embedding_jobs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.state — state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
state | text | null | CAST('queued' AS text) | ||
failure_message | text | null | |||
queued_at | timestamptz | null | now() | ||
started_at | timestamptz | null | |||
finished_at | timestamptz | null | |||
process_after | timestamptz | null | |||
num_resets | integer | NOT NULL | 0 | ||
num_failures | integer | NOT NULL | 0 | ||
last_heartbeat_at | timestamptz | null | |||
execution_logs | json[] | null | |||
worker_hostname | text | NOT NULL | CAST('' AS text) | ||
cancel | boolean | NOT NULL | FALSE | ||
repo_id | integer | NOT NULL | |||
revision | text | NOT NULL | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan repo_kvps to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to repo_kvps maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — repo_kvps.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
repo_id PK | integer | NOT NULL | repo.id 1:N · CASCADE | ||
key PK | text | NOT NULL | |||
value | text | null | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
parent_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on repo_paths must scan repo_paths to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to repo_paths maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often repo_paths rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan repo_paths to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to repo_paths maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.parent_id — repo_paths.parent_id may be NULL, so the relationship to repo_paths is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.tenant_id — repo_paths.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.parent_id, tenant_id — repo_paths has several nullable FKs (parent_id, tenant_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.tree_files_counts_updated_at — tree_files_counts_updated_at stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
repo_id | integer | NOT NULL | repo.id 1:N · CASCADE | ||
absolute_path | text | NOT NULL | Absolute path does not start or end with forward slash. Example: "a/b/c". Root directory is empty path "". | ||
parent_id | integer | null | repo_paths.id 1:N | ||
tree_files_count | integer | null | Total count of files in the file tree rooted at the path. 1 for files. | ||
tree_files_counts_updated_at | timestamp | null | Timestamp of the job that updated the file counts | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan repo_pending_permissions to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to repo_pending_permissions maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — repo_pending_permissions.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
repo_id | integer | NOT NULL | |||
permission | text | NOT NULL | |||
updated_at | timestamptz | NOT NULL | |||
user_ids_ints | bigint[] | NOT NULL | CAST('{}' AS integer[]) | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan repo_permissions to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to repo_permissions maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — repo_permissions.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
repo_id | integer | NOT NULL | |||
permission | text | NOT NULL | |||
updated_at | timestamptz | NOT NULL | |||
synced_at | timestamptz | null | |||
user_ids_ints | integer[] | NOT NULL | CAST('{}' AS integer[]) | ||
unrestricted | boolean | NOT NULL | FALSE | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan repo_statistics to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to repo_statistics maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — repo_statistics.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
total | bigint | NOT NULL | 0 | Number of repositories that are not soft-deleted and not blocked | |
soft_deleted | bigint | NOT NULL | 0 | Number of repositories that are soft-deleted and not blocked | |
not_cloned | bigint | NOT NULL | 0 | Number of repositories that are NOT soft-deleted and not blocked and not cloned by gitserver | |
cloning | bigint | NOT NULL | 0 | Number of repositories that are NOT soft-deleted and not blocked and currently being cloned by gitserver | |
cloned | bigint | NOT NULL | 0 | Number of repositories that are NOT soft-deleted and not blocked and cloned by gitserver | |
failed_fetch | bigint | NOT NULL | 0 | Number of repositories that are NOT soft-deleted and not blocked and have last_error set in gitserver_repos table | |
corrupted | bigint | NOT NULL | 0 | Number of repositories that are NOT soft-deleted and not blocked and have corrupted_at set in gitserver_repos table | |
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Tables whose names start with cm_.
cm_action_jobs.email → cm_emails.id — one cm_emails, many cm_action_jobs · optional · ON DELETE CASCADE · not indexedcm_action_jobs.slack_webhook → cm_slack_webhooks.id — one cm_slack_webhooks, many cm_action_jobs · optional · ON DELETE CASCADE · not indexedcm_action_jobs.tenant_id → tenants.id — one tenants, many cm_action_jobs · optional · ON DELETE CASCADE · not indexedcm_action_jobs.trigger_event → cm_trigger_jobs.id — one cm_trigger_jobs, many cm_action_jobs · optional · ON DELETE CASCADE · indexedcm_action_jobs.webhook → cm_webhooks.id — one cm_webhooks, many cm_action_jobs · optional · ON DELETE CASCADE · not indexedcm_emails.changed_by → users.id — one users, many cm_emails · required · ON DELETE CASCADE · not indexedcm_emails.created_by → users.id — one users, many cm_emails · required · ON DELETE CASCADE · not indexedcm_emails.monitor → cm_monitors.id — one cm_monitors, many cm_emails · required · ON DELETE CASCADE · not indexedcm_emails.tenant_id → tenants.id — one tenants, many cm_emails · optional · ON DELETE CASCADE · not indexedcm_last_searched.monitor_id → cm_monitors.id — one cm_monitors, many cm_last_searched · required · ON DELETE CASCADE · indexedcm_last_searched.repo_id → repo.id — one repo, many cm_last_searched · required · ON DELETE CASCADE · not indexedcm_last_searched.tenant_id → tenants.id — one tenants, many cm_last_searched · optional · ON DELETE CASCADE · not indexedcm_monitors.changed_by → users.id — one users, many cm_monitors · required · ON DELETE CASCADE · not indexedcm_monitors.created_by → users.id — one users, many cm_monitors · required · ON DELETE CASCADE · not indexedcm_monitors.namespace_org_id → orgs.id — one orgs, many cm_monitors · optional · ON DELETE CASCADE · not indexedcm_monitors.tenant_id → tenants.id — one tenants, many cm_monitors · optional · ON DELETE CASCADE · not indexedcm_monitors.namespace_user_id → users.id — one users, many cm_monitors · required · ON DELETE CASCADE · not indexedcm_queries.tenant_id → tenants.id — one tenants, many cm_queries · optional · ON DELETE CASCADE · not indexedcm_queries.changed_by → users.id — one users, many cm_queries · required · ON DELETE CASCADE · not indexedcm_queries.created_by → users.id — one users, many cm_queries · required · ON DELETE CASCADE · not indexedcm_queries.monitor → cm_monitors.id — one cm_monitors, many cm_queries · required · ON DELETE CASCADE · not indexedcm_recipients.email → cm_emails.id — one cm_emails, many cm_recipients · required · ON DELETE CASCADE · not indexedcm_recipients.namespace_org_id → orgs.id — one orgs, many cm_recipients · optional · ON DELETE CASCADE · not indexedcm_recipients.tenant_id → tenants.id — one tenants, many cm_recipients · optional · ON DELETE CASCADE · not indexedcm_recipients.namespace_user_id → users.id — one users, many cm_recipients · optional · ON DELETE CASCADE · not indexedcm_slack_webhooks.changed_by → users.id — one users, many cm_slack_webhooks · required · ON DELETE CASCADE · not indexedcm_slack_webhooks.created_by → users.id — one users, many cm_slack_webhooks · required · ON DELETE CASCADE · not indexedcm_slack_webhooks.monitor → cm_monitors.id — one cm_monitors, many cm_slack_webhooks · required · ON DELETE CASCADE · indexedcm_slack_webhooks.tenant_id → tenants.id — one tenants, many cm_slack_webhooks · optional · ON DELETE CASCADE · not indexedcm_trigger_jobs.query → cm_queries.id — one cm_queries, many cm_trigger_jobs · required · ON DELETE CASCADE · not indexedcm_trigger_jobs.tenant_id → tenants.id — one tenants, many cm_trigger_jobs · optional · ON DELETE CASCADE · not indexedcm_webhooks.changed_by → users.id — one users, many cm_webhooks · required · ON DELETE CASCADE · not indexedcm_webhooks.created_by → users.id — one users, many cm_webhooks · required · ON DELETE CASCADE · not indexedcm_webhooks.monitor → cm_monitors.id — one cm_monitors, many cm_webhooks · required · ON DELETE CASCADE · indexedcm_webhooks.tenant_id → tenants.id — one tenants, many cm_webhooks · optional · ON DELETE CASCADE · not indexedemail — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on cm_emails must scan cm_action_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_action_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often cm_emails rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.slack_webhook — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on cm_slack_webhooks must scan cm_action_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_action_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often cm_slack_webhooks rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan cm_action_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_action_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.webhook — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on cm_webhooks must scan cm_action_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_action_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often cm_webhooks rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.email — cm_action_jobs.email may be NULL, so the relationship to cm_emails is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.slack_webhook — cm_action_jobs.slack_webhook may be NULL, so the relationship to cm_slack_webhooks is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.tenant_id — cm_action_jobs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.trigger_event — cm_action_jobs.trigger_event may be NULL, so the relationship to cm_trigger_jobs is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.webhook — cm_action_jobs.webhook may be NULL, so the relationship to cm_webhooks is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.state — state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.email, slack_webhook, tenant_id, trigger_event, webhook — cm_action_jobs has several nullable FKs (email, slack_webhook, tenant_id, trigger_event, webhook) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
email | bigint | null | cm_emails.id 1:N · CASCADE | The ID of the cm_emails action to execute if this is an email job. Mutually exclusive with webhook and slack_webhook | |
state | text | null | CAST('queued' AS text) | ||
failure_message | text | null | |||
started_at | timestamptz | null | |||
finished_at | timestamptz | null | |||
process_after | timestamptz | null | |||
num_resets | integer | NOT NULL | 0 | ||
num_failures | integer | NOT NULL | 0 | ||
log_contents | text | null | |||
trigger_event | integer | null | cm_trigger_jobs.id 1:N · CASCADE | ||
worker_hostname | text | NOT NULL | CAST('' AS text) | ||
last_heartbeat_at | timestamptz | null | |||
execution_logs | json[] | null | |||
webhook | bigint | null | cm_webhooks.id 1:N · CASCADE | The ID of the cm_webhooks action to execute if this is a webhook job. Mutually exclusive with email and slack_webhook | |
slack_webhook | bigint | null | cm_slack_webhooks.id 1:N · CASCADE | The ID of the cm_slack_webhook action to execute if this is a slack webhook job. Mutually exclusive with email and webhook | |
queued_at | timestamptz | null | now() | ||
cancel | boolean | NOT NULL | FALSE | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Table checks: ((CASE WHEN email IS NULL THEN 0 ELSE 1 END + CASE WHEN webhook IS NULL THEN 0 ELSE 1 END) + CASE WHEN slack_webhook IS NULL THEN 0 ELSE 1 END) = 1
changed_by — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan cm_emails to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_emails maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.created_by — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan cm_emails to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_emails maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.monitor — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on cm_monitors must scan cm_emails to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_emails maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often cm_monitors rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan cm_emails to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_emails maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — cm_emails.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
monitor | bigint | NOT NULL | cm_monitors.id 1:N · CASCADE | ||
enabled | boolean | NOT NULL | |||
priority | cm_email_priority | NOT NULL | |||
header | text | NOT NULL | |||
created_by | integer | NOT NULL | users.id 1:N · CASCADE | ||
created_at | timestamptz | NOT NULL | now() | ||
changed_by | integer | NOT NULL | users.id 1:N · CASCADE | ||
changed_at | timestamptz | NOT NULL | now() | ||
include_results | boolean | NOT NULL | FALSE | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
The last searched commit hashes for the given code monitor and unique set of search arguments
repo_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on repo must scan cm_last_searched to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_last_searched maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often repo rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan cm_last_searched to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_last_searched maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — cm_last_searched.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
monitor_id PK | bigint | NOT NULL | cm_monitors.id 1:N · CASCADE | ||
commit_oids | text[] | NOT NULL | The set of commit OIDs that was previously successfully searched and should be excluded on the next run | ||
repo_id PK | integer | NOT NULL | repo.id 1:N · CASCADE | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
changed_by — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan cm_monitors to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_monitors maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.created_by — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan cm_monitors to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_monitors maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.namespace_org_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on orgs must scan cm_monitors to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_monitors maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often orgs rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan cm_monitors to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_monitors maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.namespace_user_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan cm_monitors to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_monitors maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.namespace_org_id — cm_monitors.namespace_org_id may be NULL, so the relationship to orgs is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.tenant_id — cm_monitors.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.namespace_org_id, tenant_id — cm_monitors has several nullable FKs (namespace_org_id, tenant_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
created_by | integer | NOT NULL | users.id 1:N · CASCADE | ||
created_at | timestamptz | NOT NULL | now() | ||
description | text | NOT NULL | |||
changed_at | timestamptz | NOT NULL | now() | ||
changed_by | integer | NOT NULL | users.id 1:N · CASCADE | ||
enabled | boolean | NOT NULL | TRUE | ||
namespace_user_id | integer | NOT NULL | users.id 1:N · CASCADE | ||
namespace_org_id | integer | null | orgs.id 1:N · CASCADE | DEPRECATED: code monitors cannot be owned by an org | |
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan cm_queries to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_queries maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.changed_by — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan cm_queries to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_queries maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.created_by — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan cm_queries to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_queries maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.monitor — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on cm_monitors must scan cm_queries to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_queries maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often cm_monitors rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — cm_queries.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
monitor | bigint | NOT NULL | cm_monitors.id 1:N · CASCADE | ||
query | text | NOT NULL | |||
created_by | integer | NOT NULL | users.id 1:N · CASCADE | ||
created_at | timestamptz | NOT NULL | now() | ||
changed_by | integer | NOT NULL | users.id 1:N · CASCADE | ||
changed_at | timestamptz | NOT NULL | now() | ||
next_run | timestamptz | null | now() | ||
latest_result | timestamptz | null | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
email — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on cm_emails must scan cm_recipients to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_recipients maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often cm_emails rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.namespace_org_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on orgs must scan cm_recipients to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_recipients maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often orgs rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan cm_recipients to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_recipients maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.namespace_user_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan cm_recipients to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_recipients maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.namespace_org_id — cm_recipients.namespace_org_id may be NULL, so the relationship to orgs is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.tenant_id — cm_recipients.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.namespace_user_id — cm_recipients.namespace_user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.namespace_org_id, tenant_id, namespace_user_id — cm_recipients has several nullable FKs (namespace_org_id, tenant_id, namespace_user_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
email | bigint | NOT NULL | cm_emails.id 1:N · CASCADE | ||
namespace_user_id | integer | null | users.id 1:N · CASCADE | ||
namespace_org_id | integer | null | orgs.id 1:N · CASCADE | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Slack webhook actions configured on code monitors
changed_by — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan cm_slack_webhooks to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_slack_webhooks maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.created_by — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan cm_slack_webhooks to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_slack_webhooks maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan cm_slack_webhooks to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_slack_webhooks maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — cm_slack_webhooks.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
monitor | bigint | NOT NULL | cm_monitors.id 1:N · CASCADE | The code monitor that the action is defined on | |
url | text | NOT NULL | The Slack webhook URL we send the code monitor event to | ||
enabled | boolean | NOT NULL | |||
created_by | integer | NOT NULL | users.id 1:N · CASCADE | ||
created_at | timestamptz | NOT NULL | now() | ||
changed_by | integer | NOT NULL | users.id 1:N · CASCADE | ||
changed_at | timestamptz | NOT NULL | now() | ||
include_results | boolean | NOT NULL | FALSE | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
query — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on cm_queries must scan cm_trigger_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_trigger_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often cm_queries rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan cm_trigger_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_trigger_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — cm_trigger_jobs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.state — state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
query | bigint | NOT NULL | cm_queries.id 1:N · CASCADE | ||
state | text | null | CAST('queued' AS text) | ||
failure_message | text | null | |||
started_at | timestamptz | null | |||
finished_at | timestamptz | null | |||
process_after | timestamptz | null | |||
num_resets | integer | NOT NULL | 0 | ||
num_failures | integer | NOT NULL | 0 | ||
log_contents | text | null | |||
query_string | text | null | |||
worker_hostname | text | NOT NULL | CAST('' AS text) | ||
last_heartbeat_at | timestamptz | null | |||
execution_logs | json[] | null | |||
search_results | jsonb | null | CHECK jsonb_typeof(search_results) = CAST('array' AS text) | ||
queued_at | timestamptz | null | now() | ||
cancel | boolean | NOT NULL | FALSE | ||
logs | json[] | null | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Table checks: jsonb_typeof(search_results) = CAST('array' AS text)
Webhook actions configured on code monitors
changed_by — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan cm_webhooks to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_webhooks maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.created_by — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan cm_webhooks to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_webhooks maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan cm_webhooks to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cm_webhooks maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — cm_webhooks.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
monitor | bigint | NOT NULL | cm_monitors.id 1:N · CASCADE | The code monitor that the action is defined on | |
url | text | NOT NULL | The webhook URL we send the code monitor event to | ||
enabled | boolean | NOT NULL | Whether this Slack webhook action is enabled. When not enabled, the action will not be run when its code monitor generates events | ||
created_by | integer | NOT NULL | users.id 1:N · CASCADE | ||
created_at | timestamptz | NOT NULL | now() | ||
changed_by | integer | NOT NULL | users.id 1:N · CASCADE | ||
changed_at | timestamptz | NOT NULL | now() | ||
include_results | boolean | NOT NULL | FALSE | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Tables whose names start with codeintel_.
codeintel_autoindex_queue.tenant_id → tenants.id — one tenants, many codeintel_autoindex_queue · optional · ON DELETE CASCADE · not indexedcodeintel_autoindexing_exceptions.repository_id → repo.id — one repo, at most one codeintel_autoindexing_exceptions · required · ON DELETE CASCADE · indexedcodeintel_autoindexing_exceptions.tenant_id → tenants.id — one tenants, many codeintel_autoindexing_exceptions · optional · ON DELETE CASCADE · not indexedcodeintel_commit_dates.tenant_id → tenants.id — one tenants, many codeintel_commit_dates · optional · ON DELETE CASCADE · not indexedcodeintel_inference_scripts.tenant_id → tenants.id — one tenants, many codeintel_inference_scripts · optional · ON DELETE CASCADE · not indexedcodeintel_initial_path_ranks.exported_upload_id → codeintel_ranking_exports.id — one codeintel_ranking_exports, many codeintel_initial_path_ranks · required · ON DELETE CASCADE · indexedcodeintel_initial_path_ranks.tenant_id → tenants.id — one tenants, many codeintel_initial_path_ranks · optional · ON DELETE CASCADE · not indexedcodeintel_initial_path_ranks_processed.tenant_id → tenants.id — one tenants, many codeintel_initial_path_ranks_processed · optional · ON DELETE CASCADE · not indexedcodeintel_initial_path_ranks_processed.codeintel_initial_path_ranks_id → codeintel_initial_path_ranks.id — one codeintel_initial_path_ranks, many codeintel_initial_path_ranks_processed · required · ON DELETE CASCADE · indexedcodeintel_langugage_support_requests.tenant_id → tenants.id — one tenants, many codeintel_langugage_support_requests · optional · ON DELETE CASCADE · not indexedcodeintel_path_ranks.tenant_id → tenants.id — one tenants, many codeintel_path_ranks · optional · ON DELETE CASCADE · not indexedcodeintel_ranking_definitions.exported_upload_id → codeintel_ranking_exports.id — one codeintel_ranking_exports, many codeintel_ranking_definitions · required · ON DELETE CASCADE · indexedcodeintel_ranking_definitions.tenant_id → tenants.id — one tenants, many codeintel_ranking_definitions · optional · ON DELETE CASCADE · not indexedcodeintel_ranking_exports.tenant_id → tenants.id — one tenants, many codeintel_ranking_exports · optional · ON DELETE CASCADE · not indexedcodeintel_ranking_exports.upload_id → lsif_uploads.id — one lsif_uploads, many codeintel_ranking_exports · optional · ON DELETE SET NULL · not indexedcodeintel_ranking_graph_keys.tenant_id → tenants.id — one tenants, many codeintel_ranking_graph_keys · optional · ON DELETE CASCADE · not indexedcodeintel_ranking_path_counts_inputs.tenant_id → tenants.id — one tenants, many codeintel_ranking_path_counts_inputs · optional · ON DELETE CASCADE · not indexedcodeintel_ranking_progress.tenant_id → tenants.id — one tenants, many codeintel_ranking_progress · optional · ON DELETE CASCADE · not indexedcodeintel_ranking_references.exported_upload_id → codeintel_ranking_exports.id — one codeintel_ranking_exports, many codeintel_ranking_references · required · ON DELETE CASCADE · indexedcodeintel_ranking_references.tenant_id → tenants.id — one tenants, many codeintel_ranking_references · optional · ON DELETE CASCADE · not indexedcodeintel_ranking_references_processed.tenant_id → tenants.id — one tenants, many codeintel_ranking_references_processed · optional · ON DELETE CASCADE · not indexedcodeintel_ranking_references_processed.codeintel_ranking_reference_id → codeintel_ranking_references.id — one codeintel_ranking_references, many codeintel_ranking_references_processed · required · ON DELETE CASCADE · indexedtenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan codeintel_autoindex_queue to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to codeintel_autoindex_queue maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — codeintel_autoindex_queue.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
repository_id | integer | NOT NULL | |||
rev | text | NOT NULL | |||
queued_at | timestamptz | NOT NULL | now() | ||
processed_at | timestamptz | null | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan codeintel_autoindexing_exceptions to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to codeintel_autoindexing_exceptions maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — codeintel_autoindexing_exceptions.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
repository_id UK | integer | NOT NULL | repo.id 1:1 · CASCADE | ||
disable_scheduling | boolean | NOT NULL | FALSE | ||
disable_inference | boolean | NOT NULL | FALSE | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Maps commits within a repository to the commit date as reported by gitserver.
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan codeintel_commit_dates to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to codeintel_commit_dates maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — codeintel_commit_dates.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
repository_id PK | integer | NOT NULL | Identifies a row in the `repo` table. | ||
commit_bytea PK | bytea | NOT NULL | Identifies the 40-character commit hash. | ||
committed_at | timestamptz | null | The commit date (may be -infinity if unresolvable). | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Contains auto-index job inference Lua scripts as an alternative to setting via environment variables.
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan codeintel_inference_scripts to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to codeintel_inference_scripts maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — codeintel_inference_scripts.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
insert_timestamp | timestamptz | NOT NULL | now() | ||
script | text | NOT NULL | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan codeintel_initial_path_ranks to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to codeintel_initial_path_ranks maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — codeintel_initial_path_ranks.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
document_path | text | NOT NULL | CAST('' AS text) | ||
graph_key | text | NOT NULL | |||
document_paths | text[] | NOT NULL | CAST('{}' AS text[]) | ||
exported_upload_id | integer | NOT NULL | codeintel_ranking_exports.id 1:N · CASCADE | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan codeintel_initial_path_ranks_processed to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to codeintel_initial_path_ranks_processed maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — codeintel_initial_path_ranks_processed.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
graph_key | text | NOT NULL | |||
codeintel_initial_path_ranks_id | bigint | NOT NULL | codeintel_initial_path_ranks.id 1:N · CASCADE | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan codeintel_langugage_support_requests to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to codeintel_langugage_support_requests maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — codeintel_langugage_support_requests.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id | integer | NOT NULL | |||
user_id | integer | NOT NULL | |||
language_id | text | NOT NULL | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan codeintel_path_ranks to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to codeintel_path_ranks maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — codeintel_path_ranks.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
repository_id | integer | NOT NULL | |||
payload | jsonb | NOT NULL | |||
updated_at | timestamptz | NOT NULL | now() | ||
graph_key | text | NOT NULL | |||
num_paths | integer | null | |||
refcount_logsum | double precision | null | |||
id PK | bigint | NOT NULL | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan codeintel_ranking_definitions to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to codeintel_ranking_definitions maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — codeintel_ranking_definitions.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
symbol_name | text | NOT NULL | |||
document_path | text | NOT NULL | |||
graph_key | text | NOT NULL | |||
exported_upload_id | integer | NOT NULL | codeintel_ranking_exports.id 1:N · CASCADE | ||
symbol_checksum | bytea | NOT NULL | CAST('\x' AS bytea) | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan codeintel_ranking_exports to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to codeintel_ranking_exports maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.upload_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on lsif_uploads must scan codeintel_ranking_exports to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to codeintel_ranking_exports maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often lsif_uploads rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — codeintel_ranking_exports.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.upload_id — codeintel_ranking_exports.upload_id may be NULL, so the relationship to lsif_uploads is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.graph_key, upload_id — codeintel_ranking_exports soft-deletes via deleted_at, but (graph_key, upload_id) is unique across live AND deleted rows. A user who deletes their account can never sign up again with the same value, and ON CONFLICT upserts will resurrect ghosts.tenant_id, upload_id — codeintel_ranking_exports has several nullable FKs (tenant_id, upload_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
upload_id | integer | null | lsif_uploads.id 1:N · SET NULL | ||
graph_key | text | NOT NULL | |||
locked_at | timestamptz | NOT NULL | now() | ||
id PK | integer | NOT NULL | |||
last_scanned_at | timestamptz | null | |||
deleted_at | timestamptz | null | |||
upload_key | text | null | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan codeintel_ranking_graph_keys to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to codeintel_ranking_graph_keys maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — codeintel_ranking_graph_keys.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
graph_key | text | NOT NULL | |||
created_at | timestamptz | null | now() | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan codeintel_ranking_path_counts_inputs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to codeintel_ranking_path_counts_inputs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — codeintel_ranking_path_counts_inputs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
count | integer | NOT NULL | |||
graph_key | text | NOT NULL | |||
processed | boolean | NOT NULL | FALSE | ||
definition_id | bigint | null | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan codeintel_ranking_progress to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to codeintel_ranking_progress maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — codeintel_ranking_progress.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
graph_key UK | text | NOT NULL | |||
mappers_started_at | timestamptz | NOT NULL | |||
mapper_completed_at | timestamptz | null | |||
seed_mapper_completed_at | timestamptz | null | |||
reducer_started_at | timestamptz | null | |||
reducer_completed_at | timestamptz | null | |||
num_path_records_total | integer | null | |||
num_reference_records_total | integer | null | |||
num_count_records_total | integer | null | |||
num_path_records_processed | integer | null | |||
num_reference_records_processed | integer | null | |||
num_count_records_processed | integer | null | |||
max_export_id | bigint | NOT NULL | |||
reference_cursor_export_deleted_at | timestamptz | null | |||
reference_cursor_export_id | integer | null | |||
path_cursor_deleted_export_at | timestamptz | null | |||
path_cursor_export_id | integer | null | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
References for a given upload proceduced by background job consuming SCIP indexes.
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan codeintel_ranking_references to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to codeintel_ranking_references maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — codeintel_ranking_references.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
symbol_names | text[] | NOT NULL | |||
graph_key | text | NOT NULL | |||
exported_upload_id | integer | NOT NULL | codeintel_ranking_exports.id 1:N · CASCADE | ||
symbol_checksums | bytea[] | NOT NULL | CAST('{}' AS bytea[]) | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan codeintel_ranking_references_processed to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to codeintel_ranking_references_processed maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — codeintel_ranking_references_processed.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
graph_key | text | NOT NULL | |||
codeintel_ranking_reference_id | integer | NOT NULL | codeintel_ranking_references.id 1:N · CASCADE | ||
id PK | bigint | NOT NULL | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Tables whose names start with lsif_.
lsif_dependency_indexing_jobs.upload_id → lsif_uploads.id — one lsif_uploads, many lsif_dependency_indexing_jobs · optional · ON DELETE CASCADE · not indexedlsif_dependency_syncing_jobs.upload_id → lsif_uploads.id — one lsif_uploads, many lsif_dependency_syncing_jobs · optional · ON DELETE CASCADE · indexedlsif_index_configuration.repository_id → repo.id — one repo, at most one lsif_index_configuration · required · ON DELETE CASCADE · indexedlsif_packages.dump_id → lsif_uploads.id — one lsif_uploads, many lsif_packages · required · ON DELETE CASCADE · indexedlsif_references.dump_id → lsif_uploads.id — one lsif_uploads, many lsif_references · required · ON DELETE CASCADE · indexedlsif_retention_configuration.repository_id → repo.id — one repo, at most one lsif_retention_configuration · required · ON DELETE CASCADE · indexedlsif_uploads_reference_counts.upload_id → lsif_uploads.id — one lsif_uploads, at most one lsif_uploads_reference_counts · required · ON DELETE CASCADE · indexedlsif_uploads_vulnerability_scan.upload_id → lsif_uploads.id — one lsif_uploads, at most one lsif_uploads_vulnerability_scan · required · ON DELETE CASCADE · indexedtype — type is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code. The comment lists The type of Git object (e.g., COMMIT, BRANCH, TAG)., i.e. the values are known.lsif_configuration_policies references nothing and nothing references it. Either it is a staging/log table (fine, say so), or it is dead, or it is the seed of a second data model growing beside the first.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
repository_id | integer | null | The identifier of the repository to which this configuration policy applies. If absent, this policy is applied globally. | ||
name | text | null | |||
type | text | NOT NULL | The type of Git object (e.g., COMMIT, BRANCH, TAG). | ||
pattern | text | NOT NULL | A pattern used to match` names of the associated Git object type. | ||
retention_enabled | boolean | NOT NULL | Whether or not this configuration policy affects data retention rules. | ||
retention_duration_hours | integer | null | The max age of data retained by this configuration policy. If null, the age is unbounded. | ||
retain_intermediate_commits | boolean | NOT NULL | If the matching Git object is a branch, setting this value to true will also retain all data used to resolve queries for any commit on the matching branches. Setting this value to false will only consider the tip of the branch. | ||
indexing_enabled | boolean | NOT NULL | Whether or not this configuration policy affects auto-indexing schedules. | ||
index_commit_max_age_hours | integer | null | The max age of commits indexed by this configuration policy. If null, the age is unbounded. | ||
index_intermediate_commits | boolean | NOT NULL | If the matching Git object is a branch, setting this value to true will also index all commits on the matching branches. Setting this value to false will only consider the tip of the branch. | ||
protected | boolean | NOT NULL | FALSE | Whether or not this configuration policy is protected from modification of its data retention behavior (except for duration). | |
repository_patterns | text[] | null | The name pattern matching repositories to which this configuration policy applies. If absent, all repositories are matched. | ||
last_resolved_at | timestamptz | null | |||
embeddings_enabled | boolean | NOT NULL | FALSE | ||
syntactic_indexing_enabled | boolean | NOT NULL | FALSE |
A lookup table to get all the repository patterns by repository id that apply to a configuration policy.
lsif_configuration_policies_repository_pattern_lookup references nothing and nothing references it. Either it is a staging/log table (fine, say so), or it is dead, or it is the seed of a second data model growing beside the first.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
policy_id PK | integer | NOT NULL | The policy identifier associated with the repository. | ||
repo_id PK | integer | NOT NULL | The repository identifier associated with the policy. |
upload_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on lsif_uploads must scan lsif_dependency_indexing_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to lsif_dependency_indexing_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often lsif_uploads rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.upload_id — lsif_dependency_indexing_jobs.upload_id may be NULL, so the relationship to lsif_uploads is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.state — state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.external_service_kind — external_service_kind is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code. The comment lists Filter the external services for this kind to wait to have synced. If empty, external_service_sync is ignored and no external services are polled for their last sync time., i.e. the values are known.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
state | text | NOT NULL | CAST('queued' AS text) | ||
failure_message | text | null | |||
queued_at | timestamptz | NOT NULL | now() | ||
started_at | timestamptz | null | |||
finished_at | timestamptz | null | |||
process_after | timestamptz | null | |||
num_resets | integer | NOT NULL | 0 | ||
num_failures | integer | NOT NULL | 0 | ||
execution_logs | json[] | null | |||
last_heartbeat_at | timestamptz | null | |||
worker_hostname | text | NOT NULL | CAST('' AS text) | ||
upload_id | integer | null | lsif_uploads.id 1:N · CASCADE | ||
external_service_kind | text | NOT NULL | CAST('' AS text) | Filter the external services for this kind to wait to have synced. If empty, external_service_sync is ignored and no external services are polled for their last sync time. | |
external_service_sync | timestamptz | null | The sync time after which external services of the given kind will have synced/created any repositories referenced by the LSIF upload that are resolvable. | ||
cancel | boolean | NOT NULL | FALSE |
Tracks jobs that scan imports of indexes to schedule auto-index jobs.
upload_id — lsif_dependency_syncing_jobs.upload_id may be NULL, so the relationship to lsif_uploads is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.state — state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
state | text | NOT NULL | CAST('queued' AS text) | ||
failure_message | text | null | |||
queued_at | timestamptz | NOT NULL | now() | ||
started_at | timestamptz | null | |||
finished_at | timestamptz | null | |||
process_after | timestamptz | null | |||
num_resets | integer | NOT NULL | 0 | ||
num_failures | integer | NOT NULL | 0 | ||
execution_logs | json[] | null | |||
upload_id | integer | null | lsif_uploads.id 1:N · CASCADE | The identifier of the triggering upload record. | |
worker_hostname | text | NOT NULL | CAST('' AS text) | ||
last_heartbeat_at | timestamptz | null | |||
cancel | boolean | NOT NULL | FALSE |
| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
name | text | NOT NULL | |||
scheme | text | NOT NULL | |||
blocked | boolean | NOT NULL | FALSE | ||
last_checked_at | timestamptz | null |
Stores whether or not the nearest upload data for a repository is out of date (when update_token > dirty_token).
lsif_dirty_repositories references nothing and nothing references it. Either it is a staging/log table (fine, say so), or it is dead, or it is the seed of a second data model growing beside the first.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
repository_id PK | integer | NOT NULL | |||
dirty_token | integer | NOT NULL | Set to the value of update_token visible to the transaction that updates the commit graph. Updates of dirty_token during this time will cause a second update. | ||
update_token | integer | NOT NULL | This value is incremented on each request to update the commit graph for the repository. | ||
updated_at | timestamptz | null | The time the update_token value was last updated. | ||
set_dirty_at | timestamptz | NOT NULL | now() |
Stores metadata about an LSIF index uploaded by a user.
state — state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.content_type — content_type is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code. The comment lists The content type of the upload record. For now, the default value is application/x-ndjson+lsif to backfill existing records. This will change as we remove LSIF support., i.e. the values are known.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | Used as a logical foreign key with the (disjoint) codeintel database. | ||
commit | text | NOT NULL | A 40-char revhash. Note that this commit may not be resolvable in the future.CHECK commit ~ CAST('^[a-z0-9]{40}$' AS text) | ||
root | text | NOT NULL | CAST('' AS text) | The path for which the index can resolve code intelligence relative to the repository root. | |
uploaded_at | timestamptz | NOT NULL | now() | ||
state | text | NOT NULL | CAST('queued' AS text) | ||
failure_message | text | null | |||
started_at | timestamptz | null | |||
finished_at | timestamptz | null | |||
repository_id | integer | NOT NULL | |||
indexer | text | NOT NULL | The name of the indexer that produced the index file. If not supplied by the user it will be pulled from the index metadata. | ||
num_parts | integer | NOT NULL | The number of parts src-cli split the upload file into. | ||
uploaded_parts | integer[] | NOT NULL | The index of parts that have been successfully uploaded. | ||
process_after | timestamptz | null | |||
num_resets | integer | NOT NULL | 0 | ||
upload_size | bigint | null | The size of the index file (in bytes). | ||
num_failures | integer | NOT NULL | 0 | ||
associated_index_id | bigint | null | |||
committed_at | timestamptz | null | |||
commit_last_checked_at | timestamptz | null | |||
worker_hostname | text | NOT NULL | CAST('' AS text) | ||
last_heartbeat_at | timestamptz | null | |||
execution_logs | json[] | null | |||
num_references | integer | null | Deprecated in favor of reference_count. | ||
expired | boolean | NOT NULL | FALSE | Whether or not this upload data is no longer protected by any data retention policy. | |
last_retention_scan_at | timestamptz | null | The last time this upload was checked against data retention policies. | ||
reference_count | integer | null | The number of references to this upload data from other upload records (via lsif_references). | ||
indexer_version | text | null | The version of the indexer that produced the index file. If not supplied by the user it will be pulled from the index metadata. | ||
queued_at | timestamptz | null | |||
cancel | boolean | NOT NULL | FALSE | ||
uncompressed_size | bigint | null | |||
last_referenced_scan_at | timestamptz | null | The last time this upload was known to be referenced by another (possibly expired) index. | ||
last_traversal_scan_at | timestamptz | null | The last time this upload was known to be reachable by a non-expired index. | ||
last_reconcile_at | timestamptz | null | |||
content_type | text | NOT NULL | CAST('application/x-ndjson+lsif' AS text) | The content type of the upload record. For now, the default value is `application/x-ndjson+lsif` to backfill existing records. This will change as we remove LSIF support. | |
should_reindex | boolean | NOT NULL | FALSE |
Table checks: commit ~ CAST('^[a-z0-9]{40}$' AS text)
Stores the configuration used for code intel index jobs for a repository.
| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
repository_id UK | integer | NOT NULL | repo.id 1:1 · CASCADE | ||
data | bytea | NOT NULL | The raw user-supplied [configuration](https://sourcegraph.com/github.com/sourcegraph/sourcegraph@3.23/-/blob/enterprise/internal/codeintel/autoindex/config/types.go#L3:6) (encoded in JSONC). | ||
autoindex_enabled | boolean | NOT NULL | TRUE | Whether or not auto-indexing should be attempted on this repo. Index jobs may be inferred from the repository contents if data is empty. |
Stores metadata about a code intel index job.
state — state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.lsif_indexes references nothing and nothing references it. Either it is a staging/log table (fine, say so), or it is dead, or it is the seed of a second data model growing beside the first.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
commit | text | NOT NULL | A 40-char revhash. Note that this commit may not be resolvable in the future.CHECK commit ~ CAST('^[a-z0-9]{40}$' AS text) | ||
queued_at | timestamptz | NOT NULL | now() | ||
state | text | NOT NULL | CAST('queued' AS text) | ||
failure_message | text | null | |||
started_at | timestamptz | null | |||
finished_at | timestamptz | null | |||
repository_id | integer | NOT NULL | |||
process_after | timestamptz | null | |||
num_resets | integer | NOT NULL | 0 | ||
num_failures | integer | NOT NULL | 0 | ||
docker_steps | jsonb[] | NOT NULL | An array of pre-index [steps](https://sourcegraph.com/github.com/sourcegraph/sourcegraph@3.23/-/blob/enterprise/internal/codeintel/stores/dbstore/docker_step.go#L9:6) to run. | ||
root | text | NOT NULL | The working directory of the indexer image relative to the repository root. | ||
indexer | text | NOT NULL | The docker image used to run the index command (e.g. sourcegraph/lsif-go). | ||
indexer_args | text[] | NOT NULL | The command run inside the indexer image to produce the index file (e.g. ['lsif-node', '-p', '.']) | ||
outfile | text | NOT NULL | The path to the index file produced by the index command relative to the working directory. | ||
log_contents | text | null | **Column deprecated in favor of execution_logs.** | ||
execution_logs | json[] | null | An array of [log entries](https://sourcegraph.com/github.com/sourcegraph/sourcegraph@3.23/-/blob/internal/workerutil/store.go#L48:6) (encoded as JSON) from the most recent execution. | ||
local_steps | text[] | NOT NULL | A list of commands to run inside the indexer image prior to running the indexer command. | ||
commit_last_checked_at | timestamptz | null | |||
worker_hostname | text | NOT NULL | CAST('' AS text) | ||
last_heartbeat_at | timestamptz | null | |||
cancel | boolean | NOT NULL | FALSE | ||
should_reindex | boolean | NOT NULL | FALSE | ||
requested_envvars | text[] | null | |||
enqueuer_user_id | integer | NOT NULL | 0 |
Table checks: commit ~ CAST('^[a-z0-9]{40}$' AS text)
Tracks the last time repository was checked for auto-indexing job scheduling.
lsif_last_index_scan references nothing and nothing references it. Either it is a staging/log table (fine, say so), or it is dead, or it is the seed of a second data model growing beside the first.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
repository_id PK | integer | NOT NULL | |||
last_index_scan_at | timestamptz | NOT NULL | The last time uploads of this repository were considered for auto-indexing job scheduling. |
Tracks the last time uploads a repository were checked against data retention policies.
lsif_last_retention_scan references nothing and nothing references it. Either it is a staging/log table (fine, say so), or it is dead, or it is the seed of a second data model growing beside the first.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
repository_id PK | integer | NOT NULL | |||
last_retention_scan_at | timestamptz | NOT NULL | The last time uploads of this repository were checked against data retention policies. |
Associates commits with the complete set of uploads visible from that commit. Every commit with upload data is present in this table.
lsif_nearest_uploads references nothing and nothing references it. Either it is a staging/log table (fine, say so), or it is dead, or it is the seed of a second data model growing beside the first.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
repository_id | integer | NOT NULL | |||
commit_bytea | bytea | NOT NULL | A 40-char revhash. Note that this commit may not be resolvable in the future. | ||
uploads | jsonb | NOT NULL | Encodes an {upload_id => distance} map that includes an entry for every upload visible from the commit. There is always at least one entry with a distance of zero. |
Associates commits with the closest ancestor commit with usable upload data. Together, this table and lsif_nearest_uploads cover all commits with resolvable code intelligence.
lsif_nearest_uploads_links references nothing and nothing references it. Either it is a staging/log table (fine, say so), or it is dead, or it is the seed of a second data model growing beside the first.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
repository_id | integer | NOT NULL | |||
commit_bytea | bytea | NOT NULL | A 40-char revhash. Note that this commit may not be resolvable in the future. | ||
ancestor_commit_bytea | bytea | NOT NULL | The 40-char revhash of the ancestor. Note that this commit may not be resolvable in the future. | ||
distance | integer | NOT NULL | The distance bewteen the commits. Parent = 1, Grandparent = 2, etc. |
Associates an upload with the set of packages they provide within a given packages management scheme.
| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
scheme | text | NOT NULL | The (export) moniker scheme. | ||
name | text | NOT NULL | The package name. | ||
version | text | null | The package version. | ||
dump_id | integer | NOT NULL | lsif_uploads.id 1:N · CASCADE | The identifier of the upload that provides the package. | |
manager | text | NOT NULL | CAST('' AS text) | The package manager name. |
Associates an upload with the set of packages they require within a given packages management scheme.
| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
scheme | text | NOT NULL | The (import) moniker scheme. | ||
name | text | NOT NULL | The package name. | ||
version | text | null | The package version. | ||
dump_id | integer | NOT NULL | lsif_uploads.id 1:N · CASCADE | The identifier of the upload that references the package. | |
manager | text | NOT NULL | CAST('' AS text) | The package manager name. |
Stores the retention policy of code intellience data for a repository.
| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
repository_id UK | integer | NOT NULL | repo.id 1:1 · CASCADE | ||
max_age_for_non_stale_branches_seconds | integer | NOT NULL | The number of seconds since the last modification of a branch until it is considered stale. | ||
max_age_for_non_stale_tags_seconds | integer | NOT NULL | The nujmber of seconds since the commit date of a tagged commit until it is considered stale. |
content_type — content_type is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.lsif_uploads_audit_logs references nothing and nothing references it. Either it is a staging/log table (fine, say so), or it is dead, or it is the seed of a second data model growing beside the first.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
log_timestamp | timestamptz | null | now() | Timestamp for this log entry. | |
record_deleted_at | timestamptz | null | Set once the upload this entry is associated with is deleted. Once NOW() - record_deleted_at is above a certain threshold, this log entry will be deleted. | ||
upload_id | integer | NOT NULL | |||
commit | text | NOT NULL | |||
root | text | NOT NULL | |||
repository_id | integer | NOT NULL | |||
uploaded_at | timestamptz | NOT NULL | |||
indexer | text | NOT NULL | |||
indexer_version | text | null | |||
upload_size | bigint | null | |||
associated_index_id | integer | null | |||
transition_columns | hstore[] | null | Array of changes that occurred to the upload for this entry, in the form of {"column"=>"<column name>", "old"=>"<previous value>", "new"=>"<new value>"}. | ||
reason | text | null | CAST('' AS text) | The reason/source for this entry. | |
sequence | bigint | NOT NULL | |||
operation | audit_log_operation | NOT NULL | |||
content_type | text | NOT NULL | CAST('application/x-ndjson+lsif' AS text) |
A less hot-path reference count for upload records.
| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
upload_id UK | integer | NOT NULL | lsif_uploads.id 1:1 · CASCADE | The identifier of the referenced upload. | |
reference_count | integer | NOT NULL | The number of references to the associated upload from other records (via lsif_references). |
Associates a repository with the set of LSIF upload identifiers that can serve intelligence for the tip of the default branch.
lsif_uploads_visible_at_tip references nothing and nothing references it. Either it is a staging/log table (fine, say so), or it is dead, or it is the seed of a second data model growing beside the first.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
repository_id | integer | NOT NULL | |||
upload_id | integer | NOT NULL | The identifier of the upload visible from the tip of the specified branch or tag. | ||
branch_or_tag_name | text | NOT NULL | CAST('' AS text) | The name of the branch or tag. | |
is_default_branch | boolean | NOT NULL | FALSE | Whether the specified branch is the default of the repository. Always false for tags. |
last_scanned_at — last_scanned_at stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
upload_id | integer | NOT NULL | lsif_uploads.id 1:1 · CASCADE | ||
last_scanned_at | timestamp | NOT NULL | now() |
Tables whose names start with codeowners_.
codeowners.repo_id → repo.id — one repo, at most one codeowners · required · ON DELETE CASCADE · indexedcodeowners.tenant_id → tenants.id — one tenants, many codeowners · optional · ON DELETE CASCADE · not indexedcodeowners_individual_stats.file_path_id → repo_paths.id — one repo_paths, many codeowners_individual_stats · required · ON DELETE NO ACTION · indexedcodeowners_individual_stats.owner_id → codeowners_owners.id — one codeowners_owners, many codeowners_individual_stats · required · ON DELETE NO ACTION · not indexedcodeowners_individual_stats.tenant_id → tenants.id — one tenants, many codeowners_individual_stats · optional · ON DELETE CASCADE · not indexedcodeowners_owners.tenant_id → tenants.id — one tenants, many codeowners_owners · optional · ON DELETE CASCADE · not indexedtenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan codeowners to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to codeowners maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — codeowners.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
contents | text | NOT NULL | |||
contents_proto | bytea | NOT NULL | |||
repo_id UK | integer | NOT NULL | repo.id 1:1 · CASCADE | ||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Data on how many files in given tree are owned by given owner. As opposed to ownership-general `ownership_path_stats` table, the individual <path x owner> stats are stored in CODEOWNERS-specific table `codeowners_individual_stats`. The reason for that is that we are also indexing on owner_id which is CODEOWNERS-specific.
owner_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on codeowners_owners must scan codeowners_individual_stats to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to codeowners_individual_stats maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often codeowners_owners rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan codeowners_individual_stats to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to codeowners_individual_stats maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — codeowners_individual_stats.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.updated_at — updated_at stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
file_path_id PK | integer | NOT NULL | repo_paths.id 1:N | ||
owner_id PK | integer | NOT NULL | codeowners_owners.id 1:N | ||
tree_owned_files_count | integer | NOT NULL | Total owned file count by given owner at given file tree. | ||
updated_at | timestamp | NOT NULL | When the last background job updating counts run. | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Text reference in CODEOWNERS entry to use in codeowners_individual_stats. Reference is either email or handle without @ in front.
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan codeowners_owners to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to codeowners_owners maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — codeowners_owners.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
reference | text | NOT NULL | We just keep the reference as opposed to splitting it to handle or email since the distinction is not relevant for query, and this makes indexing way easier. | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Tables whose names start with discussion_.
discussion_comments.author_user_id → users.id — one users, many discussion_comments · required · ON DELETE RESTRICT · indexeddiscussion_comments.tenant_id → tenants.id — one tenants, many discussion_comments · optional · ON DELETE CASCADE · not indexeddiscussion_comments.thread_id → discussion_threads.id — one discussion_threads, many discussion_comments · required · ON DELETE CASCADE · indexeddiscussion_mail_reply_tokens.tenant_id → tenants.id — one tenants, many discussion_mail_reply_tokens · optional · ON DELETE CASCADE · not indexeddiscussion_mail_reply_tokens.thread_id → discussion_threads.id — one discussion_threads, many discussion_mail_reply_tokens · required · ON DELETE CASCADE · not indexeddiscussion_mail_reply_tokens.user_id → users.id — one users, many discussion_mail_reply_tokens · required · ON DELETE RESTRICT · indexeddiscussion_threads.author_user_id → users.id — one users, many discussion_threads · required · ON DELETE RESTRICT · indexeddiscussion_threads.target_repo_id → discussion_threads_target_repo.id — one discussion_threads_target_repo, many discussion_threads · optional · ON DELETE CASCADE · not indexeddiscussion_threads.tenant_id → tenants.id — one tenants, many discussion_threads · optional · ON DELETE CASCADE · not indexeddiscussion_threads_target_repo.repo_id → repo.id — one repo, many discussion_threads_target_repo · required · ON DELETE CASCADE · indexeddiscussion_threads_target_repo.tenant_id → tenants.id — one tenants, many discussion_threads_target_repo · optional · ON DELETE CASCADE · not indexeddiscussion_threads_target_repo.thread_id → discussion_threads.id — one discussion_threads, many discussion_threads_target_repo · required · ON DELETE CASCADE · not indexedtenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan discussion_comments to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to discussion_comments maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — discussion_comments.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
thread_id | bigint | NOT NULL | discussion_threads.id 1:N · CASCADE | ||
author_user_id | integer | NOT NULL | users.id 1:N · RESTRICT | ||
contents | text | NOT NULL | |||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
deleted_at | timestamptz | null | |||
reports | text[] | NOT NULL | CAST('{}' AS text[]) | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan discussion_mail_reply_tokens to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to discussion_mail_reply_tokens maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.thread_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on discussion_threads must scan discussion_mail_reply_tokens to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to discussion_mail_reply_tokens maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often discussion_threads rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — discussion_mail_reply_tokens.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
token PK | text | NOT NULL | |||
user_id | integer | NOT NULL | users.id 1:N · RESTRICT | ||
thread_id | bigint | NOT NULL | discussion_threads.id 1:N · CASCADE | ||
deleted_at | timestamptz | null | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
target_repo_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on discussion_threads_target_repo must scan discussion_threads to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to discussion_threads maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often discussion_threads_target_repo rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan discussion_threads to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to discussion_threads maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.target_repo_id — discussion_threads.target_repo_id may be NULL, so the relationship to discussion_threads_target_repo is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.tenant_id — discussion_threads.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.target_repo_id, tenant_id — discussion_threads has several nullable FKs (target_repo_id, tenant_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
author_user_id | integer | NOT NULL | users.id 1:N · RESTRICT | ||
title | text | null | |||
target_repo_id | bigint | null | discussion_threads_target_repo.id 1:N · CASCADE | ||
created_at | timestamptz | NOT NULL | now() | ||
archived_at | timestamptz | null | |||
updated_at | timestamptz | NOT NULL | now() | ||
deleted_at | timestamptz | null | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan discussion_threads_target_repo to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to discussion_threads_target_repo maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.thread_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on discussion_threads must scan discussion_threads_target_repo to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to discussion_threads_target_repo maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often discussion_threads rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — discussion_threads_target_repo.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
thread_id | bigint | NOT NULL | discussion_threads.id 1:N · CASCADE | ||
repo_id | integer | NOT NULL | repo.id 1:N · CASCADE | ||
path | text | null | |||
branch | text | null | |||
revision | text | null | |||
start_line | integer | null | |||
end_line | integer | null | |||
start_character | integer | null | |||
end_character | integer | null | |||
lines_before | text | null | |||
lines | text | null | |||
lines_after | text | null | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Tables whose names start with event_.
event_logs.tenant_id → tenants.id — one tenants, many event_logs · optional · ON DELETE CASCADE · not indexedevent_logs_export_allowlist.tenant_id → tenants.id — one tenants, many event_logs_export_allowlist · optional · ON DELETE CASCADE · not indexedevent_logs_scrape_state.tenant_id → tenants.id — one tenants, many event_logs_scrape_state · optional · ON DELETE CASCADE · not indexedevent_logs_scrape_state_own.tenant_id → tenants.id — one tenants, many event_logs_scrape_state_own · optional · ON DELETE CASCADE · not indexedtenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan event_logs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to event_logs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — event_logs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.billing_product_category — billing_product_category is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
name | text | NOT NULL | CHECK name <> CAST('' AS text) | ||
url | text | NOT NULL | |||
user_id | integer | NOT NULL | |||
anonymous_user_id | text | NOT NULL | |||
source | text | NOT NULL | CHECK source <> CAST('' AS text) | ||
argument | jsonb | NOT NULL | |||
version | text | NOT NULL | CHECK version <> CAST('' AS text) | ||
timestamp | timestamptz | NOT NULL | |||
feature_flags | jsonb | null | |||
cohort_id | date | null | |||
public_argument | jsonb | NOT NULL | CAST('{}' AS jsonb) | ||
first_source_url | text | null | |||
last_source_url | text | null | |||
referrer | text | null | |||
device_id | text | null | |||
insert_id | text | null | |||
billing_product_category | text | null | |||
billing_event_id | text | null | |||
client | text | null | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Table checks: (user_id = 0 AND anonymous_user_id <> CAST('' AS text)) OR (user_id <> 0 AND anonymous_user_id = CAST('' AS text)) OR (user_id <> 0 AND anonymous_user_id <> CAST('' AS text)); name <> CAST('' AS text); source <> CAST('' AS text); version <> CAST('' AS text)
An allowlist of events that are approved for export if the scraping job is enabled
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan event_logs_export_allowlist to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to event_logs_export_allowlist maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — event_logs_export_allowlist.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
event_name | text | NOT NULL | Name of the event that corresponds to event_logs.name | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Contains state for the periodic telemetry job that scrapes events if enabled.
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan event_logs_scrape_state to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to event_logs_scrape_state maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — event_logs_scrape_state.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
bookmark_id | integer | NOT NULL | Bookmarks the maximum most recent successful event_logs.id that was scraped | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Contains state for own jobs that scrape events if enabled.
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan event_logs_scrape_state_own to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to event_logs_scrape_state_own maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — event_logs_scrape_state_own.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
bookmark_id | integer | NOT NULL | Bookmarks the maximum most recent successful event_logs.id that was scraped | ||
job_type | integer | NOT NULL | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Tables whose names start with executor_.
executor_heartbeats.tenant_id → tenants.id — one tenants, many executor_heartbeats · optional · ON DELETE CASCADE · not indexedexecutor_job_tokens.tenant_id → tenants.id — one tenants, many executor_job_tokens · optional · ON DELETE CASCADE · not indexedexecutor_secret_access_logs.executor_secret_id → executor_secrets.id — one executor_secrets, many executor_secret_access_logs · required · ON DELETE CASCADE · not indexedexecutor_secret_access_logs.tenant_id → tenants.id — one tenants, many executor_secret_access_logs · optional · ON DELETE CASCADE · not indexedexecutor_secret_access_logs.user_id → users.id — one users, many executor_secret_access_logs · optional · ON DELETE CASCADE · not indexedexecutor_secrets.creator_id → users.id — one users, many executor_secrets · optional · ON DELETE SET NULL · not indexedexecutor_secrets.namespace_org_id → orgs.id — one orgs, many executor_secrets · optional · ON DELETE CASCADE · not indexedexecutor_secrets.namespace_user_id → users.id — one users, many executor_secrets · optional · ON DELETE CASCADE · not indexedexecutor_secrets.tenant_id → tenants.id — one tenants, many executor_secrets · optional · ON DELETE CASCADE · not indexedTracks the most recent activity of executors attached to this Sourcegraph instance.
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan executor_heartbeats to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to executor_heartbeats maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — executor_heartbeats.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
hostname UK | text | NOT NULL | The uniquely identifying name of the executor. | ||
queue_name | text | null | The queue name that the executor polls for work. | ||
os | text | NOT NULL | The operating system running the executor. | ||
architecture | text | NOT NULL | The machine architure running the executor. | ||
docker_version | text | NOT NULL | The version of Docker used by the executor. | ||
executor_version | text | NOT NULL | The version of the executor. | ||
git_version | text | NOT NULL | The version of Git used by the executor. | ||
ignite_version | text | NOT NULL | The version of Ignite used by the executor. | ||
src_cli_version | text | NOT NULL | The version of src-cli used by the executor. | ||
first_seen_at | timestamptz | NOT NULL | now() | The first time a heartbeat from the executor was received. | |
last_seen_at | timestamptz | NOT NULL | now() | The last time a heartbeat from the executor was received. | |
queue_names | text[] | null | The list of queue names that the executor polls for work. | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Table checks: (queue_name IS NOT NULL AND queue_names IS NULL) OR (queue_names IS NOT NULL AND queue_name IS NULL)
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan executor_job_tokens to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to executor_job_tokens maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — executor_job_tokens.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
value_sha256 UK | bytea | NOT NULL | |||
job_id | bigint | NOT NULL | |||
queue | text | NOT NULL | |||
repo_id | bigint | NOT NULL | |||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
executor_secret_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on executor_secrets must scan executor_secret_access_logs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to executor_secret_access_logs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often executor_secrets rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan executor_secret_access_logs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to executor_secret_access_logs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.user_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan executor_secret_access_logs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to executor_secret_access_logs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — executor_secret_access_logs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.user_id — executor_secret_access_logs.user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.tenant_id, user_id — executor_secret_access_logs has several nullable FKs (tenant_id, user_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
executor_secret_id | integer | NOT NULL | executor_secrets.id 1:N · CASCADE | ||
user_id | integer | null | users.id 1:N · CASCADE | ||
created_at | timestamptz | NOT NULL | now() | ||
machine_user | text | NOT NULL | CAST('' AS text) | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Table checks: (user_id IS NULL AND machine_user <> CAST('' AS text)) OR (user_id IS NOT NULL AND machine_user = CAST('' AS text))
creator_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan executor_secrets to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to executor_secrets maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.namespace_org_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on orgs must scan executor_secrets to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to executor_secrets maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often orgs rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.namespace_user_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan executor_secrets to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to executor_secrets maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan executor_secrets to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to executor_secrets maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.creator_id — executor_secrets.creator_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.namespace_org_id — executor_secrets.namespace_org_id may be NULL, so the relationship to orgs is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.namespace_user_id — executor_secrets.namespace_user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.tenant_id — executor_secrets.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.scope — scope is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.creator_id, namespace_org_id, namespace_user_id, tenant_id — executor_secrets has several nullable FKs (creator_id, namespace_org_id, namespace_user_id, tenant_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
key | text | NOT NULL | |||
value | bytea | NOT NULL | |||
scope | text | NOT NULL | |||
encryption_key_id | text | null | |||
namespace_user_id | integer | null | users.id 1:N · CASCADE | ||
namespace_org_id | integer | null | orgs.id 1:N · CASCADE | ||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
creator_id | integer | null | users.id 1:N · SET NULL | NULL, if the user has been deleted. | |
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Tables whose names start with exhaustive_.
exhaustive_search_jobs.initiator_id → users.id — one users, many exhaustive_search_jobs · required · ON DELETE CASCADE · not indexedexhaustive_search_jobs.tenant_id → tenants.id — one tenants, many exhaustive_search_jobs · optional · ON DELETE CASCADE · not indexedexhaustive_search_repo_jobs.repo_id → repo.id — one repo, many exhaustive_search_repo_jobs · required · ON DELETE CASCADE · not indexedexhaustive_search_repo_jobs.search_job_id → exhaustive_search_jobs.id — one exhaustive_search_jobs, many exhaustive_search_repo_jobs · required · ON DELETE CASCADE · not indexedexhaustive_search_repo_jobs.tenant_id → tenants.id — one tenants, many exhaustive_search_repo_jobs · optional · ON DELETE CASCADE · not indexedexhaustive_search_repo_revision_jobs.search_repo_job_id → exhaustive_search_repo_jobs.id — one exhaustive_search_repo_jobs, many exhaustive_search_repo_revision_jobs · required · ON DELETE CASCADE · not indexedexhaustive_search_repo_revision_jobs.tenant_id → tenants.id — one tenants, many exhaustive_search_repo_revision_jobs · optional · ON DELETE CASCADE · not indexedinitiator_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan exhaustive_search_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to exhaustive_search_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan exhaustive_search_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to exhaustive_search_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — exhaustive_search_jobs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.state — state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
state | text | null | CAST('queued' AS text) | ||
initiator_id | integer | NOT NULL | users.id 1:N · CASCADE | ||
query | text | NOT NULL | |||
failure_message | text | null | |||
started_at | timestamptz | null | |||
finished_at | timestamptz | null | |||
process_after | timestamptz | null | |||
num_resets | integer | NOT NULL | 0 | ||
num_failures | integer | NOT NULL | 0 | ||
last_heartbeat_at | timestamptz | null | |||
execution_logs | json[] | null | |||
worker_hostname | text | NOT NULL | CAST('' AS text) | ||
cancel | boolean | NOT NULL | FALSE | ||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
queued_at | timestamptz | null | now() | ||
is_aggregated | boolean | NOT NULL | FALSE | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
repo_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on repo must scan exhaustive_search_repo_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to exhaustive_search_repo_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often repo rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.search_job_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on exhaustive_search_jobs must scan exhaustive_search_repo_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to exhaustive_search_repo_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often exhaustive_search_jobs rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan exhaustive_search_repo_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to exhaustive_search_repo_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — exhaustive_search_repo_jobs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.state — state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
state | text | null | CAST('queued' AS text) | ||
repo_id | integer | NOT NULL | repo.id 1:N · CASCADE | ||
ref_spec | text | NOT NULL | |||
search_job_id | integer | NOT NULL | exhaustive_search_jobs.id 1:N · CASCADE | ||
failure_message | text | null | |||
started_at | timestamptz | null | |||
finished_at | timestamptz | null | |||
process_after | timestamptz | null | |||
num_resets | integer | NOT NULL | 0 | ||
num_failures | integer | NOT NULL | 0 | ||
last_heartbeat_at | timestamptz | null | |||
execution_logs | json[] | null | |||
worker_hostname | text | NOT NULL | CAST('' AS text) | ||
cancel | boolean | NOT NULL | FALSE | ||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
queued_at | timestamptz | null | now() | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
search_repo_job_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on exhaustive_search_repo_jobs must scan exhaustive_search_repo_revision_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to exhaustive_search_repo_revision_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often exhaustive_search_repo_jobs rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan exhaustive_search_repo_revision_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to exhaustive_search_repo_revision_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — exhaustive_search_repo_revision_jobs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.state — state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
state | text | null | CAST('queued' AS text) | ||
search_repo_job_id | integer | NOT NULL | exhaustive_search_repo_jobs.id 1:N · CASCADE | ||
revision | text | NOT NULL | |||
failure_message | text | null | |||
started_at | timestamptz | null | |||
finished_at | timestamptz | null | |||
process_after | timestamptz | null | |||
num_resets | integer | NOT NULL | 0 | ||
num_failures | integer | NOT NULL | 0 | ||
last_heartbeat_at | timestamptz | null | |||
execution_logs | json[] | null | |||
worker_hostname | text | NOT NULL | CAST('' AS text) | ||
cancel | boolean | NOT NULL | FALSE | ||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
queued_at | timestamptz | null | now() | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Tables whose names start with external_.
external_service_repos.external_service_id → external_services.id — one external_services, many external_service_repos · required · ON DELETE CASCADE · indexedexternal_service_repos.repo_id → repo.id — one repo, many external_service_repos · required · ON DELETE CASCADE · indexedexternal_service_repos.tenant_id → tenants.id — one tenants, many external_service_repos · optional · ON DELETE CASCADE · not indexedexternal_service_sync_jobs.tenant_id → tenants.id — one tenants, many external_service_sync_jobs · optional · ON DELETE CASCADE · not indexedexternal_service_sync_jobs.external_service_id → external_services.id — one external_services, many external_service_sync_jobs · required · ON DELETE CASCADE · not indexedexternal_services.code_host_id → code_hosts.id — one code_hosts, many external_services · optional · ON DELETE SET NULL · not indexedexternal_services.creator_id → users.id — one users, many external_services · optional · ON DELETE SET NULL · not indexedexternal_services.last_updater_id → users.id — one users, many external_services · optional · ON DELETE SET NULL · not indexedexternal_services.tenant_id → tenants.id — one tenants, many external_services · optional · ON DELETE CASCADE · not indexedtenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan external_service_repos to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to external_service_repos maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — external_service_repos.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
external_service_id | bigint | NOT NULL | external_services.id 1:N · CASCADE | ||
repo_id | integer | NOT NULL | repo.id 1:N · CASCADE | ||
clone_url | text | NOT NULL | |||
created_at | timestamptz | NOT NULL | transaction_timestamp() | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan external_service_sync_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to external_service_sync_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.external_service_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on external_services must scan external_service_sync_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to external_service_sync_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often external_services rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — external_service_sync_jobs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.state — state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id | integer | NOT NULL | nextval(CAST('external_service_sync_jobs_id_seq' AS regclass)) | ||
state | text | NOT NULL | CAST('queued' AS text) | ||
failure_message | text | null | |||
started_at | timestamptz | null | |||
finished_at | timestamptz | null | |||
process_after | timestamptz | null | |||
num_resets | integer | NOT NULL | 0 | ||
external_service_id | bigint | NOT NULL | external_services.id 1:N · CASCADE | ||
num_failures | integer | NOT NULL | 0 | ||
log_contents | text | null | |||
execution_logs | json[] | null | |||
worker_hostname | text | NOT NULL | CAST('' AS text) | ||
last_heartbeat_at | timestamptz | null | |||
queued_at | timestamptz | null | now() | ||
cancel | boolean | NOT NULL | FALSE | ||
repos_synced | integer | NOT NULL | 0 | The number of repos synced during this sync job. | |
repo_sync_errors | integer | NOT NULL | 0 | The number of times an error occurred syncing a repo during this sync job. | |
repos_added | integer | NOT NULL | 0 | The number of new repos discovered during this sync job. | |
repos_deleted | integer | NOT NULL | 0 | The number of repos deleted as a result of this sync job. | |
repos_modified | integer | NOT NULL | 0 | The number of existing repos whose metadata has changed during this sync job. | |
repos_unmodified | integer | NOT NULL | 0 | The number of existing repos whose metadata did not change during this sync job. | |
tenant_id | integer | null | tenants.id 1:N · CASCADE |
code_host_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on code_hosts must scan external_services to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to external_services maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often code_hosts rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.creator_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan external_services to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to external_services maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.last_updater_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan external_services to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to external_services maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan external_services to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to external_services maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.code_host_id — external_services.code_host_id may be NULL, so the relationship to code_hosts is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.creator_id — external_services.creator_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.last_updater_id — external_services.last_updater_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.tenant_id — external_services.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.kind — kind is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.code_host_id, creator_id, last_updater_id, tenant_id — external_services has several nullable FKs (code_host_id, creator_id, last_updater_id, tenant_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
kind | text | NOT NULL | |||
display_name | text | NOT NULL | |||
config | text | NOT NULL | CHECK btrim(config) <> CAST('' AS text) | ||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
deleted_at | timestamptz | null | |||
last_sync_at | timestamptz | null | |||
next_sync_at | timestamptz | null | |||
unrestricted | boolean | NOT NULL | FALSE | ||
cloud_default | boolean | NOT NULL | FALSE | ||
encryption_key_id | text | NOT NULL | CAST('' AS text) | ||
has_webhooks | boolean | null | |||
token_expires_at | timestamptz | null | |||
code_host_id | integer | null | code_hosts.id 1:N · SET NULL | ||
creator_id | integer | null | users.id 1:N · SET NULL | ||
last_updater_id | integer | null | users.id 1:N · SET NULL | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Table checks: btrim(config) <> CAST('' AS text)
Tables whose names start with feature_.
feature_flag_overrides.namespace_org_id → orgs.id — one orgs, many feature_flag_overrides · optional · ON DELETE CASCADE · indexedfeature_flag_overrides.namespace_user_id → users.id — one users, many feature_flag_overrides · optional · ON DELETE CASCADE · indexedfeature_flag_overrides.tenant_id → tenants.id — one tenants, many feature_flag_overrides · optional · ON DELETE CASCADE · not indexedfeature_flags.tenant_id → tenants.id — one tenants, many feature_flags · optional · ON DELETE CASCADE · not indexedtenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan feature_flag_overrides to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to feature_flag_overrides maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.namespace_org_id — feature_flag_overrides.namespace_org_id may be NULL, so the relationship to orgs is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.namespace_user_id — feature_flag_overrides.namespace_user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.tenant_id — feature_flag_overrides.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.namespace_org_id, flag_name — feature_flag_overrides soft-deletes via deleted_at, but (namespace_org_id, flag_name) is unique across live AND deleted rows. A user who deletes their account can never sign up again with the same value, and ON CONFLICT upserts will resurrect ghosts.namespace_user_id, flag_name — feature_flag_overrides soft-deletes via deleted_at, but (namespace_user_id, flag_name) is unique across live AND deleted rows. A user who deletes their account can never sign up again with the same value, and ON CONFLICT upserts will resurrect ghosts.namespace_org_id, namespace_user_id, tenant_id — feature_flag_overrides has several nullable FKs (namespace_org_id, namespace_user_id, tenant_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
namespace_org_id | integer | null | orgs.id 1:N · CASCADE | ||
namespace_user_id | integer | null | users.id 1:N · CASCADE | ||
flag_name | text | NOT NULL | |||
flag_value | boolean | NOT NULL | |||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
deleted_at | timestamptz | null | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Table checks: namespace_org_id IS NOT NULL OR namespace_user_id IS NOT NULL
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan feature_flags to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to feature_flags maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — feature_flags.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
flag_name PK | text | NOT NULL | |||
flag_type | feature_flag_type | NOT NULL | |||
bool_value | boolean | null | Bool value only defined when flag_type is bool | ||
rollout | integer | null | Rollout only defined when flag_type is rollout. Increments of 0.01%CHECK rollout >= 0 AND rollout <= 10000 | ||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
deleted_at | timestamptz | null | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Table checks: rollout >= 0 AND rollout <= 10000; 1 = CASE WHEN flag_type = CAST('bool' AS feature_flag_type) AND bool_value IS NULL THEN 0 WHEN flag_type <> CAST('bool' AS feature_flag_type) AND bool_value IS NOT NULL THEN 0 ELSE 1 END; 1 = CASE WHEN flag_type = CAST('rollout' AS feature_flag_type) AND rollout IS NULL THEN 0 WHEN flag_type <> CAST('rollout' AS feature_flag_type) AND rollout IS NOT NULL THEN 0 ELSE 1 END
Tables whose names start with github_.
github_app_installs.app_id → github_apps.id — one github_apps, many github_app_installs · required · ON DELETE CASCADE · indexedgithub_app_installs.tenant_id → tenants.id — one tenants, many github_app_installs · optional · ON DELETE CASCADE · not indexedgithub_apps.tenant_id → tenants.id — one tenants, many github_apps · optional · ON DELETE CASCADE · not indexedgithub_apps.webhook_id → webhooks.id — one webhooks, many github_apps · optional · ON DELETE SET NULL · not indexedtenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan github_app_installs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to github_app_installs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — github_app_installs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.account_type — account_type is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
app_id | integer | NOT NULL | github_apps.id 1:N · CASCADE | ||
installation_id | integer | NOT NULL | |||
created_at | timestamptz | NOT NULL | now() | ||
url | text | null | |||
account_login | text | null | |||
account_avatar_url | text | null | |||
account_url | text | null | |||
account_type | text | null | |||
updated_at | timestamptz | NOT NULL | now() | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan github_apps to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to github_apps maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.webhook_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on webhooks must scan github_apps to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to github_apps maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often webhooks rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — github_apps.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.webhook_id — github_apps.webhook_id may be NULL, so the relationship to webhooks is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.tenant_id, webhook_id — github_apps has several nullable FKs (tenant_id, webhook_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
app_id | integer | NOT NULL | |||
name | text | NOT NULL | |||
slug | text | NOT NULL | |||
base_url | text | NOT NULL | |||
client_id | text | NOT NULL | |||
client_secret | text | NOT NULL | |||
private_key | text | NOT NULL | |||
encryption_key_id | text | NOT NULL | |||
logo | text | null | |||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
app_url | text | NOT NULL | CAST('' AS text) | ||
webhook_id | integer | null | webhooks.id 1:N · SET NULL | ||
domain | text | NOT NULL | CAST('repos' AS text) | ||
kind | github_app_kind | NOT NULL | CAST('REPO_SYNC' AS github_app_kind) | ||
creator_id | bigint | NOT NULL | 0 | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Tables whose names start with gitserver_.
gitserver_relocator_jobs.tenant_id → tenants.id — one tenants, many gitserver_relocator_jobs · optional · ON DELETE CASCADE · not indexedgitserver_repos.repo_id → repo.id — one repo, at most one gitserver_repos · required · ON DELETE CASCADE · indexedgitserver_repos.tenant_id → tenants.id — one tenants, many gitserver_repos · optional · ON DELETE CASCADE · not indexedgitserver_repos_statistics.tenant_id → tenants.id — one tenants, many gitserver_repos_statistics · optional · ON DELETE CASCADE · not indexedgitserver_repos_sync_output.repo_id → repo.id — one repo, at most one gitserver_repos_sync_output · required · ON DELETE CASCADE · indexedgitserver_repos_sync_output.tenant_id → tenants.id — one tenants, many gitserver_repos_sync_output · optional · ON DELETE CASCADE · not indexedtenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan gitserver_relocator_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to gitserver_relocator_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — gitserver_relocator_jobs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.state — state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
state | text | null | CAST('queued' AS text) | ||
queued_at | timestamptz | null | now() | ||
failure_message | text | null | |||
started_at | timestamptz | null | |||
finished_at | timestamptz | null | |||
process_after | timestamptz | null | |||
num_resets | integer | NOT NULL | 0 | ||
num_failures | integer | NOT NULL | 0 | ||
last_heartbeat_at | timestamptz | null | |||
execution_logs | json[] | null | |||
worker_hostname | text | NOT NULL | CAST('' AS text) | ||
repo_id | integer | NOT NULL | |||
source_hostname | text | NOT NULL | |||
dest_hostname | text | NOT NULL | |||
delete_source | boolean | NOT NULL | FALSE | ||
cancel | boolean | NOT NULL | FALSE | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan gitserver_repos to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to gitserver_repos maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — gitserver_repos.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.clone_status — clone_status is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
repo_id PK | integer | NOT NULL | repo.id 1:1 · CASCADE | ||
clone_status | text | NOT NULL | CAST('not_cloned' AS text) | ||
shard_id | text | NOT NULL | |||
last_error | text | null | |||
updated_at | timestamptz | NOT NULL | now() | ||
last_fetched | timestamptz | NOT NULL | now() | ||
last_changed | timestamptz | NOT NULL | now() | ||
repo_size_bytes | bigint | null | |||
corrupted_at | timestamptz | null | Timestamp of when repo corruption was detected | ||
corruption_logs | jsonb | NOT NULL | CAST('[]' AS jsonb) | Log output of repo corruptions that have been detected - encoded as json | |
cloning_progress | text | null | CAST('' AS text) | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan gitserver_repos_statistics to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to gitserver_repos_statistics maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — gitserver_repos_statistics.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
shard_id | text | null | ID of this gitserver shard. If an empty string then the repositories havent been assigned a shard. | ||
total | bigint | NOT NULL | 0 | Number of repositories in gitserver_repos table on this shard | |
not_cloned | bigint | NOT NULL | 0 | Number of repositories in gitserver_repos table on this shard that are not cloned yet | |
cloning | bigint | NOT NULL | 0 | Number of repositories in gitserver_repos table on this shard that cloning | |
cloned | bigint | NOT NULL | 0 | Number of repositories in gitserver_repos table on this shard that are cloned | |
failed_fetch | bigint | NOT NULL | 0 | Number of repositories in gitserver_repos table on this shard where last_error is set | |
corrupted | bigint | NOT NULL | 0 | Number of repositories that are NOT soft-deleted and not blocked and have corrupted_at set in gitserver_repos table | |
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Contains the most recent output from gitserver repository sync jobs.
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan gitserver_repos_sync_output to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to gitserver_repos_sync_output maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — gitserver_repos_sync_output.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
repo_id PK | integer | NOT NULL | repo.id 1:1 · CASCADE | ||
last_output | text | NOT NULL | CAST('' AS text) | ||
updated_at | timestamptz | NOT NULL | now() | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Tables whose names start with insights_.
insights_query_runner_jobs.tenant_id → tenants.id — one tenants, many insights_query_runner_jobs · optional · ON DELETE CASCADE · not indexedinsights_query_runner_jobs_dependencies.job_id → insights_query_runner_jobs.id — one insights_query_runner_jobs, many insights_query_runner_jobs_dependencies · required · ON DELETE CASCADE · indexedinsights_query_runner_jobs_dependencies.tenant_id → tenants.id — one tenants, many insights_query_runner_jobs_dependencies · optional · ON DELETE CASCADE · not indexedinsights_settings_migration_jobs.tenant_id → tenants.id — one tenants, many insights_settings_migration_jobs · optional · ON DELETE CASCADE · not indexedSee [internal/insights/background/queryrunner/worker.go:Job](https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/sourcegraph/sourcegraph%24+file:internal/insights/background/queryrunner/worker.go+type+Job&patternType=literal)
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan insights_query_runner_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to insights_query_runner_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — insights_query_runner_jobs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.state — state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
series_id | text | NOT NULL | |||
search_query | text | NOT NULL | |||
state | text | null | CAST('queued' AS text) | ||
failure_message | text | null | |||
started_at | timestamptz | null | |||
finished_at | timestamptz | null | |||
process_after | timestamptz | null | |||
num_resets | integer | NOT NULL | 0 | ||
num_failures | integer | NOT NULL | 0 | ||
execution_logs | json[] | null | |||
record_time | timestamptz | null | |||
worker_hostname | text | NOT NULL | CAST('' AS text) | ||
last_heartbeat_at | timestamptz | null | |||
priority | integer | NOT NULL | 1 | Integer representing a category of priority for this query. Priority in this context is ambiguously defined for consumers to decide an interpretation. | |
cost | integer | NOT NULL | 500 | Integer representing a cost approximation of executing this search query. | |
persist_mode | persistmode | NOT NULL | CAST('record' AS persistmode) | The persistence level for this query. This value will determine the lifecycle of the resulting value. | |
queued_at | timestamptz | null | now() | ||
cancel | boolean | NOT NULL | FALSE | ||
trace_id | text | null | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Stores data points for a code insight that do not need to be queried directly, but depend on the result of a query at a different point
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan insights_query_runner_jobs_dependencies to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to insights_query_runner_jobs_dependencies maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — insights_query_runner_jobs_dependencies.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.recording_time — recording_time stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
job_id | integer | NOT NULL | insights_query_runner_jobs.id 1:N · CASCADE | Foreign key to the job that owns this record. | |
recording_time | timestamp | NOT NULL | The time for which this dependency should be recorded at using the parents value. | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan insights_settings_migration_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to insights_settings_migration_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — insights_settings_migration_jobs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.completed_at — completed_at stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id | integer | NOT NULL | |||
user_id | integer | null | |||
org_id | integer | null | |||
global | boolean | null | |||
settings_id | integer | NOT NULL | |||
total_insights | integer | NOT NULL | 0 | ||
migrated_insights | integer | NOT NULL | 0 | ||
total_dashboards | integer | NOT NULL | 0 | ||
migrated_dashboards | integer | NOT NULL | 0 | ||
runs | integer | NOT NULL | 0 | ||
completed_at | timestamp | null | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Tables whose names start with org_.
org_invitations.org_id → orgs.id — one orgs, many org_invitations · required · ON DELETE NO ACTION · indexedorg_invitations.recipient_user_id → users.id — one users, many org_invitations · optional · ON DELETE NO ACTION · indexedorg_invitations.sender_user_id → users.id — one users, many org_invitations · required · ON DELETE NO ACTION · not indexedorg_invitations.tenant_id → tenants.id — one tenants, many org_invitations · optional · ON DELETE CASCADE · not indexedorg_members.org_id → orgs.id — one orgs, many org_members · required · ON DELETE RESTRICT · indexedorg_members.tenant_id → tenants.id — one tenants, many org_members · optional · ON DELETE CASCADE · not indexedorg_members.user_id → users.id — one users, many org_members · required · ON DELETE RESTRICT · not indexedorg_stats.org_id → orgs.id — one orgs, at most one org_stats · required · ON DELETE CASCADE · indexedorg_stats.tenant_id → tenants.id — one tenants, many org_stats · optional · ON DELETE CASCADE · not indexedsender_user_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan org_invitations to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to org_invitations maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan org_invitations to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to org_invitations maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.recipient_user_id — org_invitations.recipient_user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.tenant_id — org_invitations.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.recipient_user_id, tenant_id — org_invitations has several nullable FKs (recipient_user_id, tenant_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
org_id | integer | NOT NULL | orgs.id 1:N | ||
sender_user_id | integer | NOT NULL | users.id 1:N | ||
recipient_user_id | integer | null | users.id 1:N | ||
created_at | timestamptz | NOT NULL | now() | ||
notified_at | timestamptz | null | |||
responded_at | timestamptz | null | |||
response_type | boolean | null | |||
revoked_at | timestamptz | null | |||
deleted_at | timestamptz | null | |||
recipient_email | citext | null | |||
expires_at | timestamptz | null | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Table checks: responded_at IS NULL = response_type IS NULL; (responded_at IS NULL AND response_type IS NULL) OR revoked_at IS NULL; recipient_user_id IS NULL <> recipient_email IS NULL
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan org_members to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to org_members maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.user_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan org_members to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to org_members maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — org_members.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
org_id | integer | NOT NULL | orgs.id 1:N · RESTRICT | ||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
user_id | integer | NOT NULL | users.id 1:N · RESTRICT | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Business statistics for organizations
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan org_stats to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to org_stats maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — org_stats.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
org_id PK | integer | NOT NULL | orgs.id 1:1 · CASCADE | Org ID that the stats relate to. | |
code_host_repo_count | integer | null | 0 | Count of repositories accessible on all code hosts for this organization. | |
updated_at | timestamptz | NOT NULL | now() | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Tables whose names start with orgs_.
orgs.tenant_id → tenants.id — one tenants, many orgs · optional · ON DELETE CASCADE · not indexedorgs_open_beta_stats.tenant_id → tenants.id — one tenants, many orgs_open_beta_stats · optional · ON DELETE CASCADE · not indexedtenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan orgs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to orgs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — orgs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
name | citext | NOT NULL | CHECK char_length(CAST(name AS text)) <= 255 | ||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
display_name | text | null | CHECK char_length(display_name) <= 255 | ||
slack_webhook_url | text | null | |||
deleted_at | timestamptz | null | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Table checks: char_length(display_name) <= 255; char_length(CAST(name AS text)) <= 255; name ~ CAST('^[a-zA-Z0-9](?:[a-zA-Z0-9]|[-.](?=[a-zA-Z0-9]))*-?$' AS citext)
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan orgs_open_beta_stats to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to orgs_open_beta_stats maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — orgs_open_beta_stats.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | uuid | NOT NULL | gen_random_uuid() | ||
user_id | integer | null | |||
org_id | integer | null | |||
created_at | timestamptz | null | now() | ||
data | jsonb | NOT NULL | CAST('{}' AS jsonb) | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Tables whose names start with out_.
out_of_band_migrations.tenant_id → tenants.id — one tenants, many out_of_band_migrations · optional · ON DELETE CASCADE · not indexedout_of_band_migrations_errors.migration_id → out_of_band_migrations.id — one out_of_band_migrations, many out_of_band_migrations_errors · required · ON DELETE CASCADE · not indexedout_of_band_migrations_errors.tenant_id → tenants.id — one tenants, many out_of_band_migrations_errors · optional · ON DELETE CASCADE · not indexedStores metadata and progress about an out-of-band migration routine.
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan out_of_band_migrations to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to out_of_band_migrations maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — out_of_band_migrations.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | A globally unique primary key for this migration. The same key is used consistently across all Sourcegraph instances for the same migration. | ||
team | text | NOT NULL | The name of the engineering team responsible for the migration.CHECK team <> CAST('' AS text) | ||
component | text | NOT NULL | The name of the component undergoing a migration.CHECK component <> CAST('' AS text) | ||
description | text | NOT NULL | A brief description about the migration.CHECK description <> CAST('' AS text) | ||
progress | double precision | NOT NULL | 0 | The percentage progress in the up direction (0=0%, 1=100%).CHECK progress >= CAST(0 AS double precision) AND progress <= CAST(1 AS double precision) | |
created | timestamptz | NOT NULL | The date and time the migration was inserted into the database (via an upgrade). | ||
last_updated | timestamptz | null | The date and time the migration was last updated. | ||
non_destructive | boolean | NOT NULL | Whether or not this migration alters data so it can no longer be read by the previous Sourcegraph instance. | ||
apply_reverse | boolean | NOT NULL | FALSE | Whether this migration should run in the opposite direction (to support an upcoming downgrade). | |
is_enterprise | boolean | NOT NULL | FALSE | When true, these migrations are invisible to OSS mode. | |
introduced_version_major | integer | NOT NULL | The Sourcegraph version (major component) in which this migration was first introduced. | ||
introduced_version_minor | integer | NOT NULL | The Sourcegraph version (minor component) in which this migration was first introduced. | ||
deprecated_version_major | integer | null | The lowest Sourcegraph version (major component) that assumes the migration has completed. | ||
deprecated_version_minor | integer | null | The lowest Sourcegraph version (minor component) that assumes the migration has completed. | ||
metadata | jsonb | NOT NULL | CAST('{}' AS jsonb) | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Table checks: component <> CAST('' AS text); description <> CAST('' AS text); progress >= CAST(0 AS double precision) AND progress <= CAST(1 AS double precision); team <> CAST('' AS text)
Stores errors that occurred while performing an out-of-band migration.
migration_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on out_of_band_migrations must scan out_of_band_migrations_errors to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to out_of_band_migrations_errors maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often out_of_band_migrations rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan out_of_band_migrations_errors to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to out_of_band_migrations_errors maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — out_of_band_migrations_errors.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | A unique identifer. | ||
migration_id | integer | NOT NULL | out_of_band_migrations.id 1:N · CASCADE | The identifier of the migration. | |
message | text | NOT NULL | The error message.CHECK message <> CAST('' AS text) | ||
created | timestamptz | NOT NULL | now() | The date and time the error occurred. | |
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Table checks: message <> CAST('' AS text)
Tables whose names start with outbound_.
outbound_webhook_event_types.outbound_webhook_id → outbound_webhooks.id — one outbound_webhooks, many outbound_webhook_event_types · required · ON DELETE CASCADE · not indexedoutbound_webhook_event_types.tenant_id → tenants.id — one tenants, many outbound_webhook_event_types · optional · ON DELETE CASCADE · not indexedoutbound_webhook_jobs.tenant_id → tenants.id — one tenants, many outbound_webhook_jobs · optional · ON DELETE CASCADE · not indexedoutbound_webhook_logs.job_id → outbound_webhook_jobs.id — one outbound_webhook_jobs, many outbound_webhook_logs · required · ON DELETE CASCADE · not indexedoutbound_webhook_logs.outbound_webhook_id → outbound_webhooks.id — one outbound_webhooks, many outbound_webhook_logs · required · ON DELETE CASCADE · indexedoutbound_webhook_logs.tenant_id → tenants.id — one tenants, many outbound_webhook_logs · optional · ON DELETE CASCADE · not indexedoutbound_webhooks.created_by → users.id — one users, many outbound_webhooks · optional · ON DELETE SET NULL · not indexedoutbound_webhooks.tenant_id → tenants.id — one tenants, many outbound_webhooks · optional · ON DELETE CASCADE · not indexedoutbound_webhooks.updated_by → users.id — one users, many outbound_webhooks · optional · ON DELETE SET NULL · not indexedoutbound_webhook_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on outbound_webhooks must scan outbound_webhook_event_types to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to outbound_webhook_event_types maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often outbound_webhooks rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan outbound_webhook_event_types to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to outbound_webhook_event_types maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — outbound_webhook_event_types.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.event_type — event_type is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.scope — scope is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
outbound_webhook_id | bigint | NOT NULL | outbound_webhooks.id 1:N · CASCADE | ||
event_type | text | NOT NULL | |||
scope | text | null | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan outbound_webhook_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to outbound_webhook_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — outbound_webhook_jobs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.event_type — event_type is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.scope — scope is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.state — state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
event_type | text | NOT NULL | |||
scope | text | null | |||
encryption_key_id | text | null | |||
payload | bytea | NOT NULL | |||
state | text | NOT NULL | CAST('queued' AS text) | ||
failure_message | text | null | |||
queued_at | timestamptz | NOT NULL | now() | ||
started_at | timestamptz | null | |||
finished_at | timestamptz | null | |||
process_after | timestamptz | null | |||
num_resets | integer | NOT NULL | 0 | ||
num_failures | integer | NOT NULL | 0 | ||
last_heartbeat_at | timestamptz | null | |||
execution_logs | json[] | null | |||
worker_hostname | text | NOT NULL | CAST('' AS text) | ||
cancel | boolean | NOT NULL | FALSE | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
job_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on outbound_webhook_jobs must scan outbound_webhook_logs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to outbound_webhook_logs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often outbound_webhook_jobs rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan outbound_webhook_logs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to outbound_webhook_logs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — outbound_webhook_logs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
job_id | bigint | NOT NULL | outbound_webhook_jobs.id 1:N · CASCADE | ||
outbound_webhook_id | bigint | NOT NULL | outbound_webhooks.id 1:N · CASCADE | ||
sent_at | timestamptz | NOT NULL | now() | ||
status_code | integer | NOT NULL | |||
encryption_key_id | text | null | |||
request | bytea | NOT NULL | |||
response | bytea | NOT NULL | |||
error | bytea | NOT NULL | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
created_by — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan outbound_webhooks to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to outbound_webhooks maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan outbound_webhooks to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to outbound_webhooks maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.updated_by — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan outbound_webhooks to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to outbound_webhooks maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.created_by — outbound_webhooks.created_by may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.tenant_id — outbound_webhooks.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.updated_by — outbound_webhooks.updated_by may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
created_by | integer | null | users.id 1:N · SET NULL | ||
created_at | timestamptz | NOT NULL | now() | ||
updated_by | integer | null | users.id 1:N · SET NULL | ||
updated_at | timestamptz | NOT NULL | now() | ||
encryption_key_id | text | null | |||
url | bytea | NOT NULL | |||
secret | bytea | NOT NULL | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Tables whose names start with own_.
own_aggregate_recent_contribution.changed_file_path_id → repo_paths.id — one repo_paths, many own_aggregate_recent_contribution · required · ON DELETE NO ACTION · indexedown_aggregate_recent_contribution.commit_author_id → commit_authors.id — one commit_authors, many own_aggregate_recent_contribution · required · ON DELETE NO ACTION · not indexedown_aggregate_recent_contribution.tenant_id → tenants.id — one tenants, many own_aggregate_recent_contribution · optional · ON DELETE CASCADE · not indexedown_aggregate_recent_view.tenant_id → tenants.id — one tenants, many own_aggregate_recent_view · optional · ON DELETE CASCADE · not indexedown_aggregate_recent_view.viewed_file_path_id → repo_paths.id — one repo_paths, many own_aggregate_recent_view · required · ON DELETE NO ACTION · indexedown_aggregate_recent_view.viewer_id → users.id — one users, many own_aggregate_recent_view · required · ON DELETE CASCADE · not indexedown_background_jobs.tenant_id → tenants.id — one tenants, many own_background_jobs · optional · ON DELETE CASCADE · not indexedown_signal_configurations.tenant_id → tenants.id — one tenants, many own_signal_configurations · optional · ON DELETE CASCADE · not indexedown_signal_recent_contribution.changed_file_path_id → repo_paths.id — one repo_paths, many own_signal_recent_contribution · required · ON DELETE NO ACTION · not indexedown_signal_recent_contribution.commit_author_id → commit_authors.id — one commit_authors, many own_signal_recent_contribution · required · ON DELETE NO ACTION · not indexedown_signal_recent_contribution.tenant_id → tenants.id — one tenants, many own_signal_recent_contribution · optional · ON DELETE CASCADE · not indexedcommit_author_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on commit_authors must scan own_aggregate_recent_contribution to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to own_aggregate_recent_contribution maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often commit_authors rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan own_aggregate_recent_contribution to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to own_aggregate_recent_contribution maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — own_aggregate_recent_contribution.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
commit_author_id | integer | NOT NULL | commit_authors.id 1:N | ||
changed_file_path_id | integer | NOT NULL | repo_paths.id 1:N | ||
contributions_count | integer | null | 0 | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
One entry contains a number of views of a single file by a given viewer.
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan own_aggregate_recent_view to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to own_aggregate_recent_view maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.viewer_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan own_aggregate_recent_view to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to own_aggregate_recent_view maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — own_aggregate_recent_view.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
viewer_id | integer | NOT NULL | users.id 1:N · CASCADE | ||
viewed_file_path_id | integer | NOT NULL | repo_paths.id 1:N | ||
views_count | integer | null | 0 | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan own_background_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to own_background_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — own_background_jobs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.state — state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
state | text | null | CAST('queued' AS text) | ||
failure_message | text | null | |||
queued_at | timestamptz | null | now() | ||
started_at | timestamptz | null | |||
finished_at | timestamptz | null | |||
process_after | timestamptz | null | |||
num_resets | integer | NOT NULL | 0 | ||
num_failures | integer | NOT NULL | 0 | ||
last_heartbeat_at | timestamptz | null | |||
execution_logs | json[] | null | |||
worker_hostname | text | NOT NULL | CAST('' AS text) | ||
cancel | boolean | NOT NULL | FALSE | ||
repo_id | integer | NOT NULL | |||
job_type | integer | NOT NULL | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan own_signal_configurations to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to own_signal_configurations maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — own_signal_configurations.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
name | text | NOT NULL | |||
description | text | NOT NULL | CAST('' AS text) | ||
excluded_repo_patterns | text[] | null | |||
enabled | boolean | NOT NULL | FALSE | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
One entry per file changed in every commit that classifies as a contribution signal.
changed_file_path_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on repo_paths must scan own_signal_recent_contribution to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to own_signal_recent_contribution maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often repo_paths rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.commit_author_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on commit_authors must scan own_signal_recent_contribution to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to own_signal_recent_contribution maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often commit_authors rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan own_signal_recent_contribution to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to own_signal_recent_contribution maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — own_signal_recent_contribution.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.commit_timestamp — commit_timestamp stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
commit_author_id | integer | NOT NULL | commit_authors.id 1:N | ||
changed_file_path_id | integer | NOT NULL | repo_paths.id 1:N | ||
commit_timestamp | timestamp | NOT NULL | |||
commit_id | bytea | NOT NULL | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Tables whose names start with package_.
package_repo_filters.tenant_id → tenants.id — one tenants, many package_repo_filters · optional · ON DELETE CASCADE · not indexedpackage_repo_versions.package_id → lsif_dependency_repos.id — one lsif_dependency_repos, many package_repo_versions · required · ON DELETE CASCADE · indexedpackage_repo_versions.tenant_id → tenants.id — one tenants, many package_repo_versions · optional · ON DELETE CASCADE · not indexedtenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan package_repo_filters to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to package_repo_filters maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — package_repo_filters.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.scheme, matcher — package_repo_filters soft-deletes via deleted_at, but (scheme, matcher) is unique across live AND deleted rows. A user who deletes their account can never sign up again with the same value, and ON CONFLICT upserts will resurrect ghosts.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
behaviour | text | NOT NULL | CHECK behaviour = ANY(CAST('{BLOCK,ALLOW}' AS text[])) | ||
scheme | text | NOT NULL | CHECK scheme = ANY(CAST('{semanticdb,npm,go,python,rust-analyzer,scip-ruby}' AS text[])) | ||
matcher | jsonb | NOT NULL | CHECK (matcher ? CAST('VersionGlob' AS text) AND (matcher ->> CAST('VersionGlob' AS text)) <> CAST('' AS text) AND (matcher ->> CAST('PackageName' AS text)) <> CAST('' AS text) AND NOT matcher ? CAST('PackageGlob' AS text)) OR (matcher ? CAST('PackageGlob' AS text) AND (matcher ->> CAST('PackageGlob' AS text)) <> CAST('' AS text) AND NOT matcher ? CAST('VersionGlob' AS text)) | ||
deleted_at | timestamptz | null | |||
updated_at | timestamptz | NOT NULL | statement_timestamp() | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Table checks: behaviour = ANY(CAST('{BLOCK,ALLOW}' AS text[])); scheme = ANY(CAST('{semanticdb,npm,go,python,rust-analyzer,scip-ruby}' AS text[])); (matcher ? CAST('VersionGlob' AS text) AND (matcher ->> CAST('VersionGlob' AS text)) <> CAST('' AS text) AND (matcher ->> CAST('PackageName' AS text)) <> CAST('' AS text) AND NOT matcher ? CAST('PackageGlob' AS text)) OR (matcher ? CAST('PackageGlob' AS text) AND (matcher ->> CAST('PackageGlob' AS text)) <> CAST('' AS text) AND NOT matcher ? CAST('VersionGlob' AS text))
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan package_repo_versions to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to package_repo_versions maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — package_repo_versions.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
package_id | bigint | NOT NULL | lsif_dependency_repos.id 1:N · CASCADE | ||
version | text | NOT NULL | |||
blocked | boolean | NOT NULL | FALSE | ||
last_checked_at | timestamptz | null | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Tables whose names start with product_.
product_licenses.product_subscription_id → product_subscriptions.id — one product_subscriptions, many product_licenses · required · ON DELETE NO ACTION · not indexedproduct_licenses.tenant_id → tenants.id — one tenants, many product_licenses · optional · ON DELETE CASCADE · not indexedproduct_subscriptions.tenant_id → tenants.id — one tenants, many product_subscriptions · optional · ON DELETE CASCADE · not indexedproduct_subscriptions.user_id → users.id — one users, many product_subscriptions · required · ON DELETE NO ACTION · not indexedproduct_subscription_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on product_subscriptions must scan product_licenses to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to product_licenses maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often product_subscriptions rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan product_licenses to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to product_licenses maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — product_licenses.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | uuid | NOT NULL | |||
product_subscription_id | uuid | NOT NULL | product_subscriptions.id 1:N | ||
license_key | text | NOT NULL | |||
created_at | timestamptz | NOT NULL | now() | ||
license_version | integer | null | |||
license_tags | text[] | null | |||
license_user_count | integer | null | |||
license_expires_at | timestamptz | null | |||
access_token_enabled | boolean | NOT NULL | TRUE | Whether this license key can be used as an access token to authenticate API requests | |
site_id | uuid | null | |||
license_check_token | bytea | null | |||
revoked_at | timestamptz | null | |||
salesforce_sub_id | text | null | |||
salesforce_opp_id | text | null | |||
revoke_reason | text | null | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan product_subscriptions to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to product_subscriptions maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.user_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan product_subscriptions to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to product_subscriptions maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — product_subscriptions.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | uuid | NOT NULL | |||
user_id | integer | NOT NULL | users.id 1:N | ||
billing_subscription_id | text | null | |||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
archived_at | timestamptz | null | |||
account_number | text | null | |||
cody_gateway_enabled | boolean | NOT NULL | FALSE | ||
cody_gateway_chat_rate_limit | bigint | null | |||
cody_gateway_chat_rate_interval_seconds | integer | null | |||
cody_gateway_embeddings_api_rate_limit | bigint | null | Custom requests per time interval allowed for embeddings | ||
cody_gateway_embeddings_api_rate_interval_seconds | integer | null | Custom time interval over which the embeddings rate limit is applied | ||
cody_gateway_embeddings_api_allowed_models | text[] | null | Custom override for the set of models allowed for embedding | ||
cody_gateway_chat_rate_limit_allowed_models | text[] | null | |||
cody_gateway_code_rate_limit | bigint | null | |||
cody_gateway_code_rate_interval_seconds | integer | null | |||
cody_gateway_code_rate_limit_allowed_models | text[] | null | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Tables whose names start with registry_.
registry_extension_releases.creator_user_id → users.id — one users, many registry_extension_releases · required · ON DELETE NO ACTION · not indexedregistry_extension_releases.registry_extension_id → registry_extensions.id — one registry_extensions, many registry_extension_releases · required · ON DELETE CASCADE · indexedregistry_extension_releases.tenant_id → tenants.id — one tenants, many registry_extension_releases · optional · ON DELETE CASCADE · not indexedregistry_extensions.publisher_org_id → orgs.id — one orgs, many registry_extensions · optional · ON DELETE NO ACTION · not indexedregistry_extensions.publisher_user_id → users.id — one users, many registry_extensions · optional · ON DELETE NO ACTION · not indexedregistry_extensions.tenant_id → tenants.id — one tenants, many registry_extensions · optional · ON DELETE CASCADE · not indexedcreator_user_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan registry_extension_releases to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to registry_extension_releases maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan registry_extension_releases to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to registry_extension_releases maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — registry_extension_releases.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
registry_extension_id | integer | NOT NULL | registry_extensions.id 1:N · CASCADE | ||
creator_user_id | integer | NOT NULL | users.id 1:N | ||
release_version | citext | null | |||
release_tag | citext | NOT NULL | |||
manifest | jsonb | NOT NULL | |||
bundle | text | null | |||
created_at | timestamptz | NOT NULL | now() | ||
deleted_at | timestamptz | null | |||
source_map | text | null | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
publisher_org_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on orgs must scan registry_extensions to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to registry_extensions maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often orgs rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.publisher_user_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan registry_extensions to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to registry_extensions maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan registry_extensions to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to registry_extensions maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.publisher_org_id — registry_extensions.publisher_org_id may be NULL, so the relationship to orgs is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.publisher_user_id — registry_extensions.publisher_user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.tenant_id — registry_extensions.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.uuid — registry_extensions soft-deletes via deleted_at, but (uuid) is unique across live AND deleted rows. A user who deletes their account can never sign up again with the same value, and ON CONFLICT upserts will resurrect ghosts.publisher_org_id, publisher_user_id, tenant_id — registry_extensions has several nullable FKs (publisher_org_id, publisher_user_id, tenant_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
uuid | uuid | NOT NULL | |||
publisher_user_id | integer | null | users.id 1:N | ||
publisher_org_id | integer | null | orgs.id 1:N | ||
name | citext | NOT NULL | CHECK char_length(CAST(name AS text)) > 0 AND char_length(CAST(name AS text)) <= 128 | ||
manifest | text | null | |||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
deleted_at | timestamptz | null | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Table checks: char_length(CAST(name AS text)) > 0 AND char_length(CAST(name AS text)) <= 128; name ~ CAST('^[a-zA-Z0-9](?:[a-zA-Z0-9]|[_.-](?=[a-zA-Z0-9]))*$' AS citext); publisher_user_id IS NULL <> publisher_org_id IS NULL
Tables whose names start with search_.
search_context_default.search_context_id → search_contexts.id — one search_contexts, many search_context_default · required · ON DELETE CASCADE · not indexedsearch_context_default.tenant_id → tenants.id — one tenants, many search_context_default · optional · ON DELETE CASCADE · not indexedsearch_context_default.user_id → users.id — one users, at most one search_context_default · required · ON DELETE CASCADE · indexedsearch_context_repos.repo_id → repo.id — one repo, many search_context_repos · required · ON DELETE CASCADE · indexedsearch_context_repos.search_context_id → search_contexts.id — one search_contexts, many search_context_repos · required · ON DELETE CASCADE · not indexedsearch_context_repos.tenant_id → tenants.id — one tenants, many search_context_repos · optional · ON DELETE CASCADE · not indexedsearch_context_stars.search_context_id → search_contexts.id — one search_contexts, many search_context_stars · required · ON DELETE CASCADE · indexedsearch_context_stars.tenant_id → tenants.id — one tenants, many search_context_stars · optional · ON DELETE CASCADE · not indexedsearch_context_stars.user_id → users.id — one users, many search_context_stars · required · ON DELETE CASCADE · not indexedsearch_contexts.namespace_org_id → orgs.id — one orgs, many search_contexts · optional · ON DELETE CASCADE · not indexedsearch_contexts.namespace_user_id → users.id — one users, many search_contexts · optional · ON DELETE CASCADE · not indexedsearch_contexts.tenant_id → tenants.id — one tenants, many search_contexts · optional · ON DELETE CASCADE · not indexedWhen a user sets a search context as default, a row is inserted into this table. A user can only have one default search context. If the user has not set their default search context, it will fall back to `global`.
search_context_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on search_contexts must scan search_context_default to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to search_context_default maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often search_contexts rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan search_context_default to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to search_context_default maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — search_context_default.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
user_id PK | integer | NOT NULL | users.id 1:1 · CASCADE | ||
search_context_id | bigint | NOT NULL | search_contexts.id 1:N · CASCADE | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
search_context_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on search_contexts must scan search_context_repos to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to search_context_repos maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often search_contexts rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan search_context_repos to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to search_context_repos maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — search_context_repos.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
search_context_id | bigint | NOT NULL | search_contexts.id 1:N · CASCADE | ||
repo_id | integer | NOT NULL | repo.id 1:N · CASCADE | ||
revision | text | NOT NULL | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
When a user stars a search context, a row is inserted into this table. If the user unstars the search context, the row is deleted. The global context is not in the database, and therefore cannot be starred.
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan search_context_stars to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to search_context_stars maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.user_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan search_context_stars to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to search_context_stars maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — search_context_stars.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
search_context_id PK | bigint | NOT NULL | search_contexts.id 1:N · CASCADE | ||
user_id PK | integer | NOT NULL | users.id 1:N · CASCADE | ||
created_at | timestamptz | NOT NULL | now() | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
namespace_org_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on orgs must scan search_contexts to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to search_contexts maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often orgs rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.namespace_user_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan search_contexts to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to search_contexts maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan search_contexts to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to search_contexts maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.namespace_org_id — search_contexts.namespace_org_id may be NULL, so the relationship to orgs is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.namespace_user_id — search_contexts.namespace_user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.tenant_id — search_contexts.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.namespace_org_id, namespace_user_id, tenant_id — search_contexts has several nullable FKs (namespace_org_id, namespace_user_id, tenant_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
name | citext | NOT NULL | |||
description | text | NOT NULL | |||
public | boolean | NOT NULL | |||
namespace_user_id | integer | null | users.id 1:N · CASCADE | ||
namespace_org_id | integer | null | orgs.id 1:N · CASCADE | ||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
deleted_at | timestamptz | null | This column is unused as of Sourcegraph 3.34. Do not refer to it anymore. It will be dropped in a future version. | ||
query | text | null | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Table checks: namespace_user_id IS NULL OR namespace_org_id IS NULL
Tables whose names start with syntactic_.
syntactic_scip_indexing_jobs.tenant_id → tenants.id — one tenants, many syntactic_scip_indexing_jobs · optional · ON DELETE CASCADE · not indexedsyntactic_scip_last_index_scan.tenant_id → tenants.id — one tenants, many syntactic_scip_last_index_scan · optional · ON DELETE CASCADE · not indexedStores metadata about a code intel syntactic index job.
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan syntactic_scip_indexing_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to syntactic_scip_indexing_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — syntactic_scip_indexing_jobs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.state — state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
commit | text | NOT NULL | A 40-char revhash. Note that this commit may not be resolvable in the future.CHECK commit ~ CAST('^[a-f0-9]{40}$' AS text) | ||
queued_at | timestamptz | NOT NULL | now() | ||
state | text | NOT NULL | CAST('queued' AS text) | ||
failure_message | text | null | |||
started_at | timestamptz | null | |||
finished_at | timestamptz | null | |||
repository_id | integer | NOT NULL | |||
process_after | timestamptz | null | |||
num_resets | integer | NOT NULL | 0 | ||
num_failures | integer | NOT NULL | 0 | ||
execution_logs | json[] | null | An array of [log entries](https://sourcegraph.com/github.com/sourcegraph/sourcegraph@3.23/-/blob/internal/workerutil/store.go#L48:6) (encoded as JSON) from the most recent execution. | ||
commit_last_checked_at | timestamptz | null | |||
worker_hostname | text | NOT NULL | CAST('' AS text) | ||
last_heartbeat_at | timestamptz | null | |||
cancel | boolean | NOT NULL | FALSE | ||
should_reindex | boolean | NOT NULL | FALSE | ||
enqueuer_user_id | integer | NOT NULL | 0 | ID of the user who scheduled this index. Records with a non-NULL user ID are prioritised over the rest | |
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Table checks: commit ~ CAST('^[a-f0-9]{40}$' AS text)
Tracks the last time repository was checked for syntactic indexing job scheduling.
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan syntactic_scip_last_index_scan to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to syntactic_scip_last_index_scan maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — syntactic_scip_last_index_scan.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
repository_id PK | integer | NOT NULL | |||
last_index_scan_at | timestamptz | NOT NULL | The last time uploads of this repository were considered for syntactic indexing job scheduling. | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Tables whose names start with user_.
user_credentials.github_app_id → github_apps.id — one github_apps, many user_credentials · optional · ON DELETE CASCADE · not indexeduser_credentials.tenant_id → tenants.id — one tenants, many user_credentials · optional · ON DELETE CASCADE · not indexeduser_credentials.user_id → users.id — one users, many user_credentials · required · ON DELETE CASCADE · not indexeduser_emails.tenant_id → tenants.id — one tenants, many user_emails · optional · ON DELETE CASCADE · not indexeduser_emails.user_id → users.id — one users, many user_emails · required · ON DELETE NO ACTION · indexeduser_external_accounts.tenant_id → tenants.id — one tenants, many user_external_accounts · optional · ON DELETE CASCADE · not indexeduser_external_accounts.user_id → users.id — one users, many user_external_accounts · required · ON DELETE NO ACTION · indexeduser_onboarding_tour.tenant_id → tenants.id — one tenants, many user_onboarding_tour · optional · ON DELETE CASCADE · not indexeduser_onboarding_tour.updated_by → users.id — one users, many user_onboarding_tour · optional · ON DELETE NO ACTION · not indexeduser_pending_permissions.tenant_id → tenants.id — one tenants, many user_pending_permissions · optional · ON DELETE CASCADE · not indexeduser_permissions.tenant_id → tenants.id — one tenants, many user_permissions · optional · ON DELETE CASCADE · not indexeduser_public_repos.repo_id → repo.id — one repo, many user_public_repos · required · ON DELETE CASCADE · not indexeduser_public_repos.tenant_id → tenants.id — one tenants, many user_public_repos · optional · ON DELETE CASCADE · not indexeduser_public_repos.user_id → users.id — one users, many user_public_repos · required · ON DELETE CASCADE · indexeduser_repo_permissions.repo_id → repo.id — one repo, many user_repo_permissions · required · ON DELETE CASCADE · indexeduser_repo_permissions.tenant_id → tenants.id — one tenants, many user_repo_permissions · optional · ON DELETE CASCADE · not indexeduser_repo_permissions.user_external_account_id → user_external_accounts.id — one user_external_accounts, many user_repo_permissions · optional · ON DELETE CASCADE · indexeduser_repo_permissions.user_id → users.id — one users, many user_repo_permissions · optional · ON DELETE CASCADE · indexeduser_roles.role_id → roles.id — one roles, many user_roles · required · ON DELETE CASCADE · not indexeduser_roles.tenant_id → tenants.id — one tenants, many user_roles · optional · ON DELETE CASCADE · not indexeduser_roles.user_id → users.id — one users, many user_roles · required · ON DELETE CASCADE · indexedgithub_app_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on github_apps must scan user_credentials to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to user_credentials maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often github_apps rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan user_credentials to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to user_credentials maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.user_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan user_credentials to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to user_credentials maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.github_app_id — user_credentials.github_app_id may be NULL, so the relationship to github_apps is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.tenant_id — user_credentials.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.external_service_type — external_service_type is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.external_service_type, external_service_id — external_service_id points at different tables depending on external_service_type. No FK can express that, so orphans accumulate silently and every join needs a CASE. Acceptable for append-only audit data; painful anywhere the target must still exist.github_app_id, tenant_id — user_credentials has several nullable FKs (github_app_id, tenant_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
domain | text | NOT NULL | |||
user_id | integer | NOT NULL | users.id 1:N · CASCADE | ||
external_service_type | text | NOT NULL | |||
external_service_id | text | NOT NULL | |||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
credential | bytea | NOT NULL | |||
ssh_migration_applied | boolean | NOT NULL | FALSE | ||
encryption_key_id | text | NOT NULL | CAST('' AS text) | ||
github_app_id | integer | null | github_apps.id 1:N · CASCADE | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Table checks: github_app_id IS NULL OR external_service_type = CAST('github' AS text)
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan user_emails to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to user_emails maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — user_emails.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
user_id | integer | NOT NULL | users.id 1:N | ||
email | citext | NOT NULL | |||
created_at | timestamptz | NOT NULL | now() | ||
verification_code | text | null | |||
verified_at | timestamptz | null | |||
last_verification_sent_at | timestamptz | null | |||
is_primary | boolean | NOT NULL | FALSE | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan user_external_accounts to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to user_external_accounts maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — user_external_accounts.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.service_type — service_type is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.service_type, service_id — service_id points at different tables depending on service_type. No FK can express that, so orphans accumulate silently and every join needs a CASE. Acceptable for append-only audit data; painful anywhere the target must still exist.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
user_id | integer | NOT NULL | users.id 1:N | ||
service_type | text | NOT NULL | |||
service_id | text | NOT NULL | |||
account_id | text | NOT NULL | |||
auth_data | text | null | |||
account_data | text | null | |||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
deleted_at | timestamptz | null | |||
client_id | text | NOT NULL | |||
expired_at | timestamptz | null | |||
last_valid_at | timestamptz | null | |||
encryption_key_id | text | NOT NULL | CAST('' AS text) | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan user_onboarding_tour to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to user_onboarding_tour maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.updated_by — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan user_onboarding_tour to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to user_onboarding_tour maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — user_onboarding_tour.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.updated_by — user_onboarding_tour.updated_by may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.created_at — created_at stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
raw_json | text | NOT NULL | |||
created_at | timestamp | NOT NULL | now() | ||
updated_by | integer | null | users.id 1:N | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan user_pending_permissions to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to user_pending_permissions maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — user_pending_permissions.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.object_type — object_type is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.service_type — service_type is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.service_type, service_id — service_id points at different tables depending on service_type. No FK can express that, so orphans accumulate silently and every join needs a CASE. Acceptable for append-only audit data; painful anywhere the target must still exist.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id | bigint | NOT NULL | |||
bind_id | text | NOT NULL | |||
permission | text | NOT NULL | |||
object_type | text | NOT NULL | |||
updated_at | timestamptz | NOT NULL | |||
service_type | text | NOT NULL | |||
service_id | text | NOT NULL | |||
object_ids_ints | integer[] | NOT NULL | CAST('{}' AS integer[]) | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan user_permissions to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to user_permissions maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — user_permissions.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.object_type — object_type is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
user_id | integer | NOT NULL | |||
permission | text | NOT NULL | |||
object_type | text | NOT NULL | |||
updated_at | timestamptz | NOT NULL | |||
synced_at | timestamptz | null | |||
object_ids_ints | integer[] | NOT NULL | CAST('{}' AS integer[]) | ||
migrated | boolean | null | TRUE | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
repo_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on repo must scan user_public_repos to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to user_public_repos maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often repo rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan user_public_repos to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to user_public_repos maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — user_public_repos.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
user_id | integer | NOT NULL | users.id 1:N · CASCADE | ||
repo_uri | text | NOT NULL | |||
repo_id | integer | NOT NULL | repo.id 1:N · CASCADE | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan user_repo_permissions to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to user_repo_permissions maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — user_repo_permissions.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.user_external_account_id — user_repo_permissions.user_external_account_id may be NULL, so the relationship to user_external_accounts is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.user_id — user_repo_permissions.user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.tenant_id, user_external_account_id, user_id — user_repo_permissions has several nullable FKs (tenant_id, user_external_account_id, user_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
user_id | integer | null | users.id 1:N · CASCADE | ||
repo_id | integer | NOT NULL | repo.id 1:N · CASCADE | ||
user_external_account_id | integer | null | user_external_accounts.id 1:N · CASCADE | ||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
source | text | NOT NULL | CAST('sync' AS text) | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
role_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on roles must scan user_roles to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to user_roles maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often roles rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan user_roles to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to user_roles maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — user_roles.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
user_id PK | integer | NOT NULL | users.id 1:N · CASCADE | ||
role_id PK | integer | NOT NULL | roles.id 1:N · CASCADE | ||
created_at | timestamptz | NOT NULL | now() | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Tables whose names start with vulnerability_.
vulnerability_affected_packages.vulnerability_id → vulnerabilities.id — one vulnerabilities, many vulnerability_affected_packages · required · ON DELETE CASCADE · indexedvulnerability_affected_packages.tenant_id → tenants.id — one tenants, many vulnerability_affected_packages · optional · ON DELETE CASCADE · not indexedvulnerability_affected_symbols.vulnerability_affected_package_id → vulnerability_affected_packages.id — one vulnerability_affected_packages, many vulnerability_affected_symbols · required · ON DELETE CASCADE · indexedvulnerability_affected_symbols.tenant_id → tenants.id — one tenants, many vulnerability_affected_symbols · optional · ON DELETE CASCADE · not indexedvulnerability_matches.upload_id → lsif_uploads.id — one lsif_uploads, many vulnerability_matches · required · ON DELETE CASCADE · indexedvulnerability_matches.vulnerability_affected_package_id → vulnerability_affected_packages.id — one vulnerability_affected_packages, many vulnerability_matches · required · ON DELETE CASCADE · indexedvulnerability_matches.tenant_id → tenants.id — one tenants, many vulnerability_matches · optional · ON DELETE CASCADE · not indexedtenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan vulnerability_affected_packages to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to vulnerability_affected_packages maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — vulnerability_affected_packages.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
vulnerability_id | integer | NOT NULL | vulnerabilities.id 1:N · CASCADE | ||
package_name | text | NOT NULL | |||
language | text | NOT NULL | |||
namespace | text | NOT NULL | |||
version_constraint | text[] | NOT NULL | |||
fixed | boolean | NOT NULL | |||
fixed_in | text | null | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan vulnerability_affected_symbols to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to vulnerability_affected_symbols maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — vulnerability_affected_symbols.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
vulnerability_affected_package_id | integer | NOT NULL | vulnerability_affected_packages.id 1:N · CASCADE | ||
path | text | NOT NULL | |||
symbols | text[] | NOT NULL | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan vulnerability_matches to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to vulnerability_matches maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — vulnerability_matches.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
upload_id | integer | NOT NULL | lsif_uploads.id 1:N · CASCADE | ||
vulnerability_affected_package_id | integer | NOT NULL | vulnerability_affected_packages.id 1:N · CASCADE | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Tables whose name prefix is theirs alone.
aggregated_user_statistics.tenant_id → tenants.id — one tenants, many aggregated_user_statistics · optional · ON DELETE CASCADE · not indexedaggregated_user_statistics.user_id → users.id — one users, at most one aggregated_user_statistics · required · ON DELETE CASCADE · indexedchangesets.current_spec_id → changeset_specs.id — one changeset_specs, many changesets · optional · ON DELETE NO ACTION · indexedchangesets.owned_by_batch_change_id → batch_changes.id — one batch_changes, many changesets · optional · ON DELETE SET NULL · not indexedchangesets.previous_spec_id → changeset_specs.id — one changeset_specs, many changesets · optional · ON DELETE NO ACTION · not indexedchangesets.repo_id → repo.id — one repo, many changesets · required · ON DELETE CASCADE · indexedchangesets.tenant_id → tenants.id — one tenants, many changesets · optional · ON DELETE CASCADE · not indexedcached_available_indexers.tenant_id → tenants.id — one tenants, many cached_available_indexers · optional · ON DELETE CASCADE · not indexedcode_hosts.tenant_id → tenants.id — one tenants, many code_hosts · optional · ON DELETE CASCADE · not indexedcommit_authors.tenant_id → tenants.id — one tenants, many commit_authors · optional · ON DELETE CASCADE · not indexedconfiguration_policies_audit_logs.tenant_id → tenants.id — one tenants, many configuration_policies_audit_logs · optional · ON DELETE CASCADE · not indexedcontext_detection_embedding_jobs.tenant_id → tenants.id — one tenants, many context_detection_embedding_jobs · optional · ON DELETE CASCADE · not indexedexplicit_permissions_bitbucket_projects_jobs.tenant_id → tenants.id — one tenants, many explicit_permissions_bitbucket_projects_jobs · optional · ON DELETE CASCADE · not indexedglobal_state.tenant_id → tenants.id — one tenants, many global_state · optional · ON DELETE CASCADE · not indexednames.org_id → orgs.id — one orgs, many names · optional · ON DELETE CASCADE · not indexednames.team_id → teams.id — one teams, many names · optional · ON DELETE CASCADE · not indexednames.tenant_id → tenants.id — one tenants, many names · optional · ON DELETE CASCADE · not indexednames.user_id → users.id — one users, many names · optional · ON DELETE CASCADE · not indexednamespace_permissions.tenant_id → tenants.id — one tenants, many namespace_permissions · optional · ON DELETE CASCADE · not indexednamespace_permissions.user_id → users.id — one users, many namespace_permissions · required · ON DELETE CASCADE · not indexednotebook_stars.notebook_id → notebooks.id — one notebooks, many notebook_stars · required · ON DELETE CASCADE · indexednotebook_stars.tenant_id → tenants.id — one tenants, many notebook_stars · optional · ON DELETE CASCADE · not indexednotebook_stars.user_id → users.id — one users, many notebook_stars · required · ON DELETE CASCADE · indexednotebooks.creator_user_id → users.id — one users, many notebooks · optional · ON DELETE SET NULL · not indexednotebooks.namespace_org_id → orgs.id — one orgs, many notebooks · optional · ON DELETE SET NULL · indexednotebooks.namespace_user_id → users.id — one users, many notebooks · optional · ON DELETE SET NULL · indexednotebooks.tenant_id → tenants.id — one tenants, many notebooks · optional · ON DELETE CASCADE · not indexednotebooks.updater_user_id → users.id — one users, many notebooks · optional · ON DELETE SET NULL · not indexedownership_path_stats.file_path_id → repo_paths.id — one repo_paths, at most one ownership_path_stats · required · ON DELETE NO ACTION · indexedownership_path_stats.tenant_id → tenants.id — one tenants, many ownership_path_stats · optional · ON DELETE CASCADE · not indexedpermission_sync_jobs.repository_id → repo.id — one repo, many permission_sync_jobs · optional · ON DELETE CASCADE · indexedpermission_sync_jobs.tenant_id → tenants.id — one tenants, many permission_sync_jobs · optional · ON DELETE CASCADE · not indexedpermission_sync_jobs.triggered_by_user_id → users.id — one users, many permission_sync_jobs · optional · ON DELETE SET NULL · not indexedpermission_sync_jobs.user_id → users.id — one users, many permission_sync_jobs · optional · ON DELETE CASCADE · indexedpermissions.tenant_id → tenants.id — one tenants, many permissions · optional · ON DELETE CASCADE · not indexedphabricator_repos.tenant_id → tenants.id — one tenants, many phabricator_repos · optional · ON DELETE CASCADE · not indexedprompts.created_by → users.id — one users, many prompts · optional · ON DELETE SET NULL · not indexedprompts.owner_org_id → orgs.id — one orgs, many prompts · optional · ON DELETE CASCADE · indexedprompts.owner_user_id → users.id — one users, many prompts · optional · ON DELETE CASCADE · indexedprompts.tenant_id → tenants.id — one tenants, many prompts · optional · ON DELETE CASCADE · not indexedprompts.updated_by → users.id — one users, many prompts · optional · ON DELETE SET NULL · not indexedusers.tenant_id → tenants.id — one tenants, many users · optional · ON DELETE CASCADE · not indexedquery_runner_state.tenant_id → tenants.id — one tenants, many query_runner_state · optional · ON DELETE CASCADE · not indexedredis_key_value.tenant_id → tenants.id — one tenants, many redis_key_value · optional · ON DELETE CASCADE · not indexedrole_permissions.permission_id → permissions.id — one permissions, many role_permissions · required · ON DELETE CASCADE · indexedrole_permissions.role_id → roles.id — one roles, many role_permissions · required · ON DELETE CASCADE · not indexedrole_permissions.tenant_id → tenants.id — one tenants, many role_permissions · optional · ON DELETE CASCADE · not indexedroles.tenant_id → tenants.id — one tenants, many roles · optional · ON DELETE CASCADE · not indexedsaved_searches.created_by → users.id — one users, many saved_searches · optional · ON DELETE SET NULL · not indexedsaved_searches.org_id → orgs.id — one orgs, many saved_searches · optional · ON DELETE NO ACTION · not indexedsaved_searches.tenant_id → tenants.id — one tenants, many saved_searches · optional · ON DELETE CASCADE · not indexedsaved_searches.updated_by → users.id — one users, many saved_searches · optional · ON DELETE SET NULL · not indexedsaved_searches.user_id → users.id — one users, many saved_searches · optional · ON DELETE NO ACTION · not indexedsecurity_event_logs.tenant_id → tenants.id — one tenants, many security_event_logs · optional · ON DELETE CASCADE · not indexedsettings.author_user_id → users.id — one users, many settings · optional · ON DELETE RESTRICT · not indexedsettings.org_id → orgs.id — one orgs, many settings · optional · ON DELETE RESTRICT · indexedsettings.tenant_id → tenants.id — one tenants, many settings · optional · ON DELETE CASCADE · not indexedsettings.user_id → users.id — one users, many settings · optional · ON DELETE RESTRICT · indexedsub_repo_permissions.repo_id → repo.id — one repo, many sub_repo_permissions · required · ON DELETE CASCADE · indexedsub_repo_permissions.tenant_id → tenants.id — one tenants, many sub_repo_permissions · optional · ON DELETE CASCADE · not indexedsub_repo_permissions.user_id → users.id — one users, many sub_repo_permissions · required · ON DELETE CASCADE · indexedsurvey_responses.tenant_id → tenants.id — one tenants, many survey_responses · optional · ON DELETE CASCADE · not indexedsurvey_responses.user_id → users.id — one users, many survey_responses · optional · ON DELETE NO ACTION · not indexedteam_members.team_id → teams.id — one teams, many team_members · required · ON DELETE CASCADE · indexedteam_members.tenant_id → tenants.id — one tenants, many team_members · optional · ON DELETE CASCADE · not indexedteam_members.user_id → users.id — one users, many team_members · required · ON DELETE CASCADE · not indexedteams.creator_id → users.id — one users, many teams · optional · ON DELETE SET NULL · not indexedteams.parent_team_id → teams.id — one teams, many teams · optional · ON DELETE CASCADE · not indexedteams.tenant_id → tenants.id — one tenants, many teams · optional · ON DELETE CASCADE · not indexedtelemetry_events_export_queue.tenant_id → tenants.id — one tenants, many telemetry_events_export_queue · optional · ON DELETE CASCADE · not indexedtemporary_settings.tenant_id → tenants.id — one tenants, many temporary_settings · optional · ON DELETE CASCADE · not indexedtemporary_settings.user_id → users.id — one users, at most one temporary_settings · required · ON DELETE CASCADE · indexedvulnerabilities.tenant_id → tenants.id — one tenants, many vulnerabilities · optional · ON DELETE CASCADE · not indexedwebhook_logs.external_service_id → external_services.id — one external_services, many webhook_logs · optional · ON DELETE CASCADE · indexedwebhook_logs.tenant_id → tenants.id — one tenants, many webhook_logs · optional · ON DELETE CASCADE · not indexedwebhook_logs.webhook_id → webhooks.id — one webhooks, many webhook_logs · optional · ON DELETE CASCADE · not indexedwebhooks.created_by_user_id → users.id — one users, many webhooks · optional · ON DELETE SET NULL · not indexedwebhooks.tenant_id → tenants.id — one tenants, many webhooks · optional · ON DELETE CASCADE · not indexedwebhooks.updated_by_user_id → users.id — one users, many webhooks · optional · ON DELETE SET NULL · not indexedzoekt_repos.repo_id → repo.id — one repo, at most one zoekt_repos · required · ON DELETE CASCADE · indexedzoekt_repos.tenant_id → tenants.id — one tenants, many zoekt_repos · optional · ON DELETE CASCADE · not indexedtenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan aggregated_user_statistics to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to aggregated_user_statistics maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — aggregated_user_statistics.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
user_id PK | bigint | NOT NULL | users.id 1:1 · CASCADE | ||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
user_last_active_at | timestamptz | null | |||
user_events_count | bigint | null | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
owned_by_batch_change_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on batch_changes must scan changesets to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to changesets maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often batch_changes rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.previous_spec_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on changeset_specs must scan changesets to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to changesets maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often changeset_specs rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan changesets to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to changesets maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.current_spec_id — changesets.current_spec_id may be NULL, so the relationship to changeset_specs is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.owned_by_batch_change_id — changesets.owned_by_batch_change_id may be NULL, so the relationship to batch_changes is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.previous_spec_id — changesets.previous_spec_id may be NULL, so the relationship to changeset_specs is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.tenant_id — changesets.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.external_state — external_state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.external_review_state — external_review_state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.external_check_state — external_check_state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.publication_state — publication_state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.reconciler_state — reconciler_state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.computed_state — computed_state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.current_spec_id, owned_by_batch_change_id, previous_spec_id, tenant_id — changesets has several nullable FKs (current_spec_id, owned_by_batch_change_id, previous_spec_id, tenant_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
batch_change_ids | jsonb | NOT NULL | CAST('{}' AS jsonb) | CHECK jsonb_typeof(batch_change_ids) = CAST('object' AS text) | |
repo_id | integer | NOT NULL | repo.id 1:N · CASCADE | ||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
metadata | jsonb | null | CAST('{}' AS jsonb) | CHECK jsonb_typeof(metadata) = CAST('object' AS text) | |
external_id | text | null | CHECK external_id <> CAST('' AS text) | ||
external_service_type | text | NOT NULL | CHECK external_service_type <> CAST('' AS text) | ||
external_deleted_at | timestamptz | null | |||
external_branch | text | null | CHECK external_branch ~~ CAST('refs/heads/%' AS text) | ||
external_updated_at | timestamptz | null | |||
external_state | text | null | |||
external_review_state | text | null | |||
external_check_state | text | null | |||
diff_stat_added | integer | null | |||
diff_stat_deleted | integer | null | |||
sync_state | jsonb | NOT NULL | CAST('{}' AS jsonb) | ||
current_spec_id | bigint | null | changeset_specs.id 1:N | ||
previous_spec_id | bigint | null | changeset_specs.id 1:N | ||
publication_state | text | null | CAST('UNPUBLISHED' AS text) | ||
owned_by_batch_change_id | bigint | null | batch_changes.id 1:N · SET NULL | ||
reconciler_state | text | null | CAST('queued' AS text) | ||
failure_message | text | null | |||
started_at | timestamptz | null | |||
finished_at | timestamptz | null | |||
process_after | timestamptz | null | |||
num_resets | integer | NOT NULL | 0 | ||
closing | boolean | NOT NULL | FALSE | ||
num_failures | integer | NOT NULL | 0 | ||
log_contents | text | null | |||
execution_logs | json[] | null | |||
syncer_error | text | null | |||
external_title | text | null | Normalized property generated on save using Changeset.Title() | ||
worker_hostname | text | NOT NULL | CAST('' AS text) | ||
ui_publication_state | batch_changes_changeset_ui_publication_state | null | |||
last_heartbeat_at | timestamptz | null | |||
external_fork_namespace | citext | null | |||
queued_at | timestamptz | null | now() | ||
cancel | boolean | NOT NULL | FALSE | ||
detached_at | timestamptz | null | |||
computed_state | text | NOT NULL | |||
external_fork_name | citext | null | |||
previous_failure_message | text | null | |||
commit_verification | jsonb | NOT NULL | CAST('{}' AS jsonb) | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Table checks: jsonb_typeof(batch_change_ids) = CAST('object' AS text); external_id <> CAST('' AS text); external_service_type <> CAST('' AS text); jsonb_typeof(metadata) = CAST('object' AS text); external_branch ~~ CAST('refs/heads/%' AS text)
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan cached_available_indexers to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to cached_available_indexers maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — cached_available_indexers.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
repository_id | integer | NOT NULL | |||
num_events | integer | NOT NULL | |||
available_indexers | jsonb | NOT NULL | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan code_hosts to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to code_hosts maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — code_hosts.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.kind — kind is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
kind | text | NOT NULL | |||
url UK | text | NOT NULL | |||
api_rate_limit_quota | integer | null | |||
api_rate_limit_interval_seconds | integer | null | |||
git_rate_limit_quota | integer | null | |||
git_rate_limit_interval_seconds | integer | null | |||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan commit_authors to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to commit_authors maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — commit_authors.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
email | text | NOT NULL | |||
name | text | NOT NULL | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan configuration_policies_audit_logs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to configuration_policies_audit_logs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — configuration_policies_audit_logs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
log_timestamp | timestamptz | null | clock_timestamp() | Timestamp for this log entry. | |
record_deleted_at | timestamptz | null | Set once the upload this entry is associated with is deleted. Once NOW() - record_deleted_at is above a certain threshold, this log entry will be deleted. | ||
policy_id | integer | NOT NULL | |||
transition_columns | hstore[] | null | Array of changes that occurred to the upload for this entry, in the form of {"column"=>"<column name>", "old"=>"<previous value>", "new"=>"<new value>"}. | ||
sequence | bigint | NOT NULL | |||
operation | audit_log_operation | NOT NULL | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan context_detection_embedding_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to context_detection_embedding_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — context_detection_embedding_jobs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.state — state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
state | text | null | CAST('queued' AS text) | ||
failure_message | text | null | |||
queued_at | timestamptz | null | now() | ||
started_at | timestamptz | null | |||
finished_at | timestamptz | null | |||
process_after | timestamptz | null | |||
num_resets | integer | NOT NULL | 0 | ||
num_failures | integer | NOT NULL | 0 | ||
last_heartbeat_at | timestamptz | null | |||
execution_logs | json[] | null | |||
worker_hostname | text | NOT NULL | CAST('' AS text) | ||
cancel | boolean | NOT NULL | FALSE | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
critical_and_site_config references nothing and nothing references it. Either it is a staging/log table (fine, say so), or it is dead, or it is the seed of a second data model growing beside the first.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
type | critical_or_site | NOT NULL | |||
contents | text | NOT NULL | |||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
author_user_id | integer | null | A null value indicates that this config was most likely added by code on the start-up path, for example from the SITE_CONFIG_FILE unless the config itself was added before this column existed in which case it could also have been a user. | ||
redacted_contents | text | null | This column stores the contents but redacts all secrets. The redacted form is a sha256 hash of the secret appended to the REDACTED string. This is used to generate diffs between two subsequent changes in a way that allows us to detect changes to any secrets while also ensuring that we do not leak it in the diff. A null value indicates that this config was added before this column was added or redacting the secrets during write failed so we skipped writing to this column instead of a hard failure. |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan explicit_permissions_bitbucket_projects_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to explicit_permissions_bitbucket_projects_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — explicit_permissions_bitbucket_projects_jobs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.state — state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
state | text | null | CAST('queued' AS text) | ||
failure_message | text | null | |||
queued_at | timestamptz | null | now() | ||
started_at | timestamptz | null | |||
finished_at | timestamptz | null | |||
process_after | timestamptz | null | |||
num_resets | integer | NOT NULL | 0 | ||
num_failures | integer | NOT NULL | 0 | ||
last_heartbeat_at | timestamptz | null | |||
execution_logs | json[] | null | |||
worker_hostname | text | NOT NULL | CAST('' AS text) | ||
project_key | text | NOT NULL | |||
external_service_id | integer | NOT NULL | |||
permissions | json[] | null | |||
unrestricted | boolean | NOT NULL | FALSE | ||
cancel | boolean | NOT NULL | FALSE | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Table checks: (permissions IS NOT NULL AND …(unrestricted)) OR (permissions IS NULL AND …(unrestricted))
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan global_state to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to global_state maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — global_state.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
site_id PK | uuid | NOT NULL | |||
initialized | boolean | NOT NULL | FALSE | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
org_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on orgs must scan names to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to names maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often orgs rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.team_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on teams must scan names to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to names maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often teams rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan names to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to names maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.user_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan names to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to names maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.org_id — names.org_id may be NULL, so the relationship to orgs is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.team_id — names.team_id may be NULL, so the relationship to teams is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.tenant_id — names.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.user_id — names.user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.org_id, team_id, tenant_id, user_id — names has several nullable FKs (org_id, team_id, tenant_id, user_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
name PK | citext | NOT NULL | |||
user_id | integer | null | users.id 1:N · CASCADE | ||
org_id | integer | null | orgs.id 1:N · CASCADE | ||
team_id | integer | null | teams.id 1:N · CASCADE | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Table checks: user_id IS NOT NULL OR org_id IS NOT NULL OR team_id IS NOT NULL
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan namespace_permissions to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to namespace_permissions maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.user_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan namespace_permissions to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to namespace_permissions maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — namespace_permissions.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
namespace | text | NOT NULL | CHECK namespace <> CAST('' AS text) | ||
resource_id | integer | NOT NULL | |||
user_id | integer | NOT NULL | users.id 1:N · CASCADE | ||
created_at | timestamptz | NOT NULL | now() | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Table checks: namespace <> CAST('' AS text)
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan notebook_stars to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to notebook_stars maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — notebook_stars.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
notebook_id PK | integer | NOT NULL | notebooks.id 1:N · CASCADE | ||
user_id PK | integer | NOT NULL | users.id 1:N · CASCADE | ||
created_at | timestamptz | NOT NULL | now() | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
creator_user_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan notebooks to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to notebooks maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan notebooks to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to notebooks maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.updater_user_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan notebooks to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to notebooks maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.creator_user_id — notebooks.creator_user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.namespace_org_id — notebooks.namespace_org_id may be NULL, so the relationship to orgs is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.namespace_user_id — notebooks.namespace_user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.tenant_id — notebooks.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.updater_user_id — notebooks.updater_user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.creator_user_id, namespace_org_id, namespace_user_id, tenant_id, updater_user_id — notebooks has several nullable FKs (creator_user_id, namespace_org_id, namespace_user_id, tenant_id, updater_user_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
title | text | NOT NULL | |||
blocks | jsonb | NOT NULL | CAST('[]' AS jsonb) | CHECK jsonb_typeof(blocks) = CAST('array' AS text) | |
public | boolean | NOT NULL | |||
creator_user_id | integer | null | users.id 1:N · SET NULL | ||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
blocks_tsvector | tsvector | null | |||
namespace_user_id | integer | null | users.id 1:N · SET NULL | ||
namespace_org_id | integer | null | orgs.id 1:N · SET NULL | ||
updater_user_id | integer | null | users.id 1:N · SET NULL | ||
pattern_type | pattern_type | NOT NULL | CAST('keyword' AS pattern_type) | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Table checks: jsonb_typeof(blocks) = CAST('array' AS text); (namespace_user_id IS NULL AND namespace_org_id IS NULL) OR namespace_user_id IS NULL <> namespace_org_id IS NULL
Data on how many files in given tree are owned by anyone. We choose to have a table for `ownership_path_stats` - more general than for CODEOWNERS, with a specific tree_codeowned_files_count CODEOWNERS column. The reason for that is that we aim at expanding path stats by including total owned files (via CODEOWNERS or assigned ownership), and perhaps files count by assigned ownership only.
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan ownership_path_stats to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to ownership_path_stats maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — ownership_path_stats.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.last_updated_at — last_updated_at stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
file_path_id PK | integer | NOT NULL | repo_paths.id 1:1 | ||
tree_codeowned_files_count | integer | null | |||
last_updated_at | timestamp | NOT NULL | When the last background job updating counts run. | ||
tree_assigned_ownership_files_count | integer | null | |||
tree_any_ownership_files_count | integer | null | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan permission_sync_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to permission_sync_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.triggered_by_user_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan permission_sync_jobs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to permission_sync_jobs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.repository_id — permission_sync_jobs.repository_id may be NULL, so the relationship to repo is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.tenant_id — permission_sync_jobs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.triggered_by_user_id — permission_sync_jobs.triggered_by_user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.user_id — permission_sync_jobs.user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.state — state is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.repository_id, tenant_id, triggered_by_user_id, user_id — permission_sync_jobs has several nullable FKs (repository_id, tenant_id, triggered_by_user_id, user_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
state | text | null | CAST('queued' AS text) | ||
reason | text | NOT NULL | Specifies why permissions sync job was triggered. | ||
failure_message | text | null | |||
queued_at | timestamptz | null | now() | ||
started_at | timestamptz | null | |||
finished_at | timestamptz | null | |||
process_after | timestamptz | null | |||
num_resets | integer | NOT NULL | 0 | ||
num_failures | integer | NOT NULL | 0 | ||
last_heartbeat_at | timestamptz | null | |||
execution_logs | json[] | null | |||
worker_hostname | text | NOT NULL | CAST('' AS text) | ||
cancel | boolean | NOT NULL | FALSE | ||
repository_id | integer | null | repo.id 1:N · CASCADE | ||
user_id | integer | null | users.id 1:N · CASCADE | ||
triggered_by_user_id | integer | null | users.id 1:N · SET NULL | Specifies an ID of a user who triggered a sync. | |
priority | integer | NOT NULL | 0 | Specifies numeric priority for the permissions sync job. | |
invalidate_caches | boolean | NOT NULL | FALSE | ||
cancellation_reason | text | null | Specifies why permissions sync job was cancelled. | ||
no_perms | boolean | NOT NULL | FALSE | ||
permissions_added | integer | NOT NULL | 0 | ||
permissions_removed | integer | NOT NULL | 0 | ||
permissions_found | integer | NOT NULL | 0 | ||
code_host_states | json[] | null | |||
is_partial_success | boolean | null | FALSE | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Table checks: user_id IS NULL <> repository_id IS NULL
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan permissions to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to permissions maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — permissions.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
namespace | text | NOT NULL | CHECK namespace <> CAST('' AS text) | ||
action | text | NOT NULL | CHECK action <> CAST('' AS text) | ||
created_at | timestamptz | NOT NULL | now() | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Table checks: action <> CAST('' AS text); namespace <> CAST('' AS text)
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan phabricator_repos to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to phabricator_repos maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — phabricator_repos.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.repo_name — phabricator_repos soft-deletes via deleted_at, but (repo_name) is unique across live AND deleted rows. A user who deletes their account can never sign up again with the same value, and ON CONFLICT upserts will resurrect ghosts.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
callsign | citext | NOT NULL | |||
repo_name UK | citext | NOT NULL | |||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
deleted_at | timestamptz | null | |||
url | text | NOT NULL | CAST('' AS text) | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
created_by — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan prompts to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to prompts maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan prompts to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to prompts maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.updated_by — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan prompts to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to prompts maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.created_by — prompts.created_by may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.owner_org_id — prompts.owner_org_id may be NULL, so the relationship to orgs is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.owner_user_id — prompts.owner_user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.tenant_id — prompts.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.updated_by — prompts.updated_by may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.owner_org_id, owner_user_id, tenant_id — prompts has several nullable FKs (owner_org_id, owner_user_id, tenant_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
name | citext | NOT NULL | CHECK char_length(CAST(name AS text)) <= 255 | ||
description | text | NOT NULL | CHECK char_length(description) <= (1024 * 50) | ||
definition_text | text | NOT NULL | CHECK char_length(definition_text) <= (1024 * 100) | ||
draft | boolean | NOT NULL | FALSE | ||
visibility_secret | boolean | NOT NULL | TRUE | ||
owner_user_id | integer | null | users.id 1:N · CASCADE | ||
owner_org_id | integer | null | orgs.id 1:N · CASCADE | ||
created_by | integer | null | users.id 1:N · SET NULL | ||
created_at | timestamptz | NOT NULL | now() | ||
updated_by | integer | null | users.id 1:N · SET NULL | ||
updated_at | timestamptz | NOT NULL | now() | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Table checks: char_length(definition_text) <= (1024 * 100); char_length(description) <= (1024 * 50); (owner_user_id IS NOT NULL AND owner_org_id IS NULL) OR (owner_org_id IS NOT NULL AND owner_user_id IS NULL); char_length(CAST(name AS text)) <= 255; name ~ CAST('^[a-zA-Z0-9](?:[a-zA-Z0-9]|[-.](?=[a-zA-Z0-9]))*-?$' AS citext)
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan users to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to users maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — users.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
username | citext | NOT NULL | CHECK char_length(CAST(username AS text)) <= 255 | ||
display_name | text | null | CHECK char_length(display_name) <= 255 | ||
avatar_url | text | null | |||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
deleted_at | timestamptz | null | |||
invite_quota | integer | NOT NULL | 100 | ||
passwd | text | null | |||
passwd_reset_code | text | null | |||
passwd_reset_time | timestamptz | null | |||
site_admin | boolean | NOT NULL | FALSE | ||
page_views | integer | NOT NULL | 0 | ||
search_queries | integer | NOT NULL | 0 | ||
billing_customer_id | text | null | |||
invalidated_sessions_at | timestamptz | NOT NULL | now() | ||
tos_accepted | boolean | NOT NULL | FALSE | ||
completions_quota | integer | null | |||
code_completions_quota | integer | null | |||
completed_post_signup | boolean | NOT NULL | FALSE | ||
cody_pro_enabled_at | timestamptz | null | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Table checks: char_length(display_name) <= 255; char_length(CAST(username AS text)) <= 255; username ~ CAST('^\w(?:\w|[-.](?=\w))*-?$' AS citext)
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan query_runner_state to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to query_runner_state maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — query_runner_state.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
query | text | null | |||
last_executed | timestamptz | null | |||
latest_result | timestamptz | null | |||
exec_duration_ns | bigint | null | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan redis_key_value to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to redis_key_value maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — redis_key_value.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
namespace PK | text | NOT NULL | |||
key PK | text | NOT NULL | |||
value | bytea | NOT NULL | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
role_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on roles must scan role_permissions to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to role_permissions maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often roles rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan role_permissions to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to role_permissions maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — role_permissions.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
role_id PK | integer | NOT NULL | roles.id 1:N · CASCADE | ||
permission_id PK | integer | NOT NULL | permissions.id 1:N · CASCADE | ||
created_at | timestamptz | NOT NULL | now() | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan roles to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to roles maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — roles.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
created_at | timestamptz | NOT NULL | now() | ||
system | boolean | NOT NULL | FALSE | This is used to indicate whether a role is read-only or can be modified. | |
name | citext | NOT NULL | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
created_by — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan saved_searches to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to saved_searches maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.org_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on orgs must scan saved_searches to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to saved_searches maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often orgs rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan saved_searches to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to saved_searches maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.updated_by — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan saved_searches to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to saved_searches maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.user_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan saved_searches to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to saved_searches maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.created_by — saved_searches.created_by may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.org_id — saved_searches.org_id may be NULL, so the relationship to orgs is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.tenant_id — saved_searches.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.updated_by — saved_searches.updated_by may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.user_id — saved_searches.user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.org_id, tenant_id, user_id — saved_searches has several nullable FKs (org_id, tenant_id, user_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
description | text | NOT NULL | |||
query | text | NOT NULL | |||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
notify_owner | boolean | NOT NULL | FALSE | ||
notify_slack | boolean | NOT NULL | FALSE | ||
user_id | integer | null | users.id 1:N | ||
org_id | integer | null | orgs.id 1:N | ||
slack_webhook_url | text | null | |||
created_by | integer | null | users.id 1:N · SET NULL | ||
updated_by | integer | null | users.id 1:N · SET NULL | ||
draft | boolean | NOT NULL | FALSE | ||
visibility_secret | boolean | NOT NULL | TRUE | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Table checks: notify_owner = FALSE AND notify_slack = FALSE; (user_id IS NOT NULL AND org_id IS NULL) OR (org_id IS NOT NULL AND user_id IS NULL)
Contains security-relevant events with a long time horizon for storage.
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan security_event_logs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to security_event_logs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — security_event_logs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
name | text | NOT NULL | The event name as a CAPITALIZED_SNAKE_CASE string.CHECK name <> CAST('' AS text) | ||
url | text | NOT NULL | The URL within the Sourcegraph app which generated the event. | ||
user_id | integer | NOT NULL | The ID of the actor associated with the event. | ||
anonymous_user_id | text | NOT NULL | The UUID of the actor associated with the event. | ||
source | text | NOT NULL | The site section (WEB, BACKEND, etc.) that generated the event.CHECK source <> CAST('' AS text) | ||
argument | jsonb | NOT NULL | An arbitrary JSON blob containing event data. | ||
version | text | NOT NULL | The version of Sourcegraph which generated the event.CHECK version <> CAST('' AS text) | ||
timestamp | timestamptz | NOT NULL | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Table checks: (user_id = 0 AND anonymous_user_id <> CAST('' AS text)) OR (user_id <> 0 AND anonymous_user_id = CAST('' AS text)) OR (user_id <> 0 AND anonymous_user_id <> CAST('' AS text)); name <> CAST('' AS text); source <> CAST('' AS text); version <> CAST('' AS text)
author_user_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan settings to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to settings maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan settings to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to settings maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.author_user_id — settings.author_user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.org_id — settings.org_id may be NULL, so the relationship to orgs is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.tenant_id — settings.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.user_id — settings.user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.author_user_id, org_id, tenant_id, user_id — settings has several nullable FKs (author_user_id, org_id, tenant_id, user_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
org_id | integer | null | orgs.id 1:N · RESTRICT | ||
contents | text | NOT NULL | CAST('{}' AS text) | CHECK contents <> CAST('' AS text) | |
created_at | timestamptz | NOT NULL | now() | ||
user_id | integer | null | users.id 1:N · RESTRICT | ||
author_user_id | integer | null | users.id 1:N · RESTRICT | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Table checks: contents <> CAST('' AS text)
Responsible for storing permissions at a finer granularity than repo
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan sub_repo_permissions to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to sub_repo_permissions maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — sub_repo_permissions.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
repo_id | integer | NOT NULL | repo.id 1:N · CASCADE | ||
user_id | integer | NOT NULL | users.id 1:N · CASCADE | ||
version | integer | NOT NULL | 1 | ||
updated_at | timestamptz | NOT NULL | now() | ||
paths | text[] | null | Paths that begin with a minus sign (-) are exclusion paths. | ||
ips | text[] | null | IP addresses corresponding to each path. IP in slot 0 in the array corresponds to path the in slot 0 of the path array, etc. NULL if not yet migrated, empty array for no IP restrictions. | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Table checks: ips IS NULL OR (array_length(ips, 1) = array_length(paths, 1) AND NOT CAST('' AS text) = ANY(ips))
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan survey_responses to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to survey_responses maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.user_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan survey_responses to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to survey_responses maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — survey_responses.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.user_id — survey_responses.user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.tenant_id, user_id — survey_responses has several nullable FKs (tenant_id, user_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
user_id | integer | null | users.id 1:N | ||
email | text | null | |||
score | integer | NOT NULL | |||
reason | text | null | |||
better | text | null | |||
created_at | timestamptz | NOT NULL | now() | ||
use_cases | text[] | null | |||
other_use_case | text | null | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan team_members to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to team_members maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.user_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan team_members to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to team_members maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — team_members.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
team_id PK | integer | NOT NULL | teams.id 1:N · CASCADE | ||
user_id PK | integer | NOT NULL | users.id 1:N · CASCADE | ||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
creator_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan teams to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to teams maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.parent_team_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on teams must scan teams to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to teams maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often teams rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan teams to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to teams maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.creator_id — teams.creator_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.parent_team_id — teams.parent_team_id may be NULL, so the relationship to teams is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.tenant_id — teams.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.creator_id, parent_team_id, tenant_id — teams has several nullable FKs (creator_id, parent_team_id, tenant_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
name | citext | NOT NULL | CHECK char_length(CAST(name AS text)) <= 255 | ||
display_name | text | null | CHECK char_length(display_name) <= 255 | ||
readonly | boolean | NOT NULL | FALSE | ||
parent_team_id | integer | null | teams.id 1:N · CASCADE | ||
creator_id | integer | null | users.id 1:N · SET NULL | ||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Table checks: char_length(display_name) <= 255; char_length(CAST(name AS text)) <= 255; name ~ CAST('^[a-zA-Z0-9](?:[a-zA-Z0-9]|[-.](?=[a-zA-Z0-9]))*-?$' AS citext)
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan telemetry_events_export_queue to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to telemetry_events_export_queue maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — telemetry_events_export_queue.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | text | NOT NULL | |||
timestamp | timestamptz | NOT NULL | |||
payload_pb | bytea | NOT NULL | |||
exported_at | timestamptz | null | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Stores per-user temporary settings used in the UI, for example, which modals have been dimissed or what theme is preferred.
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan temporary_settings to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to temporary_settings maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — temporary_settings.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
user_id UK | integer | NOT NULL | users.id 1:1 · CASCADE | The ID of the user the settings will be saved for. | |
contents | jsonb | null | JSON-encoded temporary settings. | ||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
The table that holds all tenants known to the instance. In enterprise instances, this table will only contain the "default" tenant.
| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | The ID of the tenant. To keep tenants globally addressable, and be able to move them aronud instances more easily, the ID is NOT a serial and has to be specified explicitly. The creator of the tenant is responsible for choosing a unique ID, if it cares. | ||
name UK | text | NOT NULL | The name of the tenant. This may be displayed to the user and must be unique.CHECK char_length(name) <= 32 AND char_length(name) >= 3 | ||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() |
Table checks: char_length(name) <= 32 AND char_length(name) >= 3; name ~ CAST('^[a-z](?:[a-z0-9\_-])*[a-z0-9]$' AS text)
versions references nothing and nothing references it. Either it is a staging/log table (fine, say so), or it is dead, or it is the seed of a second data model growing beside the first.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
service PK | text | NOT NULL | |||
version | text | NOT NULL | |||
updated_at | timestamptz | NOT NULL | now() | ||
first_version | text | NOT NULL | |||
auto_upgrade | boolean | NOT NULL | FALSE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan vulnerabilities to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to vulnerabilities maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — vulnerabilities.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
source_id | text | NOT NULL | |||
summary | text | NOT NULL | |||
details | text | NOT NULL | |||
cpes | text[] | NOT NULL | |||
cwes | text[] | NOT NULL | |||
aliases | text[] | NOT NULL | |||
related | text[] | NOT NULL | |||
data_source | text | NOT NULL | |||
urls | text[] | NOT NULL | |||
severity | text | NOT NULL | |||
cvss_vector | text | NOT NULL | |||
cvss_score | text | NOT NULL | |||
published_at | timestamptz | NOT NULL | |||
modified_at | timestamptz | null | |||
withdrawn_at | timestamptz | null | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan webhook_logs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to webhook_logs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.webhook_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on webhooks must scan webhook_logs to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to webhook_logs maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often webhooks rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.external_service_id — webhook_logs.external_service_id may be NULL, so the relationship to external_services is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.tenant_id — webhook_logs.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.webhook_id — webhook_logs.webhook_id may be NULL, so the relationship to webhooks is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.external_service_id, tenant_id, webhook_id — webhook_logs has several nullable FKs (external_service_id, tenant_id, webhook_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | bigint | NOT NULL | |||
received_at | timestamptz | NOT NULL | now() | ||
external_service_id | integer | null | external_services.id 1:N · CASCADE | ||
status_code | integer | NOT NULL | |||
request | bytea | NOT NULL | |||
response | bytea | NOT NULL | |||
encryption_key_id | text | NOT NULL | |||
webhook_id | integer | null | webhooks.id 1:N · CASCADE | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
Webhooks registered in Sourcegraph instance.
created_by_user_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan webhooks to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to webhooks maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan webhooks to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to webhooks maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.updated_by_user_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan webhooks to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to webhooks maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often users rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.created_by_user_id — webhooks.created_by_user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.tenant_id — webhooks.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.updated_by_user_id — webhooks.updated_by_user_id may be NULL, so the relationship to users is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.code_host_kind — code_host_kind is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code. The comment lists Kind of an external service for which webhooks are registered., i.e. the values are known.created_by_user_id, tenant_id, updated_by_user_id — webhooks has several nullable FKs (created_by_user_id, tenant_id, updated_by_user_id) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | integer | NOT NULL | |||
code_host_kind | text | NOT NULL | Kind of an external service for which webhooks are registered. | ||
code_host_urn | text | NOT NULL | URN of a code host. This column maps to external_service_id column of repo table. | ||
secret | text | null | Secret used to decrypt webhook payload (if supported by the code host). | ||
created_at | timestamptz | NOT NULL | now() | ||
updated_at | timestamptz | NOT NULL | now() | ||
encryption_key_id | text | null | |||
uuid UK | uuid | NOT NULL | gen_random_uuid() | ||
created_by_user_id | integer | null | users.id 1:N · SET NULL | ID of a user, who created the webhook. If NULL, then the user does not exist (never existed or was deleted). | |
updated_by_user_id | integer | null | users.id 1:N · SET NULL | ID of a user, who updated the webhook. If NULL, then the user does not exist (never existed or was deleted). | |
name | text | NOT NULL | Descriptive name of a webhook. | ||
tenant_id | integer | null | tenants.id 1:N · CASCADE |
tenant_id — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on tenants must scan zoekt_repos to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to zoekt_repos maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often tenants rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.tenant_id — zoekt_repos.tenant_id may be NULL, so the relationship to tenants is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.index_status — index_status is a short string that clearly takes a fixed set of values, but the database accepts anything. Typos become new states, and nobody can list the legal values without reading application code.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
repo_id PK | integer | NOT NULL | repo.id 1:1 · CASCADE | ||
branches | jsonb | NOT NULL | CAST('[]' AS jsonb) | ||
index_status | text | NOT NULL | CAST('not_indexed' AS text) | ||
updated_at | timestamptz | NOT NULL | now() | ||
created_at | timestamptz | NOT NULL | now() | ||
last_indexed_at | timestamptz | null | |||
tenant_id | integer | null | tenants.id 1:N · CASCADE |