Scheduling: users, teams, event types, bookings, availability, apps. DDL emitted from the Prisma schema, no database needed. Domains here are by table-name prefix, not by judgment.
121 tables · 1268 columns · 220 foreign keys · 23 domains | 5 errors · 78 warnings · 378 notes
Generated from cal.com@v6.2.0.sql on 2026-09-05.
Conventions are claims. Findings below are where the schema breaks them.
Impersonations looks like a many-to-many link table but has no unique constraint across (impersonatedById, impersonatedUserId). The same pair can be inserted twice; every join through it will double-count.
Fix Use the FK pair as the primary key (or add a UNIQUE).
ALTER TABLE Impersonations ADD PRIMARY KEY (impersonatedById, impersonatedUserId);
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 ManagedOrganization ADD PRIMARY KEY (...);
pricePerSeat is binary floating point. 0.1 + 0.2 ≠ 0.3; sums drift; reconciliation against the ledger will be off by cents.
Fix Use NUMERIC(p, s) or integer minor units.
ALTER TABLE OrganizationOnboarding ALTER COLUMN pricePerSeat TYPE numeric(14,2);
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 UserPassword 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 avatars ADD PRIMARY KEY (...);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on OAuthClient must scan AccessCode to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to AccessCode maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often OAuthClient 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. clientId 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_AccessCode_clientId ON AccessCode(clientId) WHERE clientId IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan AccessCode to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to AccessCode 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. userId 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_AccessCode_userId ON AccessCode(userId) WHERE userId IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on Team must scan AccessCode to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to AccessCode maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often Team 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. teamId 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_AccessCode_teamId ON AccessCode(teamId) WHERE teamId IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan AccessToken to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to AccessToken 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_AccessToken_userId ON AccessToken(userId);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on PlatformOAuthClient must scan AccessToken to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to AccessToken maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often PlatformOAuthClient 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_AccessToken_platformOAuthClientId ON AccessToken(platformOAuthClientId);
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 Account ADD CONSTRAINT Account_type_check CHECK (type IN (...));
token_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 Account ADD CONSTRAINT Account_token_type_check CHECK (token_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 Account ADD CONSTRAINT Account_scope_check CHECK (scope IN (...));
session_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 Account ADD CONSTRAINT Account_session_state_check CHECK (session_state IN (...));
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on Team must scan ApiKey to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to ApiKey maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often Team 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. teamId 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_ApiKey_teamId ON ApiKey(teamId) WHERE teamId IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on App must scan ApiKey to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to ApiKey maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often App 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. appId 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_ApiKey_appId ON ApiKey(appId) WHERE appId IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan App_RoutingForms_Form to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to App_RoutingForms_Form 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. updatedById 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_App_RoutingForms_Form_updatedById ON App_RoutingForms_Form(updatedById) WHERE updatedById IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on Team must scan App_RoutingForms_Form to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to App_RoutingForms_Form maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often Team 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. teamId 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_App_RoutingForms_Form_teamId ON App_RoutingForms_Form(teamId) WHERE teamId IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on App_RoutingForms_Form must scan App_RoutingForms_IncompleteBookingActions to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to App_RoutingForms_IncompleteBookingActions maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often App_RoutingForms_Form 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_App_RoutingForms_IncompleteBookingActions_formId ON App_RoutingForms_IncompleteBookingActions(formId);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on App_RoutingForms_Form must scan App_RoutingForms_QueuedFormResponse to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to App_RoutingForms_QueuedFormResponse maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often App_RoutingForms_Form 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_App_RoutingForms_QueuedFormResponse_formId ON App_RoutingForms_QueuedFormResponse(formId);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on Attribute must scan AttributeOption to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to AttributeOption maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often Attribute 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_AttributeOption_attributeId ON AttributeOption(attributeId);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on Attribute must scan AttributeSyncFieldMapping to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to AttributeSyncFieldMapping maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often Attribute 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_AttributeSyncFieldMapping_attributeId ON AttributeSyncFieldMapping(attributeId);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on AttributeOption must scan AttributeToUser to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to AttributeToUser maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often AttributeOption 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_AttributeToUser_attributeOptionId ON AttributeToUser(attributeOptionId);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan AttributeToUser to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to AttributeToUser 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. createdById 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_AttributeToUser_createdById ON AttributeToUser(createdById) WHERE createdById IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on DSyncData must scan AttributeToUser to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to AttributeToUser maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often DSyncData 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. createdByDSyncId 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_AttributeToUser_createdByDSyncId ON AttributeToUser(createdByDSyncId) WHERE createdByDSyncId IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan AttributeToUser to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to AttributeToUser 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. updatedById 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_AttributeToUser_updatedById ON AttributeToUser(updatedById) WHERE updatedById IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on DSyncData must scan AttributeToUser to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to AttributeToUser maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often DSyncData 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. updatedByDSyncId 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_AttributeToUser_updatedByDSyncId ON AttributeToUser(updatedByDSyncId) WHERE updatedByDSyncId IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan Booking to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to Booking 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. reassignById 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_Booking_reassignById ON Booking(reassignById) WHERE reassignById IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on InternalNotePreset must scan BookingInternalNote to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to BookingInternalNote maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often InternalNotePreset 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. notePresetId 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_BookingInternalNote_notePresetId ON BookingInternalNote(notePresetId) WHERE notePresetId IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan BookingInternalNote to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to BookingInternalNote 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_BookingInternalNote_createdById ON BookingInternalNote(createdById);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on Credential must scan BookingReference to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to BookingReference maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often Credential 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. credentialId 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_BookingReference_credentialId ON BookingReference(credentialId) WHERE credentialId IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on DelegationCredential must scan BookingReference to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to BookingReference maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often DelegationCredential 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. delegationCredentialId 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_BookingReference_delegationCredentialId ON BookingReference(delegationCredentialId) WHERE delegationCredentialId IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on DomainWideDelegation must scan BookingReference to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to BookingReference maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often DomainWideDelegation 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. domainWideDelegationCredentialId 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_BookingReference_domainWideDelegationCredentialId ON BookingReference(domainWideDelegationCredentialId) WHERE domainWideDelegationCredentialId 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 BookingReference ADD CONSTRAINT BookingReference_type_check CHECK (type IN (...));
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on DelegationCredential must scan Credential to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to Credential maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often DelegationCredential 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. delegationCredentialId 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_Credential_delegationCredentialId ON Credential(delegationCredentialId) WHERE delegationCredentialId 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 Credential ADD CONSTRAINT Credential_type_check CHECK (type IN (...));
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on CreditBalance must scan CreditExpenseLog to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to CreditExpenseLog maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often CreditBalance 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_CreditExpenseLog_creditBalanceId ON CreditExpenseLog(creditBalanceId);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on Booking must scan CreditExpenseLog to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to CreditExpenseLog maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often Booking 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. bookingUid 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_CreditExpenseLog_bookingUid ON CreditExpenseLog(bookingUid) WHERE bookingUid IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on CreditBalance must scan CreditPurchaseLog to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to CreditPurchaseLog maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often CreditBalance 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_CreditPurchaseLog_creditBalanceId ON CreditPurchaseLog(creditBalanceId);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on DSyncData must scan DSyncTeamGroupMapping to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to DSyncTeamGroupMapping maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often DSyncData 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_DSyncTeamGroupMapping_directoryId ON DSyncTeamGroupMapping(directoryId);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on WorkspacePlatform must scan DelegationCredential to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to DelegationCredential maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often WorkspacePlatform 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_DelegationCredential_workspacePlatformId ON DelegationCredential(workspacePlatformId);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on DelegationCredential must scan DestinationCalendar to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to DestinationCalendar maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often DelegationCredential 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. delegationCredentialId 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_DestinationCalendar_delegationCredentialId ON DestinationCalendar(delegationCredentialId) WHERE delegationCredentialId IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on DomainWideDelegation must scan DestinationCalendar to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to DestinationCalendar maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often DomainWideDelegation 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. domainWideDelegationCredentialId 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_DestinationCalendar_domainWideDelegationCredentialId ON DestinationCalendar(domainWideDelegationCredentialId) WHERE domainWideDelegationCredentialId IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on WorkspacePlatform must scan DomainWideDelegation to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to DomainWideDelegation maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often WorkspacePlatform 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_DomainWideDelegation_workspacePlatformId ON DomainWideDelegation(workspacePlatformId);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on Schedule must scan EventType to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to EventType maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often Schedule 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. instantMeetingScheduleId 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_EventType_instantMeetingScheduleId ON EventType(instantMeetingScheduleId) WHERE instantMeetingScheduleId IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan EventTypeTranslation to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to EventTypeTranslation 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_EventTypeTranslation_createdBy ON EventTypeTranslation(createdBy);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan EventTypeTranslation to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to EventTypeTranslation 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. updatedBy 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_EventTypeTranslation_updatedBy ON EventTypeTranslation(updatedBy) WHERE updatedBy IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan FilterSegment to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to FilterSegment 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_FilterSegment_userId ON FilterSegment(userId);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on Team must scan FilterSegment to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to FilterSegment maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often Team 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. teamId 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_FilterSegment_teamId ON FilterSegment(teamId) WHERE teamId IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on HostGroup must scan Host to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to Host maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often HostGroup 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. groupId 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_Host_groupId ON Host(groupId) WHERE groupId 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 HostLocation ADD CONSTRAINT HostLocation_type_check CHECK (type IN (...));
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on Team must scan InstantMeetingToken to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to InstantMeetingToken maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often Team 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_InstantMeetingToken_teamId ON InstantMeetingToken(teamId);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on TeamBilling must scan MonthlyProration to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to MonthlyProration maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often TeamBilling 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. teamBillingId 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_MonthlyProration_teamBillingId ON MonthlyProration(teamBillingId) WHERE teamBillingId IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on OrganizationBilling must scan MonthlyProration to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to MonthlyProration maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often OrganizationBilling 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. organizationBillingId 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_MonthlyProration_organizationBillingId ON MonthlyProration(organizationBillingId) WHERE organizationBillingId 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 OrganizationBilling ADD CONSTRAINT OrganizationBilling_status_check CHECK (status IN (...));
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan OrganizationOnboarding to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to OrganizationOnboarding 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_OrganizationOnboarding_createdById ON OrganizationOnboarding(createdById);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on OutOfOfficeReason must scan OutOfOfficeEntry to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to OutOfOfficeEntry maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often OutOfOfficeReason 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. reasonId 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_OutOfOfficeEntry_reasonId ON OutOfOfficeEntry(reasonId) WHERE reasonId IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan OutOfOfficeReason to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to OutOfOfficeReason 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. userId 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_OutOfOfficeReason_userId ON OutOfOfficeReason(userId) WHERE userId IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on App must scan Payment to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to Payment maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often App 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. appId 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_Payment_appId ON Payment(appId) WHERE appId IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on PlatformOAuthClient must scan PlatformAuthorizationToken to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to PlatformAuthorizationToken maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often PlatformOAuthClient 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_PlatformAuthorizationToken_platformOAuthClientId ON PlatformAuthorizationToken(platformOAuthClientId);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on PlatformBilling must scan PlatformBilling to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to PlatformBilling maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often PlatformBilling 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. managerBillingId 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_PlatformBilling_managerBillingId ON PlatformBilling(managerBillingId) WHERE managerBillingId IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on Team must scan PlatformOAuthClient to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to PlatformOAuthClient maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often Team 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_PlatformOAuthClient_organizationId ON PlatformOAuthClient(organizationId);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan RefreshToken to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to RefreshToken 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_RefreshToken_userId ON RefreshToken(userId);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on PlatformOAuthClient must scan RefreshToken to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to RefreshToken maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often PlatformOAuthClient 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_RefreshToken_platformOAuthClientId ON RefreshToken(platformOAuthClientId);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on MonthlyProration must scan SeatChangeLog to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to SeatChangeLog maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often MonthlyProration 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. processedInProrationId 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_SeatChangeLog_processedInProrationId ON SeatChangeLog(processedInProrationId) WHERE processedInProrationId IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on TeamBilling must scan SeatChangeLog to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to SeatChangeLog maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often TeamBilling 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. teamBillingId 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_SeatChangeLog_teamBillingId ON SeatChangeLog(teamBillingId) WHERE teamBillingId IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on OrganizationBilling must scan SeatChangeLog to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to SeatChangeLog maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often OrganizationBilling 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. organizationBillingId 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_SeatChangeLog_organizationBillingId ON SeatChangeLog(organizationBillingId) WHERE organizationBillingId IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on DelegationCredential must scan SelectedCalendar to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to SelectedCalendar maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often DelegationCredential 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. delegationCredentialId 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_SelectedCalendar_delegationCredentialId ON SelectedCalendar(delegationCredentialId) WHERE delegationCredentialId IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on DomainWideDelegation must scan SelectedCalendar to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to SelectedCalendar maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often DomainWideDelegation 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. domainWideDelegationCredentialId 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_SelectedCalendar_domainWideDelegationCredentialId ON SelectedCalendar(domainWideDelegationCredentialId) WHERE domainWideDelegationCredentialId 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 Task ADD CONSTRAINT Task_type_check CHECK (type IN (...));
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on PlatformOAuthClient must scan Team to check the constraint, and every join from the parent side is a sequential scan. 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 maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often PlatformOAuthClient 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. createdByOAuthClientId 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_createdByOAuthClientId ON Team(createdByOAuthClientId) WHERE createdByOAuthClientId IS NOT NULL;
Team → PlatformOAuthClient → Team. 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.
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 TeamBilling ADD CONSTRAINT TeamBilling_status_check CHECK (status IN (...));
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on Feature must scan TeamFeatures to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to TeamFeatures maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often Feature 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_TeamFeatures_featureId ON TeamFeatures(featureId);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan TravelSchedule to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to TravelSchedule 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_TravelSchedule_userId ON TravelSchedule(userId);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on Feature must scan UserFeatures to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to UserFeatures maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often Feature 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_UserFeatures_featureId ON UserFeatures(featureId);
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on Team must scan Webhook to check the constraint, and every join from the parent side is a sequential scan. 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 maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often Team 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. teamId 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_teamId ON Webhook(teamId) WHERE teamId IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on EventType must scan Webhook to check the constraint, and every join from the parent side is a sequential scan. 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 maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often EventType 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. eventTypeId 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_eventTypeId ON Webhook(eventTypeId) WHERE eventTypeId IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on App must scan Webhook to check the constraint, and every join from the parent side is a sequential scan. 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 maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often App 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. appId 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_appId ON Webhook(appId) WHERE appId IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on Webhook must scan WebhookScheduledTriggers to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to WebhookScheduledTriggers maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often Webhook 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. webhookId 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_WebhookScheduledTriggers_webhookId ON WebhookScheduledTriggers(webhookId) WHERE webhookId IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on Booking must scan WebhookScheduledTriggers to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to WebhookScheduledTriggers maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often Booking 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. bookingId 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_WebhookScheduledTriggers_bookingId ON WebhookScheduledTriggers(bookingId) WHERE bookingId IS NOT NULL;
PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on Team 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 Team 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. organizationId 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_organizationId ON users(organizationId) WHERE organizationId IS NOT NULL;
users → Profile → users. 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.
AccessCode.clientId may be NULL, so the relationship to OAuthClient is optional. That is legitimate (e.g. 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.
AccessCode.userId 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.
AccessCode.teamId may be NULL, so the relationship to Team is optional. That is legitimate (e.g. 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.
AccessCode has several nullable FKs (clientId, userId, teamId) 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 AccessCode ADD CONSTRAINT AccessCode_one_target CHECK ((clientId IS NOT NULL)::int + (userId IS NOT NULL)::int + (teamId IS NOT NULL)::int = 1);
expiresAt 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 AccessCode ALTER COLUMN expiresAt TYPE timestamptz;
createdAt 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 AccessToken ALTER COLUMN createdAt TYPE timestamptz;
expiresAt 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 AccessToken ALTER COLUMN expiresAt TYPE timestamptz;
Agent.userId 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.
Agent.teamId may be NULL, so the relationship to Team is optional. That is legitimate (e.g. 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.
Agent has several nullable FKs (userId, teamId) 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 Agent ADD CONSTRAINT Agent_one_target CHECK ((userId IS NOT NULL)::int + (teamId IS NOT NULL)::int = 1);
createdAt 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 Agent ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 Agent ALTER COLUMN updatedAt TYPE timestamptz;
ApiKey.teamId may be NULL, so the relationship to Team is optional. That is legitimate (e.g. 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.
ApiKey.appId may be NULL, so the relationship to App is optional. That is legitimate (e.g. 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.
ApiKey has several nullable FKs (teamId, appId) 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 ApiKey ADD CONSTRAINT ApiKey_one_target CHECK ((teamId IS NOT NULL)::int + (appId IS NOT NULL)::int = 1);
createdAt 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 ApiKey ALTER COLUMN createdAt TYPE timestamptz;
expiresAt 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 ApiKey ALTER COLUMN expiresAt TYPE timestamptz;
lastUsedAt 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 ApiKey ALTER COLUMN lastUsedAt TYPE timestamptz;
createdAt 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 App ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 App ALTER COLUMN updatedAt TYPE timestamptz;
App_RoutingForms_Form.updatedById 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.
App_RoutingForms_Form.teamId may be NULL, so the relationship to Team is optional. That is legitimate (e.g. 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.
App_RoutingForms_Form has several nullable FKs (updatedById, teamId) 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 App_RoutingForms_Form ADD CONSTRAINT App_RoutingForms_Form_one_target CHECK ((updatedById IS NOT NULL)::int + (teamId IS NOT NULL)::int = 1);
createdAt 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 App_RoutingForms_Form ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 App_RoutingForms_Form ALTER COLUMN updatedAt TYPE timestamptz;
App_RoutingForms_FormResponse.routedToBookingUid may be NULL, so the relationship to Booking is optional. That is legitimate (e.g. 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.
createdAt 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 App_RoutingForms_FormResponse ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 App_RoutingForms_FormResponse ALTER COLUMN updatedAt TYPE timestamptz;
App_RoutingForms_QueuedFormResponse.actualResponseId may be NULL, so the relationship to App_RoutingForms_FormResponse is optional. That is legitimate (e.g. 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.
createdAt 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 App_RoutingForms_QueuedFormResponse ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 App_RoutingForms_QueuedFormResponse ALTER COLUMN updatedAt TYPE timestamptz;
createdAt 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 AssignmentReason ALTER COLUMN createdAt TYPE timestamptz;
Attendee.bookingId may be NULL, so the relationship to Booking is optional. That is legitimate (e.g. 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.
createdAt 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 Attribute ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 Attribute ALTER COLUMN updatedAt TYPE timestamptz;
createdAt 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 AttributeSyncFieldMapping ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 AttributeSyncFieldMapping ALTER COLUMN updatedAt TYPE timestamptz;
createdAt 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 AttributeSyncRule ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 AttributeSyncRule ALTER COLUMN updatedAt TYPE timestamptz;
AttributeToUser.createdById 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.
AttributeToUser.createdByDSyncId may be NULL, so the relationship to DSyncData is optional. That is legitimate (e.g. 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.
AttributeToUser.updatedById 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.
AttributeToUser.updatedByDSyncId may be NULL, so the relationship to DSyncData is optional. That is legitimate (e.g. 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.
AttributeToUser has several nullable FKs (createdById, createdByDSyncId, updatedById, updatedByDSyncId) 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 AttributeToUser ADD CONSTRAINT AttributeToUser_one_target CHECK ((createdById IS NOT NULL)::int + (createdByDSyncId IS NOT NULL)::int + (updatedById IS NOT NULL)::int + (updatedByDSyncId IS NOT NULL)::int = 1);
createdAt 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 AttributeToUser ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 AttributeToUser ALTER COLUMN updatedAt TYPE timestamptz;
createdAt 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 AuditActor ALTER COLUMN createdAt TYPE timestamptz;
Availability.userId 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.
Availability.eventTypeId may be NULL, so the relationship to EventType is optional. That is legitimate (e.g. 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.
Availability.scheduleId may be NULL, so the relationship to Schedule is optional. That is legitimate (e.g. 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.
Availability has several nullable FKs (userId, eventTypeId, scheduleId) 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 Availability ADD CONSTRAINT Availability_one_target CHECK ((userId IS NOT NULL)::int + (eventTypeId IS NOT NULL)::int + (scheduleId IS NOT NULL)::int = 1);
Booking.userId 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.
Booking.eventTypeId may be NULL, so the relationship to EventType is optional. That is legitimate (e.g. 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.
Booking.destinationCalendarId may be NULL, so the relationship to DestinationCalendar is optional. That is legitimate (e.g. 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.
Booking.reassignById 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.
Booking has several nullable FKs (userId, eventTypeId, destinationCalendarId, reassignById) 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 Booking ADD CONSTRAINT Booking_one_target CHECK ((userId IS NOT NULL)::int + (eventTypeId IS NOT NULL)::int + (destinationCalendarId IS NOT NULL)::int + (reassignById IS NOT NULL)::int = 1);
startTime 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 Booking ALTER COLUMN startTime TYPE timestamptz;
endTime 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 Booking ALTER COLUMN endTime TYPE timestamptz;
createdAt 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 Booking ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 Booking ALTER COLUMN updatedAt TYPE timestamptz;
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.
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.
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 BookingAudit ALTER COLUMN timestamp TYPE timestamptz;
createdAt 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 BookingAudit ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 BookingAudit ALTER COLUMN updatedAt TYPE timestamptz;
startTime 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 BookingDenormalized ALTER COLUMN startTime TYPE timestamptz;
endTime 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 BookingDenormalized ALTER COLUMN endTime TYPE timestamptz;
createdAt 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 BookingDenormalized ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 BookingDenormalized ALTER COLUMN updatedAt TYPE timestamptz;
BookingDenormalized 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.
BookingInternalNote.notePresetId may be NULL, so the relationship to InternalNotePreset is optional. That is legitimate (e.g. 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.
createdAt 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 BookingInternalNote ALTER COLUMN createdAt TYPE timestamptz;
BookingReference.bookingId may be NULL, so the relationship to Booking is optional. That is legitimate (e.g. 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.
BookingReference.credentialId may be NULL, so the relationship to Credential is optional. That is legitimate (e.g. 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.
BookingReference.delegationCredentialId may be NULL, so the relationship to DelegationCredential is optional. That is legitimate (e.g. 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.
BookingReference.domainWideDelegationCredentialId may be NULL, so the relationship to DomainWideDelegation is optional. That is legitimate (e.g. 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.
bookingId, credentialId, delegationCredentialId, domainWideDelegationCredentialIdexclusive-arcBookingReference has several nullable FKs (bookingId, credentialId, delegationCredentialId, domainWideDelegationCredentialId) 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 BookingReference ADD CONSTRAINT BookingReference_one_target CHECK ((bookingId IS NOT NULL)::int + (credentialId IS NOT NULL)::int + (delegationCredentialId IS NOT NULL)::int + (domainWideDelegationCredentialId IS NOT NULL)::int = 1);
BookingReport.reportedById 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.
BookingReport.organizationId may be NULL, so the relationship to Team is optional. That is legitimate (e.g. 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.
BookingReport.watchlistId may be NULL, so the relationship to Watchlist is optional. That is legitimate (e.g. 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.
BookingReport.globalWatchlistId may be NULL, so the relationship to Watchlist is optional. That is legitimate (e.g. 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.
BookingReport has several nullable FKs (reportedById, organizationId, watchlistId, globalWatchlistId) 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 BookingReport ADD CONSTRAINT BookingReport_one_target CHECK ((reportedById IS NOT NULL)::int + (organizationId IS NOT NULL)::int + (watchlistId IS NOT NULL)::int + (globalWatchlistId IS NOT NULL)::int = 1);
createdAt 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 BookingReport ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 BookingReport ALTER COLUMN updatedAt TYPE timestamptz;
CalAiPhoneNumber.userId 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.
CalAiPhoneNumber.teamId may be NULL, so the relationship to Team is optional. That is legitimate (e.g. 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.
CalAiPhoneNumber.inboundAgentId may be NULL, so the relationship to Agent is optional. That is legitimate (e.g. 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.
CalAiPhoneNumber.outboundAgentId may be NULL, so the relationship to Agent is optional. That is legitimate (e.g. 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.
CalAiPhoneNumber has several nullable FKs (userId, teamId, inboundAgentId, outboundAgentId) 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 CalAiPhoneNumber ADD CONSTRAINT CalAiPhoneNumber_one_target CHECK ((userId IS NOT NULL)::int + (teamId IS NOT NULL)::int + (inboundAgentId IS NOT NULL)::int + (outboundAgentId IS NOT NULL)::int = 1);
createdAt 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 CalAiPhoneNumber ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 CalAiPhoneNumber ALTER COLUMN updatedAt TYPE timestamptz;
createdAt 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 CalVideoSettings ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 CalVideoSettings ALTER COLUMN updatedAt TYPE timestamptz;
expiresAt 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 CalendarCache ALTER COLUMN expiresAt TYPE timestamptz;
updatedAt 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 CalendarCache ALTER COLUMN updatedAt TYPE timestamptz;
start 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 CalendarCacheEvent ALTER COLUMN start TYPE timestamptz;
end 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 CalendarCacheEvent ALTER COLUMN end TYPE timestamptz;
originalStartTime 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 CalendarCacheEvent ALTER COLUMN originalStartTime TYPE timestamptz;
createdAt 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 CalendarCacheEvent ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 CalendarCacheEvent ALTER COLUMN updatedAt TYPE timestamptz;
externalCreatedAt 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 CalendarCacheEvent ALTER COLUMN externalCreatedAt TYPE timestamptz;
externalUpdatedAt 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 CalendarCacheEvent ALTER COLUMN externalUpdatedAt TYPE timestamptz;
Credential.userId 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.
Credential.teamId may be NULL, so the relationship to Team is optional. That is legitimate (e.g. 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.
Credential.appId may be NULL, so the relationship to App is optional. That is legitimate (e.g. 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.
Credential.delegationCredentialId may be NULL, so the relationship to DelegationCredential is optional. That is legitimate (e.g. 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.
Credential has several nullable FKs (userId, teamId, appId, delegationCredentialId) 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 Credential ADD CONSTRAINT Credential_one_target CHECK ((userId IS NOT NULL)::int + (teamId IS NOT NULL)::int + (appId IS NOT NULL)::int + (delegationCredentialId IS NOT NULL)::int = 1);
CreditBalance.teamId may be NULL, so the relationship to Team is optional. That is legitimate (e.g. 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.
CreditBalance.userId 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.
CreditBalance has several nullable FKs (teamId, userId) 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 CreditBalance ADD CONSTRAINT CreditBalance_one_target CHECK ((teamId IS NOT NULL)::int + (userId IS NOT NULL)::int = 1);
limitReachedAt 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 CreditBalance ALTER COLUMN limitReachedAt TYPE timestamptz;
warningSentAt 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 CreditBalance ALTER COLUMN warningSentAt TYPE timestamptz;
CreditExpenseLog.bookingUid may be NULL, so the relationship to Booking is optional. That is legitimate (e.g. 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.
date 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 CreditExpenseLog ALTER COLUMN date TYPE timestamptz;
createdAt 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 CreditPurchaseLog ALTER COLUMN createdAt TYPE timestamptz;
DSyncData.organizationId may be NULL, so the relationship to OrganizationSettings is optional. That is legitimate (e.g. 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.
lastEnabledAt 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 DelegationCredential ALTER COLUMN lastEnabledAt TYPE timestamptz;
lastDisabledAt 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 DelegationCredential ALTER COLUMN lastDisabledAt TYPE timestamptz;
createdAt 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 DelegationCredential ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 DelegationCredential ALTER COLUMN updatedAt TYPE timestamptz;
agreedLicenseAt 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 Deployment ALTER COLUMN agreedLicenseAt TYPE timestamptz;
Deployment 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.
DestinationCalendar.userId 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.
DestinationCalendar.eventTypeId may be NULL, so the relationship to EventType is optional. That is legitimate (e.g. 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.
DestinationCalendar.credentialId may be NULL, so the relationship to Credential is optional. That is legitimate (e.g. 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.
DestinationCalendar.delegationCredentialId may be NULL, so the relationship to DelegationCredential is optional. That is legitimate (e.g. 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.
DestinationCalendar.domainWideDelegationCredentialId may be NULL, so the relationship to DomainWideDelegation is optional. That is legitimate (e.g. 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.
userId, eventTypeId, credentialId, delegationCredentialId, domainWideDelegationCredentialIdexclusive-arcDestinationCalendar has several nullable FKs (userId, eventTypeId, credentialId, delegationCredentialId, domainWideDelegationCredentialId) 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 DestinationCalendar ADD CONSTRAINT DestinationCalendar_one_target CHECK ((userId IS NOT NULL)::int + (eventTypeId IS NOT NULL)::int + (credentialId IS NOT NULL)::int + (delegationCredentialId IS NOT NULL)::int + (domainWideDelegationCredentialId IS NOT NULL)::int = 1);
createdAt 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 DestinationCalendar ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 DestinationCalendar ALTER COLUMN updatedAt TYPE timestamptz;
createdAt 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 DomainWideDelegation ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 DomainWideDelegation ALTER COLUMN updatedAt TYPE timestamptz;
EventType.userId 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.
EventType.profileId may be NULL, so the relationship to Profile is optional. That is legitimate (e.g. 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.
EventType.teamId may be NULL, so the relationship to Team is optional. That is legitimate (e.g. 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.
EventType.parentId may be NULL, so the relationship to EventType is optional. That is legitimate (e.g. 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.
EventType.scheduleId may be NULL, so the relationship to Schedule is optional. That is legitimate (e.g. 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.
EventType.instantMeetingScheduleId may be NULL, so the relationship to Schedule is optional. That is legitimate (e.g. 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.
EventType.secondaryEmailId may be NULL, so the relationship to SecondaryEmail is optional. That is legitimate (e.g. 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.
EventType.restrictionScheduleId may be NULL, so the relationship to Schedule is optional. That is legitimate (e.g. 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.
userId, profileId, teamId, parentId, scheduleId, instantMeetingScheduleId, secondaryEmailId, restrictionScheduleIdexclusive-arcEventType has several nullable FKs (userId, profileId, teamId, parentId, scheduleId, instantMeetingScheduleId, secondaryEmailId, restrictionScheduleId) 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 EventType ADD CONSTRAINT EventType_one_target CHECK ((userId IS NOT NULL)::int + (profileId IS NOT NULL)::int + (teamId IS NOT NULL)::int + (parentId IS NOT NULL)::int + (scheduleId IS NOT NULL)::int + (instantMeetingScheduleId IS NOT NULL)::int + (secondaryEmailId IS NOT NULL)::int + (restrictionScheduleId IS NOT NULL)::int = 1);
periodStartDate 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 EventType ALTER COLUMN periodStartDate TYPE timestamptz;
periodEndDate 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 EventType ALTER COLUMN periodEndDate TYPE timestamptz;
createdAt 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 EventType ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 EventType ALTER COLUMN updatedAt TYPE timestamptz;
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.
EventTypeTranslation.updatedBy 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.
createdAt 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 EventTypeTranslation ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 EventTypeTranslation ALTER COLUMN updatedAt TYPE timestamptz;
lastUsedAt 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 Feature ALTER COLUMN lastUsedAt TYPE timestamptz;
createdAt 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 Feature ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 Feature ALTER COLUMN updatedAt TYPE timestamptz;
date 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 Feedback ALTER COLUMN date TYPE timestamptz;
FilterSegment.teamId may be NULL, so the relationship to Team is optional. That is legitimate (e.g. 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.
createdAt 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 FilterSegment ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 FilterSegment ALTER COLUMN updatedAt TYPE timestamptz;
expiresAt 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 HashedLink ALTER COLUMN expiresAt TYPE timestamptz;
date 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 HolidayCache ALTER COLUMN date TYPE timestamptz;
createdAt 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 HolidayCache ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 HolidayCache ALTER COLUMN updatedAt TYPE timestamptz;
HolidayCache 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.
Host.scheduleId may be NULL, so the relationship to Schedule is optional. That is legitimate (e.g. 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.
Host.groupId may be NULL, so the relationship to HostGroup is optional. That is legitimate (e.g. 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.
Host.memberId may be NULL, so the relationship to Membership is optional. That is legitimate (e.g. 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.
Host has several nullable FKs (scheduleId, groupId, memberId) 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 Host ADD CONSTRAINT Host_one_target CHECK ((scheduleId IS NOT NULL)::int + (groupId IS NOT NULL)::int + (memberId IS NOT NULL)::int = 1);
createdAt 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 Host ALTER COLUMN createdAt TYPE timestamptz;
HostGroup.eventTypeId may be NULL, so the relationship to EventType is optional. That is legitimate (e.g. 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.
createdAt 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 HostGroup ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 HostGroup ALTER COLUMN updatedAt TYPE timestamptz;
HostLocation.credentialId may be NULL, so the relationship to Credential is optional. That is legitimate (e.g. 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.
createdAt 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 HostLocation ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 HostLocation ALTER COLUMN updatedAt TYPE timestamptz;
createdAt 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 Impersonations ALTER COLUMN createdAt TYPE timestamptz;
InstantMeetingToken.bookingId may be NULL, so the relationship to Booking is optional. That is legitimate (e.g. 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.
expires 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 InstantMeetingToken ALTER COLUMN expires TYPE timestamptz;
createdAt 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 InstantMeetingToken ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 InstantMeetingToken ALTER COLUMN updatedAt TYPE timestamptz;
IntegrationAttributeSync.credentialId may be NULL, so the relationship to Credential is optional. That is legitimate (e.g. 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.
createdAt 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 IntegrationAttributeSync ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 IntegrationAttributeSync ALTER COLUMN updatedAt TYPE timestamptz;
createdAt 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 InternalNotePreset ALTER COLUMN createdAt TYPE timestamptz;
createdAt 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 ManagedOrganization ALTER COLUMN createdAt TYPE timestamptz;
Membership.customRoleId may be NULL, so the relationship to Role is optional. That is legitimate (e.g. 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.
createdAt 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 Membership ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 Membership ALTER COLUMN updatedAt TYPE timestamptz;
MonthlyProration.teamBillingId may be NULL, so the relationship to TeamBilling is optional. That is legitimate (e.g. 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.
MonthlyProration.organizationBillingId may be NULL, so the relationship to OrganizationBilling is optional. That is legitimate (e.g. 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.
MonthlyProration has several nullable FKs (teamBillingId, organizationBillingId) 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 MonthlyProration ADD CONSTRAINT MonthlyProration_one_target CHECK ((teamBillingId IS NOT NULL)::int + (organizationBillingId IS NOT NULL)::int = 1);
periodStart 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 MonthlyProration ALTER COLUMN periodStart TYPE timestamptz;
periodEnd 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 MonthlyProration ALTER COLUMN periodEnd TYPE timestamptz;
subscriptionStart 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 MonthlyProration ALTER COLUMN subscriptionStart TYPE timestamptz;
subscriptionEnd 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 MonthlyProration ALTER COLUMN subscriptionEnd TYPE timestamptz;
chargedAt 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 MonthlyProration ALTER COLUMN chargedAt TYPE timestamptz;
failedAt 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 MonthlyProration ALTER COLUMN failedAt TYPE timestamptz;
createdAt 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 MonthlyProration ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 MonthlyProration ALTER COLUMN updatedAt TYPE timestamptz;
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.
OAuthClient.userId 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.
createdAt 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 OAuthClient ALTER COLUMN createdAt TYPE timestamptz;
subscriptionStart 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 OrganizationBilling ALTER COLUMN subscriptionStart TYPE timestamptz;
subscriptionTrialEnd 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 OrganizationBilling ALTER COLUMN subscriptionTrialEnd TYPE timestamptz;
subscriptionEnd 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 OrganizationBilling ALTER COLUMN subscriptionEnd TYPE timestamptz;
highWaterMarkPeriodStart 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 OrganizationBilling ALTER COLUMN highWaterMarkPeriodStart TYPE timestamptz;
createdAt 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 OrganizationBilling ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 OrganizationBilling ALTER COLUMN updatedAt TYPE timestamptz;
OrganizationOnboarding.organizationId may be NULL, so the relationship to Team is optional. That is legitimate (e.g. 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.
createdAt 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 OrganizationOnboarding ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 OrganizationOnboarding ALTER COLUMN updatedAt TYPE timestamptz;
OutOfOfficeEntry.toUserId 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.
OutOfOfficeEntry.reasonId may be NULL, so the relationship to OutOfOfficeReason is optional. That is legitimate (e.g. 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.
OutOfOfficeEntry has several nullable FKs (toUserId, reasonId) 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 OutOfOfficeEntry ADD CONSTRAINT OutOfOfficeEntry_one_target CHECK ((toUserId IS NOT NULL)::int + (reasonId IS NOT NULL)::int = 1);
start 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 OutOfOfficeEntry ALTER COLUMN start TYPE timestamptz;
end 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 OutOfOfficeEntry ALTER COLUMN end TYPE timestamptz;
createdAt 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 OutOfOfficeEntry ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 OutOfOfficeEntry ALTER COLUMN updatedAt TYPE timestamptz;
OutOfOfficeReason.userId 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.
Payment.appId may be NULL, so the relationship to App is optional. That is legitimate (e.g. 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.
PendingRoutingTrace.formResponseId may be NULL, so the relationship to App_RoutingForms_FormResponse is optional. That is legitimate (e.g. 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.
PendingRoutingTrace.queuedFormResponseId may be NULL, so the relationship to App_RoutingForms_QueuedFormResponse is optional. That is legitimate (e.g. 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.
PendingRoutingTrace has several nullable FKs (formResponseId, queuedFormResponseId) 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 PendingRoutingTrace ADD CONSTRAINT PendingRoutingTrace_one_target CHECK ((formResponseId IS NOT NULL)::int + (queuedFormResponseId IS NOT NULL)::int = 1);
createdAt 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 PendingRoutingTrace ALTER COLUMN createdAt TYPE timestamptz;
createdAt 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 PlatformAuthorizationToken ALTER COLUMN createdAt TYPE timestamptz;
PlatformBilling.managerBillingId may be NULL, so the relationship to PlatformBilling is optional. That is legitimate (e.g. 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.
createdAt 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 PlatformOAuthClient ALTER COLUMN createdAt TYPE timestamptz;
createdAt 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 Profile ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 Profile ALTER COLUMN updatedAt TYPE timestamptz;
createdAt 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 RateLimit ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 RateLimit ALTER COLUMN updatedAt TYPE timestamptz;
createdAt 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 RefreshToken ALTER COLUMN createdAt TYPE timestamptz;
expiresAt 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 RefreshToken ALTER COLUMN expiresAt TYPE timestamptz;
createdAt 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 ReminderMail ALTER COLUMN createdAt TYPE timestamptz;
ReminderMail 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.
createdAt 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 ResetPasswordRequest ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 ResetPasswordRequest ALTER COLUMN updatedAt TYPE timestamptz;
expires 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 ResetPasswordRequest ALTER COLUMN expires TYPE timestamptz;
ResetPasswordRequest 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.
Role.teamId may be NULL, so the relationship to Team is optional. That is legitimate (e.g. 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.
createdAt 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 Role ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 Role ALTER COLUMN updatedAt TYPE timestamptz;
createdAt 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 RolePermission ALTER COLUMN createdAt TYPE timestamptz;
RoutingFormResponseDenormalized.bookingId may be NULL, so the relationship to Booking is optional. That is legitimate (e.g. 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.
bookingCreatedAt 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 RoutingFormResponseDenormalized ALTER COLUMN bookingCreatedAt TYPE timestamptz;
bookingStartTime 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 RoutingFormResponseDenormalized ALTER COLUMN bookingStartTime TYPE timestamptz;
bookingEndTime 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 RoutingFormResponseDenormalized ALTER COLUMN bookingEndTime TYPE timestamptz;
createdAt 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 RoutingFormResponseDenormalized ALTER COLUMN createdAt TYPE timestamptz;
RoutingTrace.formResponseId may be NULL, so the relationship to App_RoutingForms_FormResponse is optional. That is legitimate (e.g. 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.
RoutingTrace.queuedFormResponseId may be NULL, so the relationship to App_RoutingForms_QueuedFormResponse is optional. That is legitimate (e.g. 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.
RoutingTrace.bookingUid may be NULL, so the relationship to Booking is optional. That is legitimate (e.g. 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.
RoutingTrace.assignmentReasonId may be NULL, so the relationship to AssignmentReason is optional. That is legitimate (e.g. 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.
RoutingTrace has several nullable FKs (formResponseId, queuedFormResponseId, bookingUid, assignmentReasonId) 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 RoutingTrace ADD CONSTRAINT RoutingTrace_one_target CHECK ((formResponseId IS NOT NULL)::int + (queuedFormResponseId IS NOT NULL)::int + (bookingUid IS NOT NULL)::int + (assignmentReasonId IS NOT NULL)::int = 1);
createdAt 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 RoutingTrace ALTER COLUMN createdAt TYPE timestamptz;
SeatChangeLog.processedInProrationId may be NULL, so the relationship to MonthlyProration is optional. That is legitimate (e.g. 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.
SeatChangeLog.teamBillingId may be NULL, so the relationship to TeamBilling is optional. That is legitimate (e.g. 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.
SeatChangeLog.organizationBillingId may be NULL, so the relationship to OrganizationBilling is optional. That is legitimate (e.g. 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.
SeatChangeLog has several nullable FKs (processedInProrationId, teamBillingId, organizationBillingId) 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 SeatChangeLog ADD CONSTRAINT SeatChangeLog_one_target CHECK ((processedInProrationId IS NOT NULL)::int + (teamBillingId IS NOT NULL)::int + (organizationBillingId IS NOT NULL)::int = 1);
changeDate 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 SeatChangeLog ALTER COLUMN changeDate TYPE timestamptz;
createdAt 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 SeatChangeLog ALTER COLUMN createdAt TYPE timestamptz;
emailVerified 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 SecondaryEmail ALTER COLUMN emailVerified TYPE timestamptz;
SelectedCalendar.credentialId may be NULL, so the relationship to Credential is optional. That is legitimate (e.g. 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.
SelectedCalendar.delegationCredentialId may be NULL, so the relationship to DelegationCredential is optional. That is legitimate (e.g. 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.
SelectedCalendar.domainWideDelegationCredentialId may be NULL, so the relationship to DomainWideDelegation is optional. That is legitimate (e.g. 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.
SelectedCalendar.eventTypeId may be NULL, so the relationship to EventType is optional. That is legitimate (e.g. 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.
credentialId, delegationCredentialId, domainWideDelegationCredentialId, eventTypeIdexclusive-arcSelectedCalendar has several nullable FKs (credentialId, delegationCredentialId, domainWideDelegationCredentialId, eventTypeId) 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 SelectedCalendar ADD CONSTRAINT SelectedCalendar_one_target CHECK ((credentialId IS NOT NULL)::int + (delegationCredentialId IS NOT NULL)::int + (domainWideDelegationCredentialId IS NOT NULL)::int + (eventTypeId IS NOT NULL)::int = 1);
createdAt 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 SelectedCalendar ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 SelectedCalendar ALTER COLUMN updatedAt TYPE timestamptz;
channelExpiration 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 SelectedCalendar ALTER COLUMN channelExpiration TYPE timestamptz;
syncSubscribedAt 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 SelectedCalendar ALTER COLUMN syncSubscribedAt TYPE timestamptz;
syncSubscribedErrorAt 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 SelectedCalendar ALTER COLUMN syncSubscribedErrorAt TYPE timestamptz;
syncedAt 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 SelectedCalendar ALTER COLUMN syncedAt TYPE timestamptz;
syncErrorAt 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 SelectedCalendar ALTER COLUMN syncErrorAt TYPE timestamptz;
lastErrorAt 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 SelectedCalendar ALTER COLUMN lastErrorAt TYPE timestamptz;
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.
slotUtcStartDate 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 SelectedSlots ALTER COLUMN slotUtcStartDate TYPE timestamptz;
slotUtcEndDate 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 SelectedSlots ALTER COLUMN slotUtcEndDate TYPE timestamptz;
releaseAt 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 SelectedSlots ALTER COLUMN releaseAt TYPE timestamptz;
SelectedSlots 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.
expires 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 Session ALTER COLUMN expires TYPE timestamptz;
createdAt 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 Task ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 Task ALTER COLUMN updatedAt TYPE timestamptz;
scheduledAt 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 Task ALTER COLUMN scheduledAt TYPE timestamptz;
succeededAt 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 Task ALTER COLUMN succeededAt TYPE timestamptz;
lastFailedAttemptAt 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 Task ALTER COLUMN lastFailedAttemptAt TYPE timestamptz;
Task 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.
Team.parentId may be NULL, so the relationship to Team is optional. That is legitimate (e.g. 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.createdByOAuthClientId may be NULL, so the relationship to PlatformOAuthClient is optional. That is legitimate (e.g. 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 has several nullable FKs (parentId, createdByOAuthClientId) 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 Team ADD CONSTRAINT Team_one_target CHECK ((parentId IS NOT NULL)::int + (createdByOAuthClientId IS NOT NULL)::int = 1);
createdAt 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 Team ALTER COLUMN createdAt TYPE timestamptz;
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.
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.
subscriptionStart 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 TeamBilling ALTER COLUMN subscriptionStart TYPE timestamptz;
subscriptionTrialEnd 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 TeamBilling ALTER COLUMN subscriptionTrialEnd TYPE timestamptz;
subscriptionEnd 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 TeamBilling ALTER COLUMN subscriptionEnd TYPE timestamptz;
highWaterMarkPeriodStart 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 TeamBilling ALTER COLUMN highWaterMarkPeriodStart TYPE timestamptz;
createdAt 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 TeamBilling ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 TeamBilling ALTER COLUMN updatedAt TYPE timestamptz;
assignedAt 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 TeamFeatures ALTER COLUMN assignedAt TYPE timestamptz;
updatedAt 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 TeamFeatures ALTER COLUMN updatedAt TYPE timestamptz;
createdAt 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 TempOrgRedirect ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 TempOrgRedirect ALTER COLUMN updatedAt TYPE timestamptz;
TempOrgRedirect 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.
startDate 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 TravelSchedule ALTER COLUMN startDate TYPE timestamptz;
endDate 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 TravelSchedule ALTER COLUMN endDate TYPE timestamptz;
assignedAt 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 UserFeatures ALTER COLUMN assignedAt TYPE timestamptz;
updatedAt 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 UserFeatures ALTER COLUMN updatedAt TYPE timestamptz;
UserFilterSegmentPreference.segmentId may be NULL, so the relationship to FilterSegment is optional. That is legitimate (e.g. 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.
createdAt 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 UserFilterSegmentPreference ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 UserFilterSegmentPreference ALTER COLUMN updatedAt TYPE timestamptz;
createdAt 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 UserHolidaySettings ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 UserHolidaySettings ALTER COLUMN updatedAt TYPE timestamptz;
VerificationToken.teamId may be NULL, so the relationship to Team is optional. That is legitimate (e.g. 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.
VerificationToken.secondaryEmailId may be NULL, so the relationship to SecondaryEmail is optional. That is legitimate (e.g. 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.
VerificationToken has several nullable FKs (teamId, secondaryEmailId) 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 VerificationToken ADD CONSTRAINT VerificationToken_one_target CHECK ((teamId IS NOT NULL)::int + (secondaryEmailId IS NOT NULL)::int = 1);
expires 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 VerificationToken ALTER COLUMN expires TYPE timestamptz;
createdAt 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 VerificationToken ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 VerificationToken ALTER COLUMN updatedAt TYPE timestamptz;
VerifiedEmail.userId 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.
VerifiedEmail.teamId may be NULL, so the relationship to Team is optional. That is legitimate (e.g. 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.
VerifiedEmail has several nullable FKs (userId, teamId) 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 VerifiedEmail ADD CONSTRAINT VerifiedEmail_one_target CHECK ((userId IS NOT NULL)::int + (teamId IS NOT NULL)::int = 1);
VerifiedNumber.userId 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.
VerifiedNumber.teamId may be NULL, so the relationship to Team is optional. That is legitimate (e.g. 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.
VerifiedNumber has several nullable FKs (userId, teamId) 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 VerifiedNumber ADD CONSTRAINT VerifiedNumber_one_target CHECK ((userId IS NOT NULL)::int + (teamId IS NOT NULL)::int = 1);
joinedAt 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 VideoCallGuest ALTER COLUMN joinedAt TYPE timestamptz;
createdAt 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 VideoCallGuest ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 VideoCallGuest ALTER COLUMN updatedAt TYPE timestamptz;
VideoCallGuest 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.
lastUpdatedAt 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 Watchlist ALTER COLUMN lastUpdatedAt TYPE timestamptz;
WatchlistAudit.watchlistId may be NULL, so the relationship to Watchlist is optional. That is legitimate (e.g. 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.
changedAt 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 WatchlistAudit ALTER COLUMN changedAt TYPE timestamptz;
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 WatchlistEventAudit ALTER COLUMN timestamp TYPE timestamptz;
WatchlistEventAudit 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.
Webhook.userId 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.
Webhook.teamId may be NULL, so the relationship to Team is optional. That is legitimate (e.g. 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.eventTypeId may be NULL, so the relationship to EventType is optional. That is legitimate (e.g. 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.platformOAuthClientId may be NULL, so the relationship to PlatformOAuthClient is optional. That is legitimate (e.g. 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.appId may be NULL, so the relationship to App is optional. That is legitimate (e.g. 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 has several nullable FKs (userId, teamId, eventTypeId, platformOAuthClientId, appId) 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 ADD CONSTRAINT Webhook_one_target CHECK ((userId IS NOT NULL)::int + (teamId IS NOT NULL)::int + (eventTypeId IS NOT NULL)::int + (platformOAuthClientId IS NOT NULL)::int + (appId IS NOT NULL)::int = 1);
createdAt 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 Webhook ALTER COLUMN createdAt TYPE timestamptz;
WebhookScheduledTriggers.webhookId may be NULL, so the relationship to Webhook is optional. That is legitimate (e.g. 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.
WebhookScheduledTriggers.bookingId may be NULL, so the relationship to Booking is optional. That is legitimate (e.g. 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.
WebhookScheduledTriggers has several nullable FKs (webhookId, bookingId) 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 WebhookScheduledTriggers ADD CONSTRAINT WebhookScheduledTriggers_one_target CHECK ((webhookId IS NOT NULL)::int + (bookingId IS NOT NULL)::int = 1);
startAfter 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 WebhookScheduledTriggers ALTER COLUMN startAfter TYPE timestamptz;
createdAt 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 WebhookScheduledTriggers ALTER COLUMN createdAt TYPE timestamptz;
Workflow.userId 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.
Workflow.teamId may be NULL, so the relationship to Team is optional. That is legitimate (e.g. 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.
Workflow has several nullable FKs (userId, teamId) 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 Workflow ADD CONSTRAINT Workflow_one_target CHECK ((userId IS NOT NULL)::int + (teamId IS NOT NULL)::int = 1);
createdAt 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 WorkflowOptOutContact ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 WorkflowOptOutContact ALTER COLUMN updatedAt TYPE timestamptz;
WorkflowOptOutContact 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.
WorkflowReminder.bookingUid may be NULL, so the relationship to Booking is optional. That is legitimate (e.g. 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.
WorkflowReminder.workflowStepId may be NULL, so the relationship to WorkflowStep is optional. That is legitimate (e.g. 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.
WorkflowReminder has several nullable FKs (bookingUid, workflowStepId) 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 WorkflowReminder ADD CONSTRAINT WorkflowReminder_one_target CHECK ((bookingUid IS NOT NULL)::int + (workflowStepId IS NOT NULL)::int = 1);
scheduledDate 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 WorkflowReminder ALTER COLUMN scheduledDate TYPE timestamptz;
WorkflowStep.agentId may be NULL, so the relationship to Agent is optional. That is legitimate (e.g. 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.
WorkflowStep.inboundAgentId may be NULL, so the relationship to Agent is optional. That is legitimate (e.g. 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.
WorkflowStep has several nullable FKs (agentId, inboundAgentId) 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 WorkflowStep ADD CONSTRAINT WorkflowStep_one_target CHECK ((agentId IS NOT NULL)::int + (inboundAgentId IS NOT NULL)::int = 1);
verifiedAt 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 WorkflowStep ALTER COLUMN verifiedAt TYPE timestamptz;
createdAt 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 WorkflowStepTranslation ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 WorkflowStepTranslation ALTER COLUMN updatedAt TYPE timestamptz;
createdAt 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 WorkspacePlatform ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 WorkspacePlatform ALTER COLUMN updatedAt TYPE timestamptz;
WrongAssignmentReport.reportedById 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.
WrongAssignmentReport.teamId may be NULL, so the relationship to Team is optional. That is legitimate (e.g. 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.
WrongAssignmentReport.routingFormId may be NULL, so the relationship to App_RoutingForms_Form is optional. That is legitimate (e.g. 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.
WrongAssignmentReport.reviewedById 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.
WrongAssignmentReport has several nullable FKs (reportedById, teamId, routingFormId, reviewedById) 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 WrongAssignmentReport ADD CONSTRAINT WrongAssignmentReport_one_target CHECK ((reportedById IS NOT NULL)::int + (teamId IS NOT NULL)::int + (routingFormId IS NOT NULL)::int + (reviewedById IS NOT NULL)::int = 1);
reviewedAt 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 WrongAssignmentReport ALTER COLUMN reviewedAt TYPE timestamptz;
createdAt 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 WrongAssignmentReport ALTER COLUMN createdAt TYPE timestamptz;
updatedAt 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 WrongAssignmentReport ALTER COLUMN updatedAt TYPE timestamptz;
avatars 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.
users.organizationId may be NULL, so the relationship to Team is optional. That is legitimate (e.g. 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.movedToProfileId may be NULL, so the relationship to Profile is optional. That is legitimate (e.g. 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 has several nullable FKs (organizationId, movedToProfileId) 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 users ADD CONSTRAINT users_one_target CHECK ((organizationId IS NOT NULL)::int + (movedToProfileId IS NOT NULL)::int = 1);
emailVerified 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 users ALTER COLUMN emailVerified TYPE timestamptz;
created 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 users ALTER COLUMN created TYPE timestamptz;
trialEndsAt 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 users ALTER COLUMN trialEndsAt TYPE timestamptz;
lastActiveAt 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 users ALTER COLUMN lastActiveAt TYPE timestamptz;
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.
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.
121 tables · 220 foreign keys · 23 domains. Open the 3D explorer: rotate, zoom, click any table or relationship.
Tables whose names start with Host_.
Host.userId → users.id — one users, many Host · required · ON DELETE CASCADE · indexedHost.eventTypeId → EventType.id — one EventType, many Host · required · ON DELETE CASCADE · indexedHost.scheduleId → Schedule.id — one Schedule, many Host · optional · ON DELETE SET NULL · indexedHost.groupId → HostGroup.id — one HostGroup, many Host · optional · ON DELETE SET NULL · not indexedHost.memberId → Membership.id — one Membership, many Host · optional · ON DELETE CASCADE · indexedHostGroup.eventTypeId → EventType.id — one EventType, many HostGroup · optional · ON DELETE CASCADE · indexedHostLocation.userId, eventTypeId → Host.userId, eventTypeId — one Host, at most one HostLocation · required · ON DELETE CASCADE · indexedHostLocation.credentialId → Credential.id — one Credential, many HostLocation · optional · ON DELETE SET NULL · indexedCreateTable
groupId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on HostGroup must scan Host to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to Host maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often HostGroup rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.scheduleId — Host.scheduleId may be NULL, so the relationship to Schedule is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.groupId — Host.groupId may be NULL, so the relationship to HostGroup is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.memberId — Host.memberId may be NULL, so the relationship to Membership is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.scheduleId, groupId, memberId — Host has several nullable FKs (scheduleId, groupId, memberId) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.createdAt — createdAt 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 |
|---|---|---|---|---|---|
userId PK | integer | NOT NULL | users.id 1:N · CASCADE | ||
eventTypeId PK | integer | NOT NULL | EventType.id 1:N · CASCADE | ||
isFixed | boolean | NOT NULL | FALSE | ||
priority | integer | null | |||
weight | integer | null | |||
weightAdjustment | integer | null | |||
scheduleId | integer | null | Schedule.id 1:N · SET NULL | ||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
groupId | text | null | HostGroup.id 1:N · SET NULL | ||
memberId | integer | null | Membership.id 1:N · CASCADE |
CreateTable
eventTypeId — HostGroup.eventTypeId may be NULL, so the relationship to EventType is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 | text | NOT NULL | |||
name | text | NOT NULL | |||
eventTypeId | integer | null | EventType.id 1:N · CASCADE | ||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | NOT NULL |
CreateTable
credentialId — HostLocation.credentialId may be NULL, so the relationship to Credential is optional. That is legitimate (e.g. 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.createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 | text | NOT NULL | |||
userId | integer | NOT NULL | Host.userId 1:1 · CASCADE | ||
eventTypeId | integer | NOT NULL | Host.userId 1:1 · CASCADE | ||
type | text | NOT NULL | |||
credentialId | integer | null | Credential.id 1:N · SET NULL | ||
link | text | null | |||
address | text | null | |||
phoneNumber | text | null | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | NOT NULL |
Tables whose names start with Cal_.
CalVideoSettings.eventTypeId → EventType.id — one EventType, at most one CalVideoSettings · required · ON DELETE CASCADE · indexedCalAiPhoneNumber.userId → users.id — one users, many CalAiPhoneNumber · optional · ON DELETE CASCADE · indexedCalAiPhoneNumber.teamId → Team.id — one Team, many CalAiPhoneNumber · optional · ON DELETE CASCADE · indexedCalAiPhoneNumber.inboundAgentId → Agent.id — one Agent, many CalAiPhoneNumber · optional · ON DELETE SET NULL · indexedCalAiPhoneNumber.outboundAgentId → Agent.id — one Agent, many CalAiPhoneNumber · optional · ON DELETE SET NULL · indexedCreateTable
createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 |
|---|---|---|---|---|---|
eventTypeId PK | integer | NOT NULL | EventType.id 1:1 · CASCADE | ||
disableRecordingForOrganizer | boolean | NOT NULL | FALSE | ||
disableRecordingForGuests | boolean | NOT NULL | FALSE | ||
enableAutomaticTranscription | boolean | NOT NULL | FALSE | ||
enableAutomaticRecordingForOrganizer | boolean | NOT NULL | FALSE | ||
redirectUrlOnExit | text | null | |||
disableTranscriptionForGuests | boolean | NOT NULL | FALSE | ||
disableTranscriptionForOrganizer | boolean | NOT NULL | FALSE | ||
requireEmailForGuests | boolean | NOT NULL | FALSE | ||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | NOT NULL |
CreateTable
userId — CalAiPhoneNumber.userId 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.teamId — CalAiPhoneNumber.teamId may be NULL, so the relationship to Team is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.inboundAgentId — CalAiPhoneNumber.inboundAgentId may be NULL, so the relationship to Agent is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.outboundAgentId — CalAiPhoneNumber.outboundAgentId may be NULL, so the relationship to Agent is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.userId, teamId, inboundAgentId, outboundAgentId — CalAiPhoneNumber has several nullable FKs (userId, teamId, inboundAgentId, outboundAgentId) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 | serial | NOT NULL | |||
userId | integer | null | users.id 1:N · CASCADE | ||
teamId | integer | null | Team.id 1:N · CASCADE | ||
phoneNumber | text | NOT NULL | |||
provider | text | NOT NULL | |||
providerPhoneNumberId | text | null | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | NOT NULL | |||
stripeCustomerId | text | null | |||
stripeSubscriptionId | text | null | |||
subscriptionStatus | PhoneNumberSubscriptionStatus | null | |||
inboundAgentId | text | null | Agent.id 1:N · SET NULL | ||
outboundAgentId | text | null | Agent.id 1:N · SET NULL |
Tables whose names start with Event_.
EventType.userId → users.id — one users, many EventType · optional · ON DELETE CASCADE · indexedEventType.profileId → Profile.id — one Profile, many EventType · optional · ON DELETE SET NULL · indexedEventType.teamId → Team.id — one Team, many EventType · optional · ON DELETE CASCADE · indexedEventType.parentId → EventType.id — one EventType, many EventType · optional · ON DELETE CASCADE · indexedEventType.scheduleId → Schedule.id — one Schedule, many EventType · optional · ON DELETE SET NULL · indexedEventType.instantMeetingScheduleId → Schedule.id — one Schedule, many EventType · optional · ON DELETE SET NULL · not indexedEventType.secondaryEmailId → SecondaryEmail.id — one SecondaryEmail, many EventType · optional · ON DELETE CASCADE · indexedEventType.restrictionScheduleId → Schedule.id — one Schedule, many EventType · optional · ON DELETE SET NULL · indexedEventTypeCustomInput.eventTypeId → EventType.id — one EventType, many EventTypeCustomInput · required · ON DELETE CASCADE · indexedEventTypeTranslation.eventTypeId → EventType.id — one EventType, many EventTypeTranslation · required · ON DELETE CASCADE · indexedEventTypeTranslation.createdBy → users.id — one users, many EventTypeTranslation · required · ON DELETE RESTRICT · not indexedEventTypeTranslation.updatedBy → users.id — one users, many EventTypeTranslation · optional · ON DELETE SET NULL · not indexedCreateTable
instantMeetingScheduleId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on Schedule must scan EventType to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to EventType maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often Schedule rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.userId — EventType.userId 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.profileId — EventType.profileId may be NULL, so the relationship to Profile is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.teamId — EventType.teamId may be NULL, so the relationship to Team is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.parentId — EventType.parentId may be NULL, so the relationship to EventType is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.scheduleId — EventType.scheduleId may be NULL, so the relationship to Schedule is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.instantMeetingScheduleId — EventType.instantMeetingScheduleId may be NULL, so the relationship to Schedule is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.secondaryEmailId — EventType.secondaryEmailId may be NULL, so the relationship to SecondaryEmail is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.restrictionScheduleId — EventType.restrictionScheduleId may be NULL, so the relationship to Schedule is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.userId, profileId, teamId, parentId, scheduleId, instantMeetingScheduleId, secondaryEmailId, restrictionScheduleId — EventType has several nullable FKs (userId, profileId, teamId, parentId, scheduleId, instantMeetingScheduleId, secondaryEmailId, restrictionScheduleId) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.periodStartDate — periodStartDate stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.periodEndDate — periodEndDate stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 | serial | NOT NULL | |||
title | text | NOT NULL | |||
slug | text | NOT NULL | |||
description | text | null | |||
interfaceLanguage | text | null | |||
position | integer | NOT NULL | 0 | ||
locations | jsonb | null | |||
length | integer | NOT NULL | |||
offsetStart | integer | NOT NULL | 0 | ||
hidden | boolean | NOT NULL | FALSE | ||
userId | integer | null | users.id 1:N · CASCADE | ||
profileId | integer | null | Profile.id 1:N · SET NULL | ||
teamId | integer | null | Team.id 1:N · CASCADE | ||
useEventLevelSelectedCalendars | boolean | NOT NULL | FALSE | ||
eventName | text | null | |||
parentId | integer | null | EventType.id 1:N · CASCADE | ||
bookingFields | jsonb | null | |||
timeZone | text | null | |||
periodType | PeriodType | NOT NULL | 'unlimited' | ||
periodStartDate | timestamp(3) | null | |||
periodEndDate | timestamp(3) | null | |||
periodDays | integer | null | |||
periodCountCalendarDays | boolean | null | |||
lockTimeZoneToggleOnBookingPage | boolean | NOT NULL | FALSE | ||
lockedTimeZone | text | null | |||
requiresConfirmation | boolean | NOT NULL | FALSE | ||
requiresConfirmationWillBlockSlot | boolean | NOT NULL | FALSE | ||
requiresConfirmationForFreeEmail | boolean | NOT NULL | FALSE | ||
requiresBookerEmailVerification | boolean | NOT NULL | FALSE | ||
canSendCalVideoTranscriptionEmails | boolean | NOT NULL | TRUE | ||
autoTranslateDescriptionEnabled | boolean | NOT NULL | FALSE | ||
autoTranslateInstantMeetingTitleEnabled | boolean | NOT NULL | TRUE | ||
recurringEvent | jsonb | null | |||
disableGuests | boolean | NOT NULL | FALSE | ||
hideCalendarNotes | boolean | NOT NULL | FALSE | ||
hideCalendarEventDetails | boolean | NOT NULL | FALSE | ||
minimumBookingNotice | integer | NOT NULL | 120 | ||
beforeEventBuffer | integer | NOT NULL | 0 | ||
afterEventBuffer | integer | NOT NULL | 0 | ||
seatsPerTimeSlot | integer | null | |||
onlyShowFirstAvailableSlot | boolean | NOT NULL | FALSE | ||
showOptimizedSlots | boolean | null | FALSE | ||
disableCancelling | boolean | null | FALSE | ||
disableRescheduling | boolean | null | FALSE | ||
minimumRescheduleNotice | integer | null | |||
seatsShowAttendees | boolean | null | FALSE | ||
seatsShowAvailabilityCount | boolean | null | TRUE | ||
schedulingType | SchedulingType | null | |||
scheduleId | integer | null | Schedule.id 1:N · SET NULL | ||
allowReschedulingCancelledBookings | boolean | null | FALSE | ||
price | integer | NOT NULL | 0 | ||
currency | text | NOT NULL | 'usd' | ||
slotInterval | integer | null | |||
metadata | jsonb | null | |||
successRedirectUrl | text | null | |||
forwardParamsSuccessRedirect | boolean | null | TRUE | ||
redirectUrlOnNoRoutingFormResponse | text | null | |||
bookingLimits | jsonb | null | |||
durationLimits | jsonb | null | |||
isInstantEvent | boolean | NOT NULL | FALSE | ||
instantMeetingExpiryTimeOffsetInSeconds | integer | NOT NULL | 90 | ||
instantMeetingScheduleId | integer | null | Schedule.id 1:N · SET NULL | ||
instantMeetingParameters | text[] | null | |||
assignAllTeamMembers | boolean | NOT NULL | FALSE | ||
assignRRMembersUsingSegment | boolean | NOT NULL | FALSE | ||
rrSegmentQueryValue | jsonb | null | |||
useEventTypeDestinationCalendarEmail | boolean | NOT NULL | FALSE | ||
isRRWeightsEnabled | boolean | NOT NULL | FALSE | ||
maxLeadThreshold | integer | null | |||
includeNoShowInRRCalculation | boolean | NOT NULL | FALSE | ||
allowReschedulingPastBookings | boolean | NOT NULL | FALSE | ||
hideOrganizerEmail | boolean | NOT NULL | FALSE | ||
maxActiveBookingsPerBooker | integer | null | |||
maxActiveBookingPerBookerOfferReschedule | boolean | NOT NULL | FALSE | ||
customReplyToEmail | text | null | |||
eventTypeColor | jsonb | null | |||
rescheduleWithSameRoundRobinHost | boolean | NOT NULL | FALSE | ||
secondaryEmailId | integer | null | SecondaryEmail.id 1:N · CASCADE | ||
useBookerTimezone | boolean | NOT NULL | FALSE | ||
restrictionScheduleId | integer | null | Schedule.id 1:N · SET NULL | ||
bookingRequiresAuthentication | boolean | NOT NULL | FALSE | ||
rrHostSubsetEnabled | boolean | NOT NULL | FALSE | ||
requiresCancellationReason | CancellationReasonRequirement | null | 'MANDATORY_HOST_ONLY' | ||
enablePerHostLocations | boolean | NOT NULL | FALSE | ||
createdAt | timestamp(3) | null | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | null |
CreateTable
| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | serial | NOT NULL | |||
eventTypeId | integer | NOT NULL | EventType.id 1:N · CASCADE | ||
label | text | NOT NULL | |||
type | EventTypeCustomInputType | NOT NULL | |||
options | jsonb | null | |||
required | boolean | NOT NULL | |||
placeholder | text | NOT NULL | '' |
CreateTable
createdBy — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan EventTypeTranslation to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to EventTypeTranslation 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.updatedBy — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan EventTypeTranslation to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to EventTypeTranslation 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.updatedBy — EventTypeTranslation.updatedBy 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.createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 |
|---|---|---|---|---|---|
uid PK | text | NOT NULL | |||
eventTypeId | integer | NOT NULL | EventType.id 1:N · CASCADE | ||
field | EventTypeAutoTranslatedField | NOT NULL | |||
sourceLocale | text | NOT NULL | |||
targetLocale | text | NOT NULL | |||
translatedText | text | NOT NULL | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
createdBy | integer | NOT NULL | users.id 1:N · RESTRICT | ||
updatedAt | timestamp(3) | NOT NULL | |||
updatedBy | integer | null | users.id 1:N · SET NULL |
Tables whose names start with User_.
UserPassword.userId → users.id — one users, at most one UserPassword · required · ON DELETE CASCADE · indexedUserFeatures.userId → users.id — one users, many UserFeatures · required · ON DELETE CASCADE · indexedUserFeatures.featureId → Feature.slug — one Feature, many UserFeatures · required · ON DELETE CASCADE · not indexedUserHolidaySettings.userId → users.id — one users, at most one UserHolidaySettings · required · ON DELETE CASCADE · indexedUserFilterSegmentPreference.userId → users.id — one users, many UserFilterSegmentPreference · required · ON DELETE CASCADE · indexedUserFilterSegmentPreference.segmentId → FilterSegment.id — one FilterSegment, many UserFilterSegmentPreference · optional · ON DELETE CASCADE · indexedCreateTable
| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
hash | text | NOT NULL | |||
userId | integer | NOT NULL | users.id 1:1 · CASCADE |
CreateTable
featureId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on Feature must scan UserFeatures to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to UserFeatures maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often Feature rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.assignedAt — assignedAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 |
|---|---|---|---|---|---|
userId PK | integer | NOT NULL | users.id 1:N · CASCADE | ||
featureId PK | text | NOT NULL | Feature.slug 1:N · CASCADE | ||
enabled | boolean | NOT NULL | |||
assignedAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
assignedBy | text | NOT NULL | |||
updatedAt | timestamp(3) | NOT NULL |
CreateTable
createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 | serial | NOT NULL | |||
userId | integer | NOT NULL | users.id 1:1 · CASCADE | ||
countryCode | text | null | |||
disabledIds | text[] | null | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | NOT NULL |
CreateTable
segmentId — UserFilterSegmentPreference.segmentId may be NULL, so the relationship to FilterSegment is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 | serial | NOT NULL | |||
userId | integer | NOT NULL | users.id 1:N · CASCADE | ||
tableIdentifier | text | NOT NULL | |||
segmentId | integer | null | FilterSegment.id 1:N · CASCADE | ||
systemSegmentId | text | null | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | NOT NULL |
Tables whose names start with Team_.
Team.parentId → Team.id — one Team, many Team · optional · ON DELETE CASCADE · indexedTeam.createdByOAuthClientId → PlatformOAuthClient.id — one PlatformOAuthClient, many Team · optional · ON DELETE CASCADE · not indexedTeamFeatures.teamId → Team.id — one Team, many TeamFeatures · required · ON DELETE CASCADE · indexedTeamFeatures.featureId → Feature.slug — one Feature, many TeamFeatures · required · ON DELETE CASCADE · not indexedTeamBilling.teamId → Team.id — one Team, at most one TeamBilling · required · ON DELETE CASCADE · indexedCreateTable
createdByOAuthClientId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on PlatformOAuthClient must scan Team to check the constraint, and every join from the parent side is a sequential scan. 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 maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often PlatformOAuthClient rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.parentId — Team.parentId may be NULL, so the relationship to Team is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.createdByOAuthClientId — Team.createdByOAuthClientId may be NULL, so the relationship to PlatformOAuthClient is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.parentId, createdByOAuthClientId — Team has several nullable FKs (parentId, createdByOAuthClientId) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.createdAt — createdAt 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 | serial | NOT NULL | |||
name | text | NOT NULL | |||
slug | text | null | |||
logoUrl | text | null | |||
calVideoLogo | text | null | |||
appLogo | text | null | |||
appIconLogo | text | null | |||
bio | text | null | |||
hideBranding | boolean | NOT NULL | FALSE | ||
hideTeamProfileLink | boolean | NOT NULL | FALSE | ||
isPrivate | boolean | NOT NULL | FALSE | ||
hideBookATeamMember | boolean | NOT NULL | FALSE | ||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
metadata | jsonb | null | |||
theme | text | null | |||
rrResetInterval | RRResetInterval | null | 'MONTH' | ||
rrTimestampBasis | RRTimestampBasis | NOT NULL | 'CREATED_AT' | ||
brandColor | text | null | |||
darkBrandColor | text | null | |||
bannerUrl | text | null | |||
parentId | integer | null | Team.id 1:N · CASCADE | ||
timeFormat | integer | null | |||
timeZone | text | NOT NULL | 'Europe/London' | ||
weekStart | text | NOT NULL | 'Sunday' | ||
isOrganization | boolean | NOT NULL | FALSE | ||
pendingPayment | boolean | NOT NULL | FALSE | ||
isPlatform | boolean | NOT NULL | FALSE | ||
createdByOAuthClientId | text | null | PlatformOAuthClient.id 1:N · CASCADE | ||
smsLockState | SMSLockState | NOT NULL | 'UNLOCKED' | ||
smsLockReviewedByAdmin | boolean | NOT NULL | FALSE | ||
bookingLimits | jsonb | null | |||
includeManagedEventsInLimits | boolean | NOT NULL | FALSE | ||
autoOptInFeatures | boolean | NOT NULL | FALSE |
CreateTable
featureId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on Feature must scan TeamFeatures to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to TeamFeatures maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often Feature rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.assignedAt — assignedAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 |
|---|---|---|---|---|---|
teamId PK | integer | NOT NULL | Team.id 1:N · CASCADE | ||
featureId PK | text | NOT NULL | Feature.slug 1:N · CASCADE | ||
enabled | boolean | NOT NULL | |||
assignedAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
assignedBy | text | NOT NULL | |||
updatedAt | timestamp(3) | NOT NULL |
CreateTable
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.subscriptionStart — subscriptionStart stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.subscriptionTrialEnd — subscriptionTrialEnd stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.subscriptionEnd — subscriptionEnd stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.highWaterMarkPeriodStart — highWaterMarkPeriodStart stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 | text | NOT NULL | |||
teamId | integer | NOT NULL | Team.id 1:1 · CASCADE | ||
subscriptionId | text | NOT NULL | |||
subscriptionItemId | text | NOT NULL | |||
customerId | text | NOT NULL | |||
status | text | NOT NULL | |||
planName | text | NOT NULL | |||
subscriptionStart | timestamp(3) | null | |||
subscriptionTrialEnd | timestamp(3) | null | |||
subscriptionEnd | timestamp(3) | null | |||
billingPeriod | BillingPeriod | null | |||
billingMode | BillingMode | NOT NULL | 'SEATS' | ||
pricePerSeat | integer | null | |||
paidSeats | integer | null | |||
highWaterMark | integer | null | |||
highWaterMarkPeriodStart | timestamp(3) | null | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | NOT NULL |
Tables whose names start with Credit_.
CreditBalance.teamId → Team.id — one Team, at most one CreditBalance · optional · ON DELETE CASCADE · indexedCreditBalance.userId → users.id — one users, at most one CreditBalance · optional · ON DELETE CASCADE · indexedCreditPurchaseLog.creditBalanceId → CreditBalance.id — one CreditBalance, many CreditPurchaseLog · required · ON DELETE CASCADE · not indexedCreditExpenseLog.creditBalanceId → CreditBalance.id — one CreditBalance, many CreditExpenseLog · required · ON DELETE CASCADE · not indexedCreditExpenseLog.bookingUid → Booking.uid — one Booking, many CreditExpenseLog · optional · ON DELETE CASCADE · not indexedCreateTable
teamId — CreditBalance.teamId may be NULL, so the relationship to Team is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.userId — CreditBalance.userId 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.teamId, userId — CreditBalance has several nullable FKs (teamId, userId) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.limitReachedAt — limitReachedAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.warningSentAt — warningSentAt 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 | text | NOT NULL | |||
teamId | integer | null | Team.id 1:1 · CASCADE | ||
userId | integer | null | users.id 1:1 · CASCADE | ||
additionalCredits | integer | NOT NULL | 0 | ||
limitReachedAt | timestamp(3) | null | |||
warningSentAt | timestamp(3) | null |
CreateTable
creditBalanceId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on CreditBalance must scan CreditPurchaseLog to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to CreditPurchaseLog maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often CreditBalance rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.createdAt — createdAt 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 | text | NOT NULL | |||
creditBalanceId | text | NOT NULL | CreditBalance.id 1:N · CASCADE | ||
credits | integer | NOT NULL | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP |
CreateTable
creditBalanceId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on CreditBalance must scan CreditExpenseLog to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to CreditExpenseLog maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often CreditBalance rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.bookingUid — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on Booking must scan CreditExpenseLog to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to CreditExpenseLog maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often Booking rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.bookingUid — CreditExpenseLog.bookingUid may be NULL, so the relationship to Booking is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.date — date 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 | text | NOT NULL | |||
creditBalanceId | text | NOT NULL | CreditBalance.id 1:N · CASCADE | ||
bookingUid | text | null | Booking.uid 1:N · CASCADE | ||
credits | integer | null | |||
creditType | CreditType | NOT NULL | |||
date | timestamp(3) | NOT NULL | |||
smsSid | text | null | |||
smsSegments | integer | null | |||
phoneNumber | text | null | |||
email | text | null | |||
callDuration | integer | null | |||
creditFor | CreditUsageType | null | |||
externalRef | text | null |
Tables whose names start with Organization_.
OrganizationSettings.organizationId → Team.id — one Team, at most one OrganizationSettings · required · ON DELETE CASCADE · indexedOrganizationOnboarding.createdById → users.id — one users, many OrganizationOnboarding · required · ON DELETE CASCADE · not indexedOrganizationOnboarding.organizationId → Team.id — one Team, at most one OrganizationOnboarding · optional · ON DELETE CASCADE · indexedOrganizationBilling.teamId → Team.id — one Team, at most one OrganizationBilling · required · ON DELETE CASCADE · indexedCreateTable
| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | serial | NOT NULL | |||
organizationId | integer | NOT NULL | Team.id 1:1 · CASCADE | ||
isOrganizationConfigured | boolean | NOT NULL | FALSE | ||
isOrganizationVerified | boolean | NOT NULL | FALSE | ||
orgAutoAcceptEmail | text | NOT NULL | |||
lockEventTypeCreationForUsers | boolean | NOT NULL | FALSE | ||
adminGetsNoSlotsNotification | boolean | NOT NULL | FALSE | ||
isAdminReviewed | boolean | NOT NULL | FALSE | ||
isAdminAPIEnabled | boolean | NOT NULL | FALSE | ||
allowSEOIndexing | boolean | NOT NULL | FALSE | ||
orgProfileRedirectsToVerifiedDomain | boolean | NOT NULL | FALSE | ||
disablePhoneOnlySMSNotifications | boolean | NOT NULL | FALSE | ||
disableAutofillOnBookingPage | boolean | NOT NULL | FALSE | ||
orgAutoJoinOnSignup | boolean | NOT NULL | TRUE | ||
disableAttendeeConfirmationEmail | boolean | NOT NULL | FALSE | ||
disableAttendeeCancellationEmail | boolean | NOT NULL | FALSE | ||
disableAttendeeRescheduledEmail | boolean | NOT NULL | FALSE | ||
disableAttendeeRequestEmail | boolean | NOT NULL | FALSE | ||
disableAttendeeReassignedEmail | boolean | NOT NULL | FALSE | ||
disableAttendeeAwaitingPaymentEmail | boolean | NOT NULL | FALSE | ||
disableAttendeeRescheduleRequestEmail | boolean | NOT NULL | FALSE | ||
disableAttendeeLocationChangeEmail | boolean | NOT NULL | FALSE | ||
disableAttendeeNewEventEmail | boolean | NOT NULL | FALSE |
CreateTable
createdById — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan OrganizationOnboarding to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to OrganizationOnboarding 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.organizationId — OrganizationOnboarding.organizationId may be NULL, so the relationship to Team is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.pricePerSeat — pricePerSeat is binary floating point. 0.1 + 0.2 ≠ 0.3; sums drift; reconciliation against the ledger will be off by cents.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | text | NOT NULL | |||
createdById | integer | NOT NULL | users.id 1:N · CASCADE | ||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
orgOwnerEmail | text | NOT NULL | |||
error | text | null | |||
updatedAt | timestamp(3) | NOT NULL | |||
organizationId | integer | null | Team.id 1:1 · CASCADE | ||
billingPeriod | BillingPeriod | NOT NULL | |||
pricePerSeat | double precision | NOT NULL | |||
seats | integer | NOT NULL | |||
isPlatform | boolean | NOT NULL | FALSE | ||
name | text | NOT NULL | |||
slug | text | NOT NULL | |||
logo | text | null | |||
bio | text | null | |||
brandColor | text | null | |||
bannerUrl | text | null | |||
isDomainConfigured | boolean | NOT NULL | FALSE | ||
stripeCustomerId | text | null | |||
stripeSubscriptionId | text | null | |||
stripeSubscriptionItemId | text | null | |||
invitedMembers | jsonb | NOT NULL | '[]' | ||
teams | jsonb | NOT NULL | '[]' | ||
isComplete | boolean | NOT NULL | FALSE |
CreateTable
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.subscriptionStart — subscriptionStart stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.subscriptionTrialEnd — subscriptionTrialEnd stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.subscriptionEnd — subscriptionEnd stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.highWaterMarkPeriodStart — highWaterMarkPeriodStart stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 | text | NOT NULL | |||
teamId | integer | NOT NULL | Team.id 1:1 · CASCADE | ||
subscriptionId | text | NOT NULL | |||
subscriptionItemId | text | NOT NULL | |||
customerId | text | NOT NULL | |||
status | text | NOT NULL | |||
planName | text | NOT NULL | |||
subscriptionStart | timestamp(3) | null | |||
subscriptionTrialEnd | timestamp(3) | null | |||
subscriptionEnd | timestamp(3) | null | |||
billingPeriod | BillingPeriod | null | |||
billingMode | BillingMode | NOT NULL | 'SEATS' | ||
pricePerSeat | integer | null | |||
paidSeats | integer | null | |||
highWaterMark | integer | null | |||
highWaterMarkPeriodStart | timestamp(3) | null | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | NOT NULL |
Tables whose names start with Booking_.
BookingReference.bookingId → Booking.id — one Booking, many BookingReference · optional · ON DELETE CASCADE · indexedBookingReference.credentialId → Credential.id — one Credential, many BookingReference · optional · ON DELETE SET NULL · not indexedBookingReference.delegationCredentialId → DelegationCredential.id — one DelegationCredential, many BookingReference · optional · ON DELETE SET NULL · not indexedBookingReference.domainWideDelegationCredentialId → DomainWideDelegation.id — one DomainWideDelegation, many BookingReference · optional · ON DELETE SET NULL · not indexedBooking.userId → users.id — one users, many Booking · optional · ON DELETE CASCADE · indexedBooking.eventTypeId → EventType.id — one EventType, many Booking · optional · ON DELETE SET NULL · indexedBooking.destinationCalendarId → DestinationCalendar.id — one DestinationCalendar, many Booking · optional · ON DELETE SET NULL · indexedBooking.reassignById → users.id — one users, many Booking · optional · ON DELETE SET NULL · not indexedBookingSeat.bookingId → Booking.id — one Booking, many BookingSeat · required · ON DELETE CASCADE · indexedBookingSeat.attendeeId → Attendee.id — one Attendee, at most one BookingSeat · required · ON DELETE CASCADE · indexedBookingReport.bookingUid → Booking.uid — one Booking, at most one BookingReport · required · ON DELETE CASCADE · indexedBookingReport.reportedById → users.id — one users, many BookingReport · optional · ON DELETE SET NULL · indexedBookingReport.organizationId → Team.id — one Team, many BookingReport · optional · ON DELETE CASCADE · indexedBookingReport.watchlistId → Watchlist.id — one Watchlist, many BookingReport · optional · ON DELETE SET NULL · indexedBookingReport.globalWatchlistId → Watchlist.id — one Watchlist, many BookingReport · optional · ON DELETE SET NULL · indexedBookingInternalNote.notePresetId → InternalNotePreset.id — one InternalNotePreset, many BookingInternalNote · optional · ON DELETE CASCADE · not indexedBookingInternalNote.bookingId → Booking.id — one Booking, many BookingInternalNote · required · ON DELETE CASCADE · indexedBookingInternalNote.createdById → users.id — one users, many BookingInternalNote · required · ON DELETE RESTRICT · not indexedBookingAudit.actorId → AuditActor.id — one AuditActor, many BookingAudit · required · ON DELETE RESTRICT · indexedCreateTable
credentialId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on Credential must scan BookingReference to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to BookingReference maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often Credential rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.delegationCredentialId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on DelegationCredential must scan BookingReference to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to BookingReference maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often DelegationCredential rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.domainWideDelegationCredentialId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on DomainWideDelegation must scan BookingReference to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to BookingReference maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often DomainWideDelegation rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.bookingId — BookingReference.bookingId may be NULL, so the relationship to Booking is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.credentialId — BookingReference.credentialId may be NULL, so the relationship to Credential is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.delegationCredentialId — BookingReference.delegationCredentialId may be NULL, so the relationship to DelegationCredential is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.domainWideDelegationCredentialId — BookingReference.domainWideDelegationCredentialId may be NULL, so the relationship to DomainWideDelegation is optional. That is legitimate (e.g. 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.bookingId, credentialId, delegationCredentialId, domainWideDelegationCredentialId — BookingReference has several nullable FKs (bookingId, credentialId, delegationCredentialId, domainWideDelegationCredentialId) 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 | serial | NOT NULL | |||
type | text | NOT NULL | |||
uid | text | NOT NULL | |||
meetingId | text | null | |||
thirdPartyRecurringEventId | text | null | |||
meetingPassword | text | null | |||
meetingUrl | text | null | |||
bookingId | integer | null | Booking.id 1:N · CASCADE | ||
externalCalendarId | text | null | |||
deleted | boolean | null | |||
credentialId | integer | null | Credential.id 1:N · SET NULL | ||
delegationCredentialId | text | null | DelegationCredential.id 1:N · SET NULL | ||
domainWideDelegationCredentialId | text | null | DomainWideDelegation.id 1:N · SET NULL |
CreateTable
reassignById — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan Booking to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to Booking 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.userId — Booking.userId 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.eventTypeId — Booking.eventTypeId may be NULL, so the relationship to EventType is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.destinationCalendarId — Booking.destinationCalendarId may be NULL, so the relationship to DestinationCalendar is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.reassignById — Booking.reassignById 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.userId, eventTypeId, destinationCalendarId, reassignById — Booking has several nullable FKs (userId, eventTypeId, destinationCalendarId, reassignById) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.startTime — startTime stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.endTime — endTime stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 | serial | NOT NULL | |||
uid | text | NOT NULL | |||
idempotencyKey | text | null | |||
userId | integer | null | users.id 1:N · CASCADE | ||
userPrimaryEmail | text | null | |||
eventTypeId | integer | null | EventType.id 1:N · SET NULL | ||
title | text | NOT NULL | |||
description | text | null | |||
customInputs | jsonb | null | |||
responses | jsonb | null | |||
startTime | timestamp(3) | NOT NULL | |||
endTime | timestamp(3) | NOT NULL | |||
location | text | null | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | null | |||
status | BookingStatus | NOT NULL | 'accepted' | ||
paid | boolean | NOT NULL | FALSE | ||
destinationCalendarId | integer | null | DestinationCalendar.id 1:N · SET NULL | ||
cancellationReason | text | null | |||
rejectionReason | text | null | |||
reassignReason | text | null | |||
reassignById | integer | null | users.id 1:N · SET NULL | ||
dynamicEventSlugRef | text | null | |||
dynamicGroupSlugRef | text | null | |||
rescheduled | boolean | null | |||
fromReschedule | text | null | |||
recurringEventId | text | null | |||
smsReminderNumber | text | null | |||
scheduledJobs | text[] | null | |||
metadata | jsonb | null | |||
isRecorded | boolean | NOT NULL | FALSE | ||
iCalUID | text | null | '' | ||
iCalSequence | integer | NOT NULL | 0 | ||
rating | integer | null | |||
ratingFeedback | text | null | |||
noShowHost | boolean | null | FALSE | ||
oneTimePassword | text | null | |||
cancelledBy | text | null | |||
rescheduledBy | text | null | |||
creationSource | CreationSource | null |
CreateTable
| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | serial | NOT NULL | |||
referenceUid | text | NOT NULL | |||
bookingId | integer | NOT NULL | Booking.id 1:N · CASCADE | ||
attendeeId | integer | NOT NULL | Attendee.id 1:1 · CASCADE | ||
data | jsonb | null | |||
metadata | jsonb | null |
CreateTable
startTime — startTime stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.endTime — endTime stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.BookingDenormalized 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 | |||
uid | text | NOT NULL | |||
eventTypeId | integer | null | |||
title | text | NOT NULL | |||
description | text | null | |||
startTime | timestamp(3) | NOT NULL | |||
endTime | timestamp(3) | NOT NULL | |||
createdAt | timestamp(3) | NOT NULL | |||
updatedAt | timestamp(3) | null | |||
location | text | null | |||
paid | boolean | NOT NULL | |||
status | BookingStatus | NOT NULL | |||
rescheduled | boolean | null | |||
userId | integer | null | |||
teamId | integer | null | |||
eventLength | integer | null | |||
eventParentId | integer | null | |||
userEmail | text | null | |||
userName | text | null | |||
userUsername | text | null | |||
ratingFeedback | text | null | |||
rating | integer | null | |||
noShowHost | boolean | null | |||
isTeamBooking | boolean | NOT NULL |
CreateTable
reportedById — BookingReport.reportedById 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.organizationId — BookingReport.organizationId may be NULL, so the relationship to Team is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.watchlistId — BookingReport.watchlistId may be NULL, so the relationship to Watchlist is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.globalWatchlistId — BookingReport.globalWatchlistId may be NULL, so the relationship to Watchlist is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.reportedById, organizationId, watchlistId, globalWatchlistId — BookingReport has several nullable FKs (reportedById, organizationId, watchlistId, globalWatchlistId) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 | uuid | NOT NULL | |||
bookingUid | text | NOT NULL | Booking.uid 1:1 · CASCADE | ||
bookerEmail | text | NOT NULL | |||
reportedById | integer | null | users.id 1:N · SET NULL | ||
organizationId | integer | null | Team.id 1:N · CASCADE | ||
reason | BookingReportReason | NOT NULL | |||
description | text | null | |||
cancelled | boolean | NOT NULL | FALSE | ||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | NOT NULL | |||
status | BookingReportStatus | NOT NULL | 'PENDING' | ||
systemStatus | SystemReportStatus | NOT NULL | 'PENDING' | ||
watchlistId | uuid | null | Watchlist.id 1:N · SET NULL | ||
globalWatchlistId | uuid | null | Watchlist.id 1:N · SET NULL |
CreateTable
notePresetId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on InternalNotePreset must scan BookingInternalNote to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to BookingInternalNote maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often InternalNotePreset rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.createdById — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan BookingInternalNote to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to BookingInternalNote 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.notePresetId — BookingInternalNote.notePresetId may be NULL, so the relationship to InternalNotePreset is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.createdAt — createdAt 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 | serial | NOT NULL | |||
notePresetId | integer | null | InternalNotePreset.id 1:N · CASCADE | ||
text | text | null | |||
bookingId | integer | NOT NULL | Booking.id 1:N · CASCADE | ||
createdById | integer | NOT NULL | users.id 1:N · RESTRICT | ||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP |
CreateTable
timestamp — timestamp stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 | uuid | NOT NULL | |||
bookingUid | text | NOT NULL | |||
actorId | uuid | NOT NULL | AuditActor.id 1:N · RESTRICT | ||
type | BookingAuditType | NOT NULL | |||
action | BookingAuditAction | NOT NULL | |||
timestamp | timestamp(3) | NOT NULL | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | NOT NULL | |||
source | BookingAuditSource | NOT NULL | |||
operationId | text | NOT NULL | |||
data | jsonb | null | |||
context | jsonb | null |
Tables whose names start with Selected_.
SelectedCalendar.userId → users.id — one users, many SelectedCalendar · required · ON DELETE CASCADE · indexedSelectedCalendar.credentialId → Credential.id — one Credential, many SelectedCalendar · optional · ON DELETE CASCADE · indexedSelectedCalendar.delegationCredentialId → DelegationCredential.id — one DelegationCredential, many SelectedCalendar · optional · ON DELETE CASCADE · not indexedSelectedCalendar.domainWideDelegationCredentialId → DomainWideDelegation.id — one DomainWideDelegation, many SelectedCalendar · optional · ON DELETE CASCADE · not indexedSelectedCalendar.eventTypeId → EventType.id — one EventType, many SelectedCalendar · optional · ON DELETE SET NULL · indexedCreateTable
delegationCredentialId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on DelegationCredential must scan SelectedCalendar to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to SelectedCalendar maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often DelegationCredential rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.domainWideDelegationCredentialId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on DomainWideDelegation must scan SelectedCalendar to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to SelectedCalendar maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often DomainWideDelegation rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.credentialId — SelectedCalendar.credentialId may be NULL, so the relationship to Credential is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.delegationCredentialId — SelectedCalendar.delegationCredentialId may be NULL, so the relationship to DelegationCredential is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.domainWideDelegationCredentialId — SelectedCalendar.domainWideDelegationCredentialId may be NULL, so the relationship to DomainWideDelegation is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.eventTypeId — SelectedCalendar.eventTypeId may be NULL, so the relationship to EventType is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.credentialId, delegationCredentialId, domainWideDelegationCredentialId, eventTypeId — SelectedCalendar has several nullable FKs (credentialId, delegationCredentialId, domainWideDelegationCredentialId, eventTypeId) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.channelExpiration — channelExpiration stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.syncSubscribedAt — syncSubscribedAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.syncSubscribedErrorAt — syncSubscribedErrorAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.syncedAt — syncedAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.syncErrorAt — syncErrorAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.lastErrorAt — lastErrorAt 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 | text | NOT NULL | |||
userId | integer | NOT NULL | users.id 1:N · CASCADE | ||
integration | text | NOT NULL | |||
externalId | text | NOT NULL | |||
credentialId | integer | null | Credential.id 1:N · CASCADE | ||
createdAt | timestamp(3) | null | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | null | |||
googleChannelId | text | null | |||
googleChannelKind | text | null | |||
googleChannelResourceId | text | null | |||
googleChannelResourceUri | text | null | |||
googleChannelExpiration | text | null | |||
channelId | text | null | |||
channelKind | text | null | |||
channelResourceId | text | null | |||
channelResourceUri | text | null | |||
channelExpiration | timestamp(3) | null | |||
syncSubscribedAt | timestamp(3) | null | |||
syncSubscribedErrorAt | timestamp(3) | null | |||
syncSubscribedErrorCount | integer | NOT NULL | 0 | ||
syncToken | text | null | |||
syncedAt | timestamp(3) | null | |||
syncErrorAt | timestamp(3) | null | |||
syncErrorCount | integer | null | 0 | ||
delegationCredentialId | text | null | DelegationCredential.id 1:N · CASCADE | ||
domainWideDelegationCredentialId | text | null | DomainWideDelegation.id 1:N · CASCADE | ||
error | text | null | |||
lastErrorAt | timestamp(3) | null | |||
watchAttempts | integer | NOT NULL | 0 | ||
unwatchAttempts | integer | NOT NULL | 0 | ||
maxAttempts | integer | NOT NULL | 3 | ||
eventTypeId | integer | null | EventType.id 1:N · SET NULL |
CreateTable
slotUtcStartDate — slotUtcStartDate stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.slotUtcEndDate — slotUtcEndDate stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.releaseAt — releaseAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.SelectedSlots 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 | serial | NOT NULL | |||
eventTypeId | integer | NOT NULL | |||
userId | integer | NOT NULL | |||
slotUtcStartDate | timestamp(3) | NOT NULL | |||
slotUtcEndDate | timestamp(3) | NOT NULL | |||
uid | text | NOT NULL | |||
releaseAt | timestamp(3) | NOT NULL | |||
isSeat | boolean | NOT NULL | FALSE |
Tables whose names start with Webhook_.
Webhook.userId → users.id — one users, many Webhook · optional · ON DELETE CASCADE · indexedWebhook.teamId → Team.id — one Team, many Webhook · optional · ON DELETE CASCADE · not indexedWebhook.eventTypeId → EventType.id — one EventType, many Webhook · optional · ON DELETE CASCADE · not indexedWebhook.platformOAuthClientId → PlatformOAuthClient.id — one PlatformOAuthClient, many Webhook · optional · ON DELETE CASCADE · indexedWebhook.appId → App.slug — one App, many Webhook · optional · ON DELETE CASCADE · not indexedWebhookScheduledTriggers.webhookId → Webhook.id — one Webhook, many WebhookScheduledTriggers · optional · ON DELETE CASCADE · not indexedWebhookScheduledTriggers.bookingId → Booking.id — one Booking, many WebhookScheduledTriggers · optional · ON DELETE CASCADE · not indexedCreateTable
teamId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on Team must scan Webhook to check the constraint, and every join from the parent side is a sequential scan. 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 maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often Team rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.eventTypeId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on EventType must scan Webhook to check the constraint, and every join from the parent side is a sequential scan. 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 maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often EventType rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.appId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on App must scan Webhook to check the constraint, and every join from the parent side is a sequential scan. 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 maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often App rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.userId — Webhook.userId 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.teamId — Webhook.teamId may be NULL, so the relationship to Team is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.eventTypeId — Webhook.eventTypeId may be NULL, so the relationship to EventType is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.platformOAuthClientId — Webhook.platformOAuthClientId may be NULL, so the relationship to PlatformOAuthClient is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.appId — Webhook.appId may be NULL, so the relationship to App is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.userId, teamId, eventTypeId, platformOAuthClientId, appId — Webhook has several nullable FKs (userId, teamId, eventTypeId, platformOAuthClientId, appId) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.createdAt — createdAt 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 | text | NOT NULL | |||
userId | integer | null | users.id 1:N · CASCADE | ||
teamId | integer | null | Team.id 1:N · CASCADE | ||
eventTypeId | integer | null | EventType.id 1:N · CASCADE | ||
platformOAuthClientId | text | null | PlatformOAuthClient.id 1:N · CASCADE | ||
subscriberUrl | text | NOT NULL | |||
payloadTemplate | text | null | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
active | boolean | NOT NULL | TRUE | ||
eventTriggers | WebhookTriggerEvents[] | null | |||
appId | text | null | App.slug 1:N · CASCADE | ||
secret | text | null | |||
platform | boolean | NOT NULL | FALSE | ||
time | integer | null | |||
timeUnit | TimeUnit | null | |||
version | text | NOT NULL | '2021-10-20' |
CreateTable
webhookId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on Webhook must scan WebhookScheduledTriggers to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to WebhookScheduledTriggers maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often Webhook rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.bookingId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on Booking must scan WebhookScheduledTriggers to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to WebhookScheduledTriggers maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often Booking rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.webhookId — WebhookScheduledTriggers.webhookId may be NULL, so the relationship to Webhook is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.bookingId — WebhookScheduledTriggers.bookingId may be NULL, so the relationship to Booking is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.webhookId, bookingId — WebhookScheduledTriggers has several nullable FKs (webhookId, bookingId) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.startAfter — startAfter stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.createdAt — createdAt 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 | serial | NOT NULL | |||
jobName | text | null | |||
subscriberUrl | text | NOT NULL | |||
payload | text | NOT NULL | |||
startAfter | timestamp(3) | NOT NULL | |||
retryCount | integer | NOT NULL | 0 | ||
createdAt | timestamp(3) | null | CURRENT_TIMESTAMP | ||
appId | text | null | |||
webhookId | text | null | Webhook.id 1:N · CASCADE | ||
bookingId | integer | null | Booking.id 1:N · CASCADE |
Tables whose names start with App_.
App_RoutingForms_Form.userId → users.id — one users, many App_RoutingForms_Form · required · ON DELETE CASCADE · indexedApp_RoutingForms_Form.updatedById → users.id — one users, many App_RoutingForms_Form · optional · ON DELETE SET NULL · not indexedApp_RoutingForms_Form.teamId → Team.id — one Team, many App_RoutingForms_Form · optional · ON DELETE CASCADE · not indexedApp_RoutingForms_FormResponse.formId → App_RoutingForms_Form.id — one App_RoutingForms_Form, many App_RoutingForms_FormResponse · required · ON DELETE CASCADE · indexedApp_RoutingForms_FormResponse.routedToBookingUid → Booking.uid — one Booking, at most one App_RoutingForms_FormResponse · optional · ON DELETE SET NULL · indexedApp_RoutingForms_QueuedFormResponse.formId → App_RoutingForms_Form.id — one App_RoutingForms_Form, many App_RoutingForms_QueuedFormResponse · required · ON DELETE CASCADE · not indexedApp_RoutingForms_QueuedFormResponse.actualResponseId → App_RoutingForms_FormResponse.id — one App_RoutingForms_FormResponse, at most one App_RoutingForms_QueuedFormResponse · optional · ON DELETE CASCADE · indexedApp_RoutingForms_IncompleteBookingActions.formId → App_RoutingForms_Form.id — one App_RoutingForms_Form, many App_RoutingForms_IncompleteBookingActions · required · ON DELETE CASCADE · not indexedCreateTable
createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 |
|---|---|---|---|---|---|
slug PK | text | NOT NULL | |||
dirName | text | NOT NULL | |||
keys | jsonb | null | |||
categories | AppCategories[] | null | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | NOT NULL | |||
enabled | boolean | NOT NULL | FALSE |
CreateTable
updatedById — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan App_RoutingForms_Form to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to App_RoutingForms_Form 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.teamId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on Team must scan App_RoutingForms_Form to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to App_RoutingForms_Form maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often Team rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.updatedById — App_RoutingForms_Form.updatedById 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.teamId — App_RoutingForms_Form.teamId may be NULL, so the relationship to Team is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.updatedById, teamId — App_RoutingForms_Form has several nullable FKs (updatedById, teamId) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 | text | NOT NULL | |||
description | text | null | |||
position | integer | NOT NULL | 0 | ||
routes | jsonb | null | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | NOT NULL | |||
name | text | NOT NULL | |||
fields | jsonb | null | |||
updatedById | integer | null | users.id 1:N · SET NULL | ||
userId | integer | NOT NULL | users.id 1:N · CASCADE | ||
teamId | integer | null | Team.id 1:N · CASCADE | ||
disabled | boolean | NOT NULL | FALSE | ||
settings | jsonb | null |
CreateTable
routedToBookingUid — App_RoutingForms_FormResponse.routedToBookingUid may be NULL, so the relationship to Booking is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 | serial | NOT NULL | |||
uuid | text | null | |||
formFillerId | text | NOT NULL | |||
formId | text | NOT NULL | App_RoutingForms_Form.id 1:N · CASCADE | ||
response | jsonb | NOT NULL | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | null | |||
routedToBookingUid | text | null | Booking.uid 1:1 · SET NULL | ||
chosenRouteId | text | null |
CreateTable
formId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on App_RoutingForms_Form must scan App_RoutingForms_QueuedFormResponse to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to App_RoutingForms_QueuedFormResponse maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often App_RoutingForms_Form rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.actualResponseId — App_RoutingForms_QueuedFormResponse.actualResponseId may be NULL, so the relationship to App_RoutingForms_FormResponse is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 | text | NOT NULL | |||
formId | text | NOT NULL | App_RoutingForms_Form.id 1:N · CASCADE | ||
response | jsonb | NOT NULL | |||
chosenRouteId | text | null | |||
fallbackAction | jsonb | null | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | null | |||
actualResponseId | integer | null | App_RoutingForms_FormResponse.id 1:1 · CASCADE |
CreateTable
formId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on App_RoutingForms_Form must scan App_RoutingForms_IncompleteBookingActions to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to App_RoutingForms_IncompleteBookingActions maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often App_RoutingForms_Form rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | serial | NOT NULL | |||
formId | text | NOT NULL | App_RoutingForms_Form.id 1:N · CASCADE | ||
actionType | IncompleteBookingActionType | NOT NULL | |||
data | jsonb | NOT NULL | |||
enabled | boolean | NOT NULL | TRUE | ||
credentialId | integer | null |
Tables whose names start with Routing_.
RoutingFormResponseField.responseId → App_RoutingForms_FormResponse.id — one App_RoutingForms_FormResponse, many RoutingFormResponseField · required · ON DELETE CASCADE · indexedRoutingFormResponseField.responseId → RoutingFormResponseDenormalized.id — one RoutingFormResponseDenormalized, many RoutingFormResponseField · required · ON DELETE CASCADE · indexedRoutingFormResponseDenormalized.bookingId → Booking.id — one Booking, many RoutingFormResponseDenormalized · optional · ON DELETE SET NULL · indexedRoutingFormResponseDenormalized.id → App_RoutingForms_FormResponse.id — one App_RoutingForms_FormResponse, at most one RoutingFormResponseDenormalized · required · ON DELETE CASCADE · indexedRoutingTrace.formResponseId → App_RoutingForms_FormResponse.id — one App_RoutingForms_FormResponse, at most one RoutingTrace · optional · ON DELETE CASCADE · indexedRoutingTrace.queuedFormResponseId → App_RoutingForms_QueuedFormResponse.id — one App_RoutingForms_QueuedFormResponse, at most one RoutingTrace · optional · ON DELETE CASCADE · indexedRoutingTrace.bookingUid → Booking.uid — one Booking, at most one RoutingTrace · optional · ON DELETE CASCADE · indexedRoutingTrace.assignmentReasonId → AssignmentReason.id — one AssignmentReason, at most one RoutingTrace · optional · ON DELETE CASCADE · indexedCreateTable
| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | serial | NOT NULL | |||
responseId | integer | NOT NULL | RoutingFormResponseDenormalized.id 1:N · CASCADE | ||
fieldId | text | NOT NULL | |||
valueString | text | null | |||
valueNumber | numeric(65, 30) | null | |||
valueStringArray | text[] | null |
CreateTable
bookingId — RoutingFormResponseDenormalized.bookingId may be NULL, so the relationship to Booking is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.bookingCreatedAt — bookingCreatedAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.bookingStartTime — bookingStartTime stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.bookingEndTime — bookingEndTime stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.createdAt — createdAt 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 | App_RoutingForms_FormResponse.id 1:1 · CASCADE | ||
uuid | text | null | |||
formId | text | NOT NULL | |||
formName | text | NOT NULL | |||
formTeamId | integer | null | |||
formUserId | integer | NOT NULL | |||
bookingUid | text | null | |||
bookingId | integer | null | Booking.id 1:N · SET NULL | ||
bookingStatus | BookingStatus | null | |||
bookingStatusOrder | integer | null | |||
bookingCreatedAt | timestamp(3) | null | |||
bookingStartTime | timestamp(3) | null | |||
bookingEndTime | timestamp(3) | null | |||
bookingUserId | integer | null | |||
bookingUserName | text | null | |||
bookingUserEmail | text | null | |||
bookingUserAvatarUrl | text | null | |||
bookingAssignmentReason | text | null | |||
eventTypeId | integer | null | |||
eventTypeParentId | integer | null | |||
eventTypeSchedulingType | text | null | |||
createdAt | timestamp(3) | NOT NULL | |||
utm_source | text | null | |||
utm_medium | text | null | |||
utm_campaign | text | null | |||
utm_term | text | null | |||
utm_content | text | null |
CreateTable
formResponseId — RoutingTrace.formResponseId may be NULL, so the relationship to App_RoutingForms_FormResponse is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.queuedFormResponseId — RoutingTrace.queuedFormResponseId may be NULL, so the relationship to App_RoutingForms_QueuedFormResponse is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.bookingUid — RoutingTrace.bookingUid may be NULL, so the relationship to Booking is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.assignmentReasonId — RoutingTrace.assignmentReasonId may be NULL, so the relationship to AssignmentReason is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.formResponseId, queuedFormResponseId, bookingUid, assignmentReasonId — RoutingTrace has several nullable FKs (formResponseId, queuedFormResponseId, bookingUid, assignmentReasonId) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.createdAt — createdAt 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 | text | NOT NULL | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
trace | jsonb | NOT NULL | |||
formResponseId | integer | null | App_RoutingForms_FormResponse.id 1:1 · CASCADE | ||
queuedFormResponseId | text | null | App_RoutingForms_QueuedFormResponse.id 1:1 · CASCADE | ||
bookingUid | text | null | Booking.uid 1:1 · CASCADE | ||
assignmentReasonId | integer | null | AssignmentReason.id 1:1 · CASCADE |
Tables whose names start with Workflow_.
WorkflowStep.workflowId → Workflow.id — one Workflow, many WorkflowStep · required · ON DELETE CASCADE · indexedWorkflowStep.agentId → Agent.id — one Agent, at most one WorkflowStep · optional · ON DELETE SET NULL · indexedWorkflowStep.inboundAgentId → Agent.id — one Agent, at most one WorkflowStep · optional · ON DELETE SET NULL · indexedWorkflow.userId → users.id — one users, many Workflow · optional · ON DELETE CASCADE · indexedWorkflow.teamId → Team.id — one Team, many Workflow · optional · ON DELETE CASCADE · indexedWorkflowReminder.bookingUid → Booking.uid — one Booking, many WorkflowReminder · optional · ON DELETE SET NULL · indexedWorkflowReminder.workflowStepId → WorkflowStep.id — one WorkflowStep, many WorkflowReminder · optional · ON DELETE CASCADE · indexedWorkflowStepTranslation.workflowStepId → WorkflowStep.id — one WorkflowStep, many WorkflowStepTranslation · required · ON DELETE CASCADE · indexedCreateTable
agentId — WorkflowStep.agentId may be NULL, so the relationship to Agent is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.inboundAgentId — WorkflowStep.inboundAgentId may be NULL, so the relationship to Agent is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.agentId, inboundAgentId — WorkflowStep has several nullable FKs (agentId, inboundAgentId) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.verifiedAt — verifiedAt 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 | serial | NOT NULL | |||
stepNumber | integer | NOT NULL | |||
action | WorkflowActions | NOT NULL | |||
workflowId | integer | NOT NULL | Workflow.id 1:N · CASCADE | ||
sendTo | text | null | |||
reminderBody | text | null | |||
emailSubject | text | null | |||
template | WorkflowTemplates | NOT NULL | 'REMINDER' | ||
numberRequired | boolean | null | |||
sender | text | null | |||
numberVerificationPending | boolean | NOT NULL | TRUE | ||
includeCalendarEvent | boolean | NOT NULL | FALSE | ||
verifiedAt | timestamp(3) | null | |||
agentId | text | null | Agent.id 1:1 · SET NULL | ||
inboundAgentId | text | null | Agent.id 1:1 · SET NULL | ||
autoTranslateEnabled | boolean | NOT NULL | FALSE | ||
sourceLocale | text | null |
CreateTable
userId — Workflow.userId 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.teamId — Workflow.teamId may be NULL, so the relationship to Team is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.userId, teamId — Workflow has several nullable FKs (userId, teamId) 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 | serial | NOT NULL | |||
position | integer | NOT NULL | 0 | ||
name | text | NOT NULL | |||
userId | integer | null | users.id 1:N · CASCADE | ||
teamId | integer | null | Team.id 1:N · CASCADE | ||
isActiveOnAll | boolean | NOT NULL | FALSE | ||
trigger | WorkflowTriggerEvents | NOT NULL | |||
time | integer | null | |||
timeUnit | TimeUnit | null | |||
type | WorkflowType | NOT NULL | 'EVENT_TYPE' |
CreateTable
bookingUid — WorkflowReminder.bookingUid may be NULL, so the relationship to Booking is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.workflowStepId — WorkflowReminder.workflowStepId may be NULL, so the relationship to WorkflowStep is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.bookingUid, workflowStepId — WorkflowReminder has several nullable FKs (bookingUid, workflowStepId) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.scheduledDate — scheduledDate 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 | serial | NOT NULL | |||
uuid | text | null | |||
bookingUid | text | null | Booking.uid 1:N · SET NULL | ||
method | WorkflowMethods | NOT NULL | |||
scheduledDate | timestamp(3) | NOT NULL | |||
referenceId | text | null | |||
scheduled | boolean | NOT NULL | |||
workflowStepId | integer | null | WorkflowStep.id 1:N · CASCADE | ||
cancelled | boolean | null | |||
seatReferenceId | text | null | |||
isMandatoryReminder | boolean | null | FALSE | ||
retryCount | integer | NOT NULL | 0 |
CreateTable
createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 |
|---|---|---|---|---|---|
uid PK | text | NOT NULL | |||
workflowStepId | integer | NOT NULL | WorkflowStep.id 1:N · CASCADE | ||
field | WorkflowStepAutoTranslatedField | NOT NULL | |||
sourceLocale | text | NOT NULL | |||
targetLocale | text | NOT NULL | |||
translatedText | text | NOT NULL | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | NOT NULL |
CreateTable
createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.WorkflowOptOutContact 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 | serial | NOT NULL | |||
type | WorkflowContactType | NOT NULL | |||
value | text | NOT NULL | |||
optedOut | boolean | NOT NULL | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | NOT NULL |
Tables whose names start with Workflows_.
WorkflowsOnEventTypes.workflowId → Workflow.id — one Workflow, many WorkflowsOnEventTypes · required · ON DELETE CASCADE · indexedWorkflowsOnEventTypes.eventTypeId → EventType.id — one EventType, many WorkflowsOnEventTypes · required · ON DELETE CASCADE · indexedWorkflowsOnRoutingForms.workflowId → Workflow.id — one Workflow, many WorkflowsOnRoutingForms · required · ON DELETE CASCADE · indexedWorkflowsOnRoutingForms.routingFormId → App_RoutingForms_Form.id — one App_RoutingForms_Form, many WorkflowsOnRoutingForms · required · ON DELETE CASCADE · indexedWorkflowsOnTeams.workflowId → Workflow.id — one Workflow, many WorkflowsOnTeams · required · ON DELETE CASCADE · indexedWorkflowsOnTeams.teamId → Team.id — one Team, many WorkflowsOnTeams · required · ON DELETE CASCADE · indexedCreateTable
| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | serial | NOT NULL | |||
workflowId | integer | NOT NULL | Workflow.id 1:N · CASCADE | ||
eventTypeId | integer | NOT NULL | EventType.id 1:N · CASCADE |
CreateTable
| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | serial | NOT NULL | |||
workflowId | integer | NOT NULL | Workflow.id 1:N · CASCADE | ||
routingFormId | text | NOT NULL | App_RoutingForms_Form.id 1:N · CASCADE |
CreateTable
| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | serial | NOT NULL | |||
workflowId | integer | NOT NULL | Workflow.id 1:N · CASCADE | ||
teamId | integer | NOT NULL | Team.id 1:N · CASCADE |
Tables whose names start with Verified_.
VerifiedNumber.userId → users.id — one users, many VerifiedNumber · optional · ON DELETE CASCADE · indexedVerifiedNumber.teamId → Team.id — one Team, many VerifiedNumber · optional · ON DELETE CASCADE · indexedVerifiedEmail.userId → users.id — one users, many VerifiedEmail · optional · ON DELETE CASCADE · indexedVerifiedEmail.teamId → Team.id — one Team, many VerifiedEmail · optional · ON DELETE CASCADE · indexedCreateTable
userId — VerifiedNumber.userId 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.teamId — VerifiedNumber.teamId may be NULL, so the relationship to Team is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.userId, teamId — VerifiedNumber has several nullable FKs (userId, teamId) 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 | serial | NOT NULL | |||
userId | integer | null | users.id 1:N · CASCADE | ||
teamId | integer | null | Team.id 1:N · CASCADE | ||
phoneNumber | text | NOT NULL |
CreateTable
userId — VerifiedEmail.userId 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.teamId — VerifiedEmail.teamId may be NULL, so the relationship to Team is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.userId, teamId — VerifiedEmail has several nullable FKs (userId, teamId) 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 | serial | NOT NULL | |||
userId | integer | null | users.id 1:N · CASCADE | ||
teamId | integer | null | Team.id 1:N · CASCADE | ||
email | text | NOT NULL |
Tables whose names start with Access_.
AccessCode.clientId → OAuthClient.clientId — one OAuthClient, many AccessCode · optional · ON DELETE CASCADE · not indexedAccessCode.userId → users.id — one users, many AccessCode · optional · ON DELETE CASCADE · not indexedAccessCode.teamId → Team.id — one Team, many AccessCode · optional · ON DELETE CASCADE · not indexedAccessToken.userId → users.id — one users, many AccessToken · required · ON DELETE CASCADE · not indexedAccessToken.platformOAuthClientId → PlatformOAuthClient.id — one PlatformOAuthClient, many AccessToken · required · ON DELETE CASCADE · not indexedCreateTable
clientId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on OAuthClient must scan AccessCode to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to AccessCode maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often OAuthClient rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.userId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan AccessCode to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to AccessCode 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.teamId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on Team must scan AccessCode to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to AccessCode maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often Team rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.clientId — AccessCode.clientId may be NULL, so the relationship to OAuthClient is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.userId — AccessCode.userId 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.teamId — AccessCode.teamId may be NULL, so the relationship to Team is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.clientId, userId, teamId — AccessCode has several nullable FKs (clientId, userId, teamId) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.expiresAt — expiresAt 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 | serial | NOT NULL | |||
code | text | NOT NULL | |||
clientId | text | null | OAuthClient.clientId 1:N · CASCADE | ||
expiresAt | timestamp(3) | NOT NULL | |||
scopes | AccessScope[] | null | |||
userId | integer | null | users.id 1:N · CASCADE | ||
teamId | integer | null | Team.id 1:N · CASCADE | ||
codeChallenge | text | null | |||
codeChallengeMethod | text | null | 'S256' |
CreateTable
userId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan AccessToken to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to AccessToken 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.platformOAuthClientId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on PlatformOAuthClient must scan AccessToken to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to AccessToken maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often PlatformOAuthClient rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.expiresAt — expiresAt 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 | serial | NOT NULL | |||
secret | text | NOT NULL | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
expiresAt | timestamp(3) | NOT NULL | |||
platformOAuthClientId | text | NOT NULL | PlatformOAuthClient.id 1:N · CASCADE | ||
userId | integer | NOT NULL | users.id 1:N · CASCADE |
Tables whose names start with Calendar_.
CalendarCache.credentialId → Credential.id — one Credential, many CalendarCache · required · ON DELETE CASCADE · indexedCalendarCacheEvent.selectedCalendarId → SelectedCalendar.id — one SelectedCalendar, many CalendarCacheEvent · required · ON DELETE CASCADE · indexedCreateTable
expiresAt — expiresAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 | text | null | |||
key PK | text | NOT NULL | |||
value | jsonb | NOT NULL | |||
expiresAt | timestamp(3) | NOT NULL | |||
updatedAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
credentialId PK | integer | NOT NULL | Credential.id 1:N · CASCADE | ||
userId | integer | null |
CreateTable
start — start stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.end — end stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.originalStartTime — originalStartTime stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.externalCreatedAt — externalCreatedAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.externalUpdatedAt — externalUpdatedAt 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 | text | NOT NULL | |||
selectedCalendarId | text | NOT NULL | SelectedCalendar.id 1:N · CASCADE | ||
externalId | text | NOT NULL | |||
externalEtag | text | NOT NULL | |||
iCalUID | text | null | |||
iCalSequence | integer | NOT NULL | 0 | ||
summary | text | null | |||
description | text | null | |||
location | text | null | |||
start | timestamp(3) | NOT NULL | |||
end | timestamp(3) | NOT NULL | |||
isAllDay | boolean | NOT NULL | FALSE | ||
timeZone | text | null | |||
status | CalendarCacheEventStatus | NOT NULL | 'confirmed' | ||
recurringEventId | text | null | |||
originalStartTime | timestamp(3) | null | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | NOT NULL | |||
externalCreatedAt | timestamp(3) | null | |||
externalUpdatedAt | timestamp(3) | null |
Tables whose names start with Out_.
OutOfOfficeEntry.userId → users.id — one users, many OutOfOfficeEntry · required · ON DELETE CASCADE · indexedOutOfOfficeEntry.toUserId → users.id — one users, many OutOfOfficeEntry · optional · ON DELETE CASCADE · indexedOutOfOfficeEntry.reasonId → OutOfOfficeReason.id — one OutOfOfficeReason, many OutOfOfficeEntry · optional · ON DELETE SET NULL · not indexedOutOfOfficeReason.userId → users.id — one users, many OutOfOfficeReason · optional · ON DELETE CASCADE · not indexedCreateTable
reasonId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on OutOfOfficeReason must scan OutOfOfficeEntry to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to OutOfOfficeEntry maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often OutOfOfficeReason rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.toUserId — OutOfOfficeEntry.toUserId 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.reasonId — OutOfOfficeEntry.reasonId may be NULL, so the relationship to OutOfOfficeReason is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.toUserId, reasonId — OutOfOfficeEntry has several nullable FKs (toUserId, reasonId) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.start — start stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.end — end stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 | serial | NOT NULL | |||
uuid | text | NOT NULL | |||
start | timestamp(3) | NOT NULL | |||
end | timestamp(3) | NOT NULL | |||
notes | text | null | |||
showNotePublicly | boolean | NOT NULL | FALSE | ||
userId | integer | NOT NULL | users.id 1:N · CASCADE | ||
toUserId | integer | null | users.id 1:N · CASCADE | ||
reasonId | integer | null | OutOfOfficeReason.id 1:N · SET NULL | ||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | NOT NULL |
CreateTable
userId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan OutOfOfficeReason to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to OutOfOfficeReason 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.userId — OutOfOfficeReason.userId 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 | serial | NOT NULL | |||
emoji | text | NOT NULL | |||
reason | text | NOT NULL | |||
enabled | boolean | NOT NULL | TRUE | ||
userId | integer | null | users.id 1:N · CASCADE |
Tables whose names start with Platform_.
PlatformOAuthClient.organizationId → Team.id — one Team, many PlatformOAuthClient · required · ON DELETE CASCADE · not indexedPlatformAuthorizationToken.userId → users.id — one users, many PlatformAuthorizationToken · required · ON DELETE CASCADE · indexedPlatformAuthorizationToken.platformOAuthClientId → PlatformOAuthClient.id — one PlatformOAuthClient, many PlatformAuthorizationToken · required · ON DELETE CASCADE · not indexedPlatformBilling.managerBillingId → PlatformBilling.id — one PlatformBilling, many PlatformBilling · optional · ON DELETE SET NULL · not indexedPlatformBilling.id → Team.id — one Team, at most one PlatformBilling · required · ON DELETE CASCADE · indexed_PlatformOAuthClientToUser.A → PlatformOAuthClient.id — one PlatformOAuthClient, many _PlatformOAuthClientToUser · required · ON DELETE CASCADE · indexed_PlatformOAuthClientToUser.B → users.id — one users, many _PlatformOAuthClientToUser · required · ON DELETE CASCADE · indexedCreateTable
organizationId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on Team must scan PlatformOAuthClient to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to PlatformOAuthClient maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often Team rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.createdAt — createdAt 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 | text | NOT NULL | |||
name | text | NOT NULL | |||
secret | text | NOT NULL | |||
permissions | integer | NOT NULL | |||
logo | text | null | |||
redirectUris | text[] | null | |||
organizationId | integer | NOT NULL | Team.id 1:N · CASCADE | ||
bookingRedirectUri | text | null | |||
bookingCancelRedirectUri | text | null | |||
bookingRescheduleRedirectUri | text | null | |||
areEmailsEnabled | boolean | NOT NULL | FALSE | ||
areDefaultEventTypesEnabled | boolean | NOT NULL | TRUE | ||
areCalendarEventsEnabled | boolean | NOT NULL | TRUE | ||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP |
CreateTable
platformOAuthClientId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on PlatformOAuthClient must scan PlatformAuthorizationToken to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to PlatformAuthorizationToken maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often PlatformOAuthClient rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.createdAt — createdAt 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 | text | NOT NULL | |||
platformOAuthClientId | text | NOT NULL | PlatformOAuthClient.id 1:N · CASCADE | ||
userId | integer | NOT NULL | users.id 1:N · CASCADE | ||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP |
CreateTable
managerBillingId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on PlatformBilling must scan PlatformBilling to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to PlatformBilling maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often PlatformBilling rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.managerBillingId — PlatformBilling.managerBillingId may be NULL, so the relationship to PlatformBilling is optional. That is legitimate (e.g. 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 | Team.id 1:1 · CASCADE | ||
customerId | text | NOT NULL | |||
subscriptionId | text | null | |||
priceId | text | null | |||
plan | text | NOT NULL | 'none' | ||
billingCycleStart | integer | null | |||
billingCycleEnd | integer | null | |||
overdue | boolean | null | FALSE | ||
managerBillingId | integer | null | PlatformBilling.id 1:N · SET NULL |
CreateTable
| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
A PK | text | NOT NULL | PlatformOAuthClient.id 1:N · CASCADE | ||
B PK | integer | NOT NULL | users.id 1:N · CASCADE |
Tables whose names start with Attribute_.
AttributeOption.attributeId → Attribute.id — one Attribute, many AttributeOption · required · ON DELETE CASCADE · not indexedAttribute.teamId → Team.id — one Team, many Attribute · required · ON DELETE CASCADE · indexedAttributeToUser.memberId → Membership.id — one Membership, many AttributeToUser · required · ON DELETE CASCADE · indexedAttributeToUser.attributeOptionId → AttributeOption.id — one AttributeOption, many AttributeToUser · required · ON DELETE CASCADE · not indexedAttributeToUser.createdById → users.id — one users, many AttributeToUser · optional · ON DELETE SET NULL · not indexedAttributeToUser.createdByDSyncId → DSyncData.directoryId — one DSyncData, many AttributeToUser · optional · ON DELETE SET NULL · not indexedAttributeToUser.updatedById → users.id — one users, many AttributeToUser · optional · ON DELETE SET NULL · not indexedAttributeToUser.updatedByDSyncId → DSyncData.directoryId — one DSyncData, many AttributeToUser · optional · ON DELETE SET NULL · not indexedAttributeSyncRule.integrationAttributeSyncId → IntegrationAttributeSync.id — one IntegrationAttributeSync, at most one AttributeSyncRule · required · ON DELETE CASCADE · indexedAttributeSyncFieldMapping.attributeId → Attribute.id — one Attribute, many AttributeSyncFieldMapping · required · ON DELETE CASCADE · not indexedAttributeSyncFieldMapping.integrationAttributeSyncId → IntegrationAttributeSync.id — one IntegrationAttributeSync, many AttributeSyncFieldMapping · required · ON DELETE CASCADE · indexedCreateTable
attributeId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on Attribute must scan AttributeOption to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to AttributeOption maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often Attribute rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | text | NOT NULL | |||
attributeId | text | NOT NULL | Attribute.id 1:N · CASCADE | ||
value | text | NOT NULL | |||
slug | text | NOT NULL | |||
isGroup | boolean | NOT NULL | FALSE | ||
contains | text[] | null |
CreateTable
createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 | text | NOT NULL | |||
teamId | integer | NOT NULL | Team.id 1:N · CASCADE | ||
type | AttributeType | NOT NULL | |||
name | text | NOT NULL | |||
slug | text | NOT NULL | |||
enabled | boolean | NOT NULL | TRUE | ||
usersCanEditRelation | boolean | NOT NULL | FALSE | ||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | NOT NULL | |||
isWeightsEnabled | boolean | NOT NULL | FALSE | ||
isLocked | boolean | NOT NULL | FALSE |
CreateTable
attributeOptionId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on AttributeOption must scan AttributeToUser to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to AttributeToUser maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often AttributeOption rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.createdById — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan AttributeToUser to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to AttributeToUser 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.createdByDSyncId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on DSyncData must scan AttributeToUser to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to AttributeToUser maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often DSyncData rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.updatedById — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan AttributeToUser to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to AttributeToUser 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.updatedByDSyncId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on DSyncData must scan AttributeToUser to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to AttributeToUser maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often DSyncData rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.createdById — AttributeToUser.createdById 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.createdByDSyncId — AttributeToUser.createdByDSyncId may be NULL, so the relationship to DSyncData is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.updatedById — AttributeToUser.updatedById 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.updatedByDSyncId — AttributeToUser.updatedByDSyncId may be NULL, so the relationship to DSyncData is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.createdById, createdByDSyncId, updatedById, updatedByDSyncId — AttributeToUser has several nullable FKs (createdById, createdByDSyncId, updatedById, updatedByDSyncId) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 | text | NOT NULL | |||
memberId | integer | NOT NULL | Membership.id 1:N · CASCADE | ||
attributeOptionId | text | NOT NULL | AttributeOption.id 1:N · CASCADE | ||
weight | integer | null | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
createdById | integer | null | users.id 1:N · SET NULL | ||
createdByDSyncId | text | null | DSyncData.directoryId 1:N · SET NULL | ||
updatedAt | timestamp(3) | null | |||
updatedById | integer | null | users.id 1:N · SET NULL | ||
updatedByDSyncId | text | null | DSyncData.directoryId 1:N · SET NULL |
CreateTable
createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 | text | NOT NULL | |||
integrationAttributeSyncId | text | NOT NULL | IntegrationAttributeSync.id 1:1 · CASCADE | ||
rule | jsonb | NOT NULL | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | NOT NULL |
CreateTable
attributeId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on Attribute must scan AttributeSyncFieldMapping to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to AttributeSyncFieldMapping maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often Attribute rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 | text | NOT NULL | |||
integrationFieldName | text | NOT NULL | |||
attributeId | text | NOT NULL | Attribute.id 1:N · CASCADE | ||
enabled | boolean | NOT NULL | |||
integrationAttributeSyncId | text | NOT NULL | IntegrationAttributeSync.id 1:N · CASCADE | ||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | NOT NULL |
Tables whose names start with Watchlist_.
WatchlistAudit.watchlistId → Watchlist.id — one Watchlist, many WatchlistAudit · optional · ON DELETE SET NULL · indexedCreateTable
lastUpdatedAt — lastUpdatedAt 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 | uuid | NOT NULL | |||
type | WatchlistType | NOT NULL | |||
value | text | NOT NULL | |||
description | text | null | |||
isGlobal | boolean | NOT NULL | FALSE | ||
organizationId | integer | null | |||
action | WatchlistAction | NOT NULL | 'REPORT' | ||
source | WatchlistSource | NOT NULL | 'MANUAL' | ||
lastUpdatedAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP |
CreateTable
watchlistId — WatchlistAudit.watchlistId may be NULL, so the relationship to Watchlist is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.changedAt — changedAt 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 | uuid | NOT NULL | |||
type | WatchlistType | NOT NULL | |||
value | text | NOT NULL | |||
description | text | null | |||
action | WatchlistAction | NOT NULL | 'REPORT' | ||
changedAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
changedByUserId | integer | null | |||
watchlistId | uuid | null | Watchlist.id 1:N · SET NULL |
CreateTable
timestamp — timestamp stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.WatchlistEventAudit 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 | uuid | NOT NULL | |||
watchlistId | uuid | NOT NULL | |||
eventTypeId | integer | NOT NULL | |||
actionTaken | WatchlistAction | NOT NULL | |||
timestamp | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP |
Tables whose names start with Role_.
Role.teamId → Team.id — one Team, many Role · optional · ON DELETE CASCADE · indexedRolePermission.roleId → Role.id — one Role, many RolePermission · required · ON DELETE CASCADE · indexedCreateTable
teamId — Role.teamId may be NULL, so the relationship to Team is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 | text | NOT NULL | |||
name | text | NOT NULL | |||
color | text | null | |||
description | text | null | |||
teamId | integer | null | Team.id 1:N · CASCADE | ||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | NOT NULL | |||
type | RoleType | NOT NULL | 'CUSTOM' |
CreateTable
createdAt — createdAt 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 | text | NOT NULL | |||
roleId | text | NOT NULL | Role.id 1:N · CASCADE | ||
resource | text | NOT NULL | |||
action | text | NOT NULL | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP |
Tables whose name prefix is theirs alone.
Credential.userId → users.id — one users, many Credential · optional · ON DELETE CASCADE · indexedCredential.teamId → Team.id — one Team, many Credential · optional · ON DELETE CASCADE · indexedCredential.appId → App.slug — one App, many Credential · optional · ON DELETE CASCADE · indexedCredential.delegationCredentialId → DelegationCredential.id — one DelegationCredential, many Credential · optional · ON DELETE CASCADE · not indexedDestinationCalendar.userId → users.id — one users, at most one DestinationCalendar · optional · ON DELETE CASCADE · indexedDestinationCalendar.eventTypeId → EventType.id — one EventType, at most one DestinationCalendar · optional · ON DELETE CASCADE · indexedDestinationCalendar.credentialId → Credential.id — one Credential, many DestinationCalendar · optional · ON DELETE CASCADE · indexedDestinationCalendar.delegationCredentialId → DelegationCredential.id — one DelegationCredential, many DestinationCalendar · optional · ON DELETE CASCADE · not indexedDestinationCalendar.domainWideDelegationCredentialId → DomainWideDelegation.id — one DomainWideDelegation, many DestinationCalendar · optional · ON DELETE CASCADE · not indexedTravelSchedule.userId → users.id — one users, many TravelSchedule · required · ON DELETE CASCADE · not indexedusers.organizationId → Team.id — one Team, many users · optional · ON DELETE SET NULL · not indexedusers.movedToProfileId → Profile.id — one Profile, at most one users · optional · ON DELETE SET NULL · indexedNotificationsSubscriptions.userId → users.id — one users, many NotificationsSubscriptions · required · ON DELETE CASCADE · indexedProfile.userId → users.id — one users, many Profile · required · ON DELETE CASCADE · indexedProfile.organizationId → Team.id — one Team, many Profile · required · ON DELETE CASCADE · indexedMembership.customRoleId → Role.id — one Role, many Membership · optional · ON DELETE SET NULL · indexedMembership.teamId → Team.id — one Team, many Membership · required · ON DELETE CASCADE · indexedMembership.userId → users.id — one users, many Membership · required · ON DELETE CASCADE · indexedVerificationToken.teamId → Team.id — one Team, many VerificationToken · optional · ON DELETE SET NULL · indexedVerificationToken.secondaryEmailId → SecondaryEmail.id — one SecondaryEmail, many VerificationToken · optional · ON DELETE SET NULL · indexedInstantMeetingToken.teamId → Team.id — one Team, many InstantMeetingToken · required · ON DELETE CASCADE · not indexedInstantMeetingToken.bookingId → Booking.id — one Booking, at most one InstantMeetingToken · optional · ON DELETE CASCADE · indexedAttendee.bookingId → Booking.id — one Booking, many Attendee · optional · ON DELETE CASCADE · indexedTracking.bookingId → Booking.id — one Booking, at most one Tracking · required · ON DELETE CASCADE · indexedSchedule.userId → users.id — one users, many Schedule · required · ON DELETE CASCADE · indexedAvailability.userId → users.id — one users, many Availability · optional · ON DELETE CASCADE · indexedAvailability.eventTypeId → EventType.id — one EventType, many Availability · optional · ON DELETE SET NULL · indexedAvailability.scheduleId → Schedule.id — one Schedule, many Availability · optional · ON DELETE SET NULL · indexedPayment.appId → App.slug — one App, many Payment · optional · ON DELETE CASCADE · not indexedPayment.bookingId → Booking.id — one Booking, many Payment · required · ON DELETE CASCADE · indexedImpersonations.impersonatedUserId → users.id — one users, many Impersonations · required · ON DELETE CASCADE · indexedImpersonations.impersonatedById → users.id — one users, many Impersonations · required · ON DELETE CASCADE · indexedApiKey.userId → users.id — one users, many ApiKey · required · ON DELETE CASCADE · indexedApiKey.teamId → Team.id — one Team, many ApiKey · optional · ON DELETE CASCADE · not indexedApiKey.appId → App.slug — one App, many ApiKey · optional · ON DELETE CASCADE · not indexedRateLimit.apiKeyId → ApiKey.id — one ApiKey, many RateLimit · required · ON DELETE CASCADE · indexedHashedLink.eventTypeId → EventType.id — one EventType, many HashedLink · required · ON DELETE CASCADE · indexedAccount.userId → users.id — one users, many Account · required · ON DELETE CASCADE · indexedSession.userId → users.id — one users, many Session · required · ON DELETE CASCADE · indexedFeedback.userId → users.id — one users, many Feedback · required · ON DELETE CASCADE · indexedAIPhoneCallConfiguration.eventTypeId → EventType.id — one EventType, at most one AIPhoneCallConfiguration · required · ON DELETE CASCADE · indexedOAuthClient.userId → users.id — one users, many OAuthClient · optional · ON DELETE SET NULL · indexedRefreshToken.userId → users.id — one users, many RefreshToken · required · ON DELETE CASCADE · not indexedRefreshToken.platformOAuthClientId → PlatformOAuthClient.id — one PlatformOAuthClient, many RefreshToken · required · ON DELETE CASCADE · not indexedDSyncData.organizationId → OrganizationSettings.organizationId — one OrganizationSettings, at most one DSyncData · optional · ON DELETE CASCADE · indexedDSyncTeamGroupMapping.teamId → Team.id — one Team, many DSyncTeamGroupMapping · required · ON DELETE CASCADE · indexedDSyncTeamGroupMapping.directoryId → DSyncData.directoryId — one DSyncData, many DSyncTeamGroupMapping · required · ON DELETE CASCADE · not indexedSecondaryEmail.userId → users.id — one users, many SecondaryEmail · required · ON DELETE CASCADE · indexedManagedOrganization.managedOrganizationId → Team.id — one Team, at most one ManagedOrganization · required · ON DELETE CASCADE · indexedManagedOrganization.managerOrganizationId → Team.id — one Team, many ManagedOrganization · required · ON DELETE CASCADE · indexedAssignmentReason.bookingId → Booking.id — one Booking, many AssignmentReason · required · ON DELETE CASCADE · indexedDelegationCredential.workspacePlatformId → WorkspacePlatform.id — one WorkspacePlatform, many DelegationCredential · required · ON DELETE CASCADE · not indexedDelegationCredential.organizationId → Team.id — one Team, many DelegationCredential · required · ON DELETE CASCADE · indexedDomainWideDelegation.workspacePlatformId → WorkspacePlatform.id — one WorkspacePlatform, many DomainWideDelegation · required · ON DELETE CASCADE · not indexedDomainWideDelegation.organizationId → Team.id — one Team, many DomainWideDelegation · required · ON DELETE CASCADE · indexedWrongAssignmentReport.bookingUid → Booking.uid — one Booking, at most one WrongAssignmentReport · required · ON DELETE CASCADE · indexedWrongAssignmentReport.reportedById → users.id — one users, many WrongAssignmentReport · optional · ON DELETE SET NULL · indexedWrongAssignmentReport.teamId → Team.id — one Team, many WrongAssignmentReport · optional · ON DELETE SET NULL · indexedWrongAssignmentReport.routingFormId → App_RoutingForms_Form.id — one App_RoutingForms_Form, many WrongAssignmentReport · optional · ON DELETE SET NULL · indexedWrongAssignmentReport.reviewedById → users.id — one users, many WrongAssignmentReport · optional · ON DELETE SET NULL · indexedInternalNotePreset.teamId → Team.id — one Team, many InternalNotePreset · required · ON DELETE CASCADE · indexedFilterSegment.userId → users.id — one users, many FilterSegment · required · ON DELETE CASCADE · not indexedFilterSegment.teamId → Team.id — one Team, many FilterSegment · optional · ON DELETE CASCADE · not indexedAgent.userId → users.id — one users, many Agent · optional · ON DELETE CASCADE · indexedAgent.teamId → Team.id — one Team, many Agent · optional · ON DELETE CASCADE · indexedSeatChangeLog.teamId → Team.id — one Team, many SeatChangeLog · required · ON DELETE CASCADE · indexedSeatChangeLog.processedInProrationId → MonthlyProration.id — one MonthlyProration, many SeatChangeLog · optional · ON DELETE SET NULL · not indexedSeatChangeLog.teamBillingId → TeamBilling.id — one TeamBilling, many SeatChangeLog · optional · ON DELETE SET NULL · not indexedSeatChangeLog.organizationBillingId → OrganizationBilling.id — one OrganizationBilling, many SeatChangeLog · optional · ON DELETE SET NULL · not indexedMonthlyProration.teamId → Team.id — one Team, many MonthlyProration · required · ON DELETE CASCADE · indexedMonthlyProration.teamBillingId → TeamBilling.id — one TeamBilling, many MonthlyProration · optional · ON DELETE SET NULL · not indexedMonthlyProration.organizationBillingId → OrganizationBilling.id — one OrganizationBilling, many MonthlyProration · optional · ON DELETE SET NULL · not indexedIntegrationAttributeSync.organizationId → Team.id — one Team, many IntegrationAttributeSync · required · ON DELETE CASCADE · indexedIntegrationAttributeSync.credentialId → Credential.id — one Credential, many IntegrationAttributeSync · optional · ON DELETE CASCADE · indexedPendingRoutingTrace.formResponseId → App_RoutingForms_FormResponse.id — one App_RoutingForms_FormResponse, at most one PendingRoutingTrace · optional · ON DELETE CASCADE · indexedPendingRoutingTrace.queuedFormResponseId → App_RoutingForms_QueuedFormResponse.id — one App_RoutingForms_QueuedFormResponse, at most one PendingRoutingTrace · optional · ON DELETE CASCADE · indexed_user_eventtype.A → EventType.id — one EventType, many _user_eventtype · required · ON DELETE CASCADE · indexed_user_eventtype.B → users.id — one users, many _user_eventtype · required · ON DELETE CASCADE · indexedCreateTable
joinedAt — joinedAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.VideoCallGuest 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 | text | NOT NULL | |||
bookingUid | text | NOT NULL | |||
email | text | NOT NULL | |||
name | text | NOT NULL | |||
joinedAt | timestamp(3) | null | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | NOT NULL |
CreateTable
delegationCredentialId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on DelegationCredential must scan Credential to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to Credential maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often DelegationCredential rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.userId — Credential.userId 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.teamId — Credential.teamId may be NULL, so the relationship to Team is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.appId — Credential.appId may be NULL, so the relationship to App is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.delegationCredentialId — Credential.delegationCredentialId may be NULL, so the relationship to DelegationCredential is optional. That is legitimate (e.g. 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.userId, teamId, appId, delegationCredentialId — Credential has several nullable FKs (userId, teamId, appId, delegationCredentialId) 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 | serial | NOT NULL | |||
type | text | NOT NULL | |||
key | jsonb | NOT NULL | |||
encryptedKey | text | null | |||
userId | integer | null | users.id 1:N · CASCADE | ||
teamId | integer | null | Team.id 1:N · CASCADE | ||
appId | text | null | App.slug 1:N · CASCADE | ||
subscriptionId | text | null | |||
paymentStatus | text | null | |||
billingCycleStart | integer | null | |||
invalid | boolean | null | FALSE | ||
delegationCredentialId | text | null | DelegationCredential.id 1:N · CASCADE |
CreateTable
delegationCredentialId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on DelegationCredential must scan DestinationCalendar to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to DestinationCalendar maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often DelegationCredential rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.domainWideDelegationCredentialId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on DomainWideDelegation must scan DestinationCalendar to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to DestinationCalendar maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often DomainWideDelegation rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.userId — DestinationCalendar.userId 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.eventTypeId — DestinationCalendar.eventTypeId may be NULL, so the relationship to EventType is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.credentialId — DestinationCalendar.credentialId may be NULL, so the relationship to Credential is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.delegationCredentialId — DestinationCalendar.delegationCredentialId may be NULL, so the relationship to DelegationCredential is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.domainWideDelegationCredentialId — DestinationCalendar.domainWideDelegationCredentialId may be NULL, so the relationship to DomainWideDelegation is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.userId, eventTypeId, credentialId, delegationCredentialId, domainWideDelegationCredentialId — DestinationCalendar has several nullable FKs (userId, eventTypeId, credentialId, delegationCredentialId, domainWideDelegationCredentialId) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 | serial | NOT NULL | |||
integration | text | NOT NULL | |||
externalId | text | NOT NULL | |||
primaryEmail | text | null | |||
userId | integer | null | users.id 1:1 · CASCADE | ||
eventTypeId | integer | null | EventType.id 1:1 · CASCADE | ||
credentialId | integer | null | Credential.id 1:N · CASCADE | ||
createdAt | timestamp(3) | null | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | null | |||
delegationCredentialId | text | null | DelegationCredential.id 1:N · CASCADE | ||
domainWideDelegationCredentialId | text | null | DomainWideDelegation.id 1:N · CASCADE | ||
customCalendarReminder | integer | null |
CreateTable
userId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan TravelSchedule to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to TravelSchedule 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.startDate — startDate stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.endDate — endDate 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 | serial | NOT NULL | |||
userId | integer | NOT NULL | users.id 1:N · CASCADE | ||
timeZone | text | NOT NULL | |||
startDate | timestamp(3) | NOT NULL | |||
endDate | timestamp(3) | null | |||
prevTimeZone | text | null |
CreateTable
organizationId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on Team 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 Team rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.organizationId — users.organizationId may be NULL, so the relationship to Team is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.movedToProfileId — users.movedToProfileId may be NULL, so the relationship to Profile is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.organizationId, movedToProfileId — users has several nullable FKs (organizationId, movedToProfileId) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.emailVerified — emailVerified stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.created — created stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.trialEndsAt — trialEndsAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.lastActiveAt — lastActiveAt 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 | serial | NOT NULL | |||
uuid | uuid | NOT NULL | |||
username | text | null | |||
name | text | null | |||
email | text | NOT NULL | |||
emailVerified | timestamp(3) | null | |||
bio | text | null | |||
avatarUrl | text | null | |||
timeZone | text | NOT NULL | 'Europe/London' | ||
weekStart | text | NOT NULL | 'Sunday' | ||
bufferTime | integer | NOT NULL | 0 | ||
hideBranding | boolean | NOT NULL | FALSE | ||
theme | text | null | |||
appTheme | text | null | |||
created | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
trialEndsAt | timestamp(3) | null | |||
lastActiveAt | timestamp(3) | null | |||
defaultScheduleId | integer | null | |||
completedOnboarding | boolean | NOT NULL | FALSE | ||
locale | text | null | |||
timeFormat | integer | null | 12 | ||
twoFactorSecret | text | null | |||
twoFactorEnabled | boolean | NOT NULL | FALSE | ||
backupCodes | text | null | |||
identityProvider | IdentityProvider | NOT NULL | 'CAL' | ||
identityProviderId | text | null | |||
invitedTo | integer | null | |||
brandColor | text | null | |||
darkBrandColor | text | null | |||
allowDynamicBooking | boolean | null | TRUE | ||
allowSEOIndexing | boolean | null | TRUE | ||
receiveMonthlyDigestEmail | boolean | null | TRUE | ||
requiresBookerEmailVerification | boolean | null | FALSE | ||
metadata | jsonb | null | |||
verified | boolean | null | FALSE | ||
role | UserPermissionRole | NOT NULL | 'USER' | ||
disableImpersonation | boolean | NOT NULL | FALSE | ||
organizationId | integer | null | Team.id 1:N · SET NULL | ||
locked | boolean | NOT NULL | FALSE | ||
movedToProfileId | integer | null | Profile.id 1:1 · SET NULL | ||
isPlatformManaged | boolean | NOT NULL | FALSE | ||
smsLockState | SMSLockState | NOT NULL | 'UNLOCKED' | ||
smsLockReviewedByAdmin | boolean | NOT NULL | FALSE | ||
referralLinkId | text | null | |||
creationSource | CreationSource | null | |||
whitelistWorkflows | boolean | NOT NULL | FALSE | ||
autoOptInFeatures | boolean | NOT NULL | FALSE |
CreateTable
| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | serial | NOT NULL | |||
userId | integer | NOT NULL | users.id 1:N · CASCADE | ||
subscription | text | NOT NULL |
CreateTable
createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 | serial | NOT NULL | |||
uid | text | NOT NULL | |||
userId | integer | NOT NULL | users.id 1:N · CASCADE | ||
organizationId | integer | NOT NULL | Team.id 1:N · CASCADE | ||
username | text | NOT NULL | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | NOT NULL |
CreateTable
customRoleId — Membership.customRoleId may be NULL, so the relationship to Role is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 | serial | NOT NULL | |||
teamId | integer | NOT NULL | Team.id 1:N · CASCADE | ||
userId | integer | NOT NULL | users.id 1:N · CASCADE | ||
accepted | boolean | NOT NULL | FALSE | ||
role | MembershipRole | NOT NULL | |||
customRoleId | text | null | Role.id 1:N · SET NULL | ||
disableImpersonation | boolean | NOT NULL | FALSE | ||
createdAt | timestamp(3) | null | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | null |
CreateTable
teamId — VerificationToken.teamId may be NULL, so the relationship to Team is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.secondaryEmailId — VerificationToken.secondaryEmailId may be NULL, so the relationship to SecondaryEmail is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.teamId, secondaryEmailId — VerificationToken has several nullable FKs (teamId, secondaryEmailId) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.expires — expires stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 | serial | NOT NULL | |||
identifier | text | NOT NULL | |||
token | text | NOT NULL | |||
expires | timestamp(3) | NOT NULL | |||
expiresInDays | integer | null | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | NOT NULL | |||
teamId | integer | null | Team.id 1:N · SET NULL | ||
secondaryEmailId | integer | null | SecondaryEmail.id 1:N · SET NULL |
CreateTable
teamId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on Team must scan InstantMeetingToken to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to InstantMeetingToken maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often Team rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.bookingId — InstantMeetingToken.bookingId may be NULL, so the relationship to Booking is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.expires — expires stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 | serial | NOT NULL | |||
token | text | NOT NULL | |||
expires | timestamp(3) | NOT NULL | |||
teamId | integer | NOT NULL | Team.id 1:N · CASCADE | ||
bookingId | integer | null | Booking.id 1:1 · CASCADE | ||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | NOT NULL |
CreateTable
bookingId — Attendee.bookingId may be NULL, so the relationship to Booking is optional. That is legitimate (e.g. 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 | serial | NOT NULL | |||
email | text | NOT NULL | |||
name | text | NOT NULL | |||
timeZone | text | NOT NULL | |||
phoneNumber | text | null | |||
locale | text | null | 'en' | ||
bookingId | integer | null | Booking.id 1:N · CASCADE | ||
noShow | boolean | null | FALSE |
CreateTable
| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | serial | NOT NULL | |||
bookingId | integer | NOT NULL | Booking.id 1:1 · CASCADE | ||
utm_source | text | null | |||
utm_medium | text | null | |||
utm_campaign | text | null | |||
utm_term | text | null | |||
utm_content | text | null |
CreateTable
| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | serial | NOT NULL | |||
userId | integer | NOT NULL | users.id 1:N · CASCADE | ||
name | text | NOT NULL | |||
timeZone | text | null |
CreateTable
userId — Availability.userId 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.eventTypeId — Availability.eventTypeId may be NULL, so the relationship to EventType is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.scheduleId — Availability.scheduleId may be NULL, so the relationship to Schedule is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.userId, eventTypeId, scheduleId — Availability has several nullable FKs (userId, eventTypeId, scheduleId) 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 | serial | NOT NULL | |||
userId | integer | null | users.id 1:N · CASCADE | ||
eventTypeId | integer | null | EventType.id 1:N · SET NULL | ||
days | integer[] | null | |||
startTime | time | NOT NULL | |||
endTime | time | NOT NULL | |||
date | date | null | |||
scheduleId | integer | null | Schedule.id 1:N · SET NULL |
CreateTable
createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.expires — expires stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.ResetPasswordRequest 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 | text | NOT NULL | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | NOT NULL | |||
email | text | NOT NULL | |||
expires | timestamp(3) | NOT NULL |
CreateTable
createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.ReminderMail 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 | serial | NOT NULL | |||
referenceId | integer | NOT NULL | |||
reminderType | ReminderType | NOT NULL | |||
elapsedMinutes | integer | NOT NULL | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP |
CreateTable
appId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on App must scan Payment to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to Payment maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often App rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.appId — Payment.appId may be NULL, so the relationship to App is optional. That is legitimate (e.g. 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 | serial | NOT NULL | |||
uid | text | NOT NULL | |||
appId | text | null | App.slug 1:N · CASCADE | ||
bookingId | integer | NOT NULL | Booking.id 1:N · CASCADE | ||
amount | integer | NOT NULL | |||
fee | integer | NOT NULL | |||
currency | text | NOT NULL | |||
success | boolean | NOT NULL | |||
refunded | boolean | NOT NULL | |||
data | jsonb | NOT NULL | |||
externalId | text | NOT NULL | |||
paymentOption | PaymentOption | null | 'ON_BOOKING' |
CreateTable
impersonatedById, impersonatedUserId — Impersonations looks like a many-to-many link table but has no unique constraint across (impersonatedById, impersonatedUserId). The same pair can be inserted twice; every join through it will double-count.createdAt — createdAt 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 | serial | NOT NULL | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
impersonatedUserId | integer | NOT NULL | users.id 1:N · CASCADE | ||
impersonatedById | integer | NOT NULL | users.id 1:N · CASCADE |
CreateTable
teamId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on Team must scan ApiKey to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to ApiKey maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often Team rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.appId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on App must scan ApiKey to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to ApiKey maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often App rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.teamId — ApiKey.teamId may be NULL, so the relationship to Team is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.appId — ApiKey.appId may be NULL, so the relationship to App is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.teamId, appId — ApiKey has several nullable FKs (teamId, appId) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.expiresAt — expiresAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.lastUsedAt — lastUsedAt 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 | text | NOT NULL | |||
userId | integer | NOT NULL | users.id 1:N · CASCADE | ||
teamId | integer | null | Team.id 1:N · CASCADE | ||
note | text | null | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
expiresAt | timestamp(3) | null | |||
lastUsedAt | timestamp(3) | null | |||
hashedKey | text | NOT NULL | |||
appId | text | null | App.slug 1:N · CASCADE |
CreateTable
createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 | text | NOT NULL | |||
name | text | NOT NULL | |||
apiKeyId | text | NOT NULL | ApiKey.id 1:N · CASCADE | ||
ttl | integer | NOT NULL | |||
limit | integer | NOT NULL | |||
blockDuration | integer | NOT NULL | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | NOT NULL |
CreateTable
expiresAt — expiresAt 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 | serial | NOT NULL | |||
link | text | NOT NULL | |||
eventTypeId | integer | NOT NULL | EventType.id 1:N · CASCADE | ||
expiresAt | timestamp(3) | null | |||
maxUsageCount | integer | NOT NULL | 1 | ||
usageCount | integer | NOT NULL | 0 |
CreateTable
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.token_type — token_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.session_state — session_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 | text | NOT NULL | |||
userId | integer | NOT NULL | users.id 1:N · CASCADE | ||
type | text | NOT NULL | |||
provider | text | NOT NULL | |||
providerAccountId | text | NOT NULL | |||
providerEmail | text | null | |||
refresh_token | text | null | |||
access_token | text | null | |||
expires_at | integer | null | |||
token_type | text | null | |||
scope | text | null | |||
id_token | text | null | |||
session_state | text | null |
CreateTable
expires — expires 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 | text | NOT NULL | |||
sessionToken | text | NOT NULL | |||
userId | integer | NOT NULL | users.id 1:N · CASCADE | ||
expires | timestamp(3) | NOT NULL |
CreateTable
date — date 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 | serial | NOT NULL | |||
date | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
userId | integer | NOT NULL | users.id 1:N · CASCADE | ||
rating | text | NOT NULL | |||
comment | text | null |
CreateTable
| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | serial | NOT NULL | |||
eventTypeId | integer | NOT NULL | EventType.id 1:1 · CASCADE | ||
templateType | text | NOT NULL | 'CUSTOM_TEMPLATE' | ||
schedulerName | text | null | |||
generalPrompt | text | null | |||
yourPhoneNumber | text | NOT NULL | |||
numberToCall | text | NOT NULL | |||
guestName | text | null | |||
guestEmail | text | null | |||
guestCompany | text | null | |||
enabled | boolean | NOT NULL | FALSE | ||
beginMessage | text | null | |||
llmId | text | null |
CreateTable
agreedLicenseAt — agreedLicenseAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.Deployment 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 | 1 | ||
logo | text | null | |||
theme | jsonb | null | |||
licenseKey | text | null | |||
signatureTokenEncrypted | text | null | |||
agreedLicenseAt | timestamp(3) | null |
CreateTable
lastUsedAt — lastUsedAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 |
|---|---|---|---|---|---|
slug PK | text | NOT NULL | |||
enabled | boolean | NOT NULL | FALSE | ||
description | text | null | |||
type | FeatureType | null | 'RELEASE' | ||
stale | boolean | null | FALSE | ||
lastUsedAt | timestamp(3) | null | |||
createdAt | timestamp(3) | null | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | null | CURRENT_TIMESTAMP | ||
updatedBy | integer | null |
CreateTable
userId — OAuthClient.userId 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.createdAt — createdAt 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 |
|---|---|---|---|---|---|
clientId PK | text | NOT NULL | |||
redirectUri | text | NOT NULL | |||
clientSecret | text | null | |||
clientType | OAuthClientType | NOT NULL | 'confidential' | ||
name | text | NOT NULL | |||
purpose | text | null | |||
logo | text | null | |||
websiteUrl | text | null | |||
rejectionReason | text | null | |||
isTrusted | boolean | NOT NULL | FALSE | ||
status | OAuthClientStatus | NOT NULL | 'approved' | ||
userId | integer | null | users.id 1:N · SET NULL | ||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP |
CreateTable
createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.TempOrgRedirect 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 | serial | NOT NULL | |||
from | text | NOT NULL | |||
fromOrgId | integer | NOT NULL | |||
type | RedirectType | NOT NULL | |||
toUrl | text | NOT NULL | |||
enabled | boolean | NOT NULL | TRUE | ||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | NOT NULL |
CreateTable
avatars 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 |
|---|---|---|---|---|---|
teamId | integer | NOT NULL | 0 | ||
userId | integer | NOT NULL | 0 | ||
data | text | NOT NULL | |||
objectKey | text | NOT NULL | |||
isBanner | boolean | NOT NULL | FALSE |
CreateTable
date — date stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.HolidayCache 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 | text | NOT NULL | |||
countryCode | text | NOT NULL | |||
calendarId | text | NOT NULL | |||
eventId | text | NOT NULL | |||
name | text | NOT NULL | |||
date | timestamp(3) | NOT NULL | |||
year | integer | NOT NULL | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | NOT NULL |
CreateTable
userId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan RefreshToken to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to RefreshToken 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.platformOAuthClientId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on PlatformOAuthClient must scan RefreshToken to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to RefreshToken maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often PlatformOAuthClient rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.expiresAt — expiresAt 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 | serial | NOT NULL | |||
secret | text | NOT NULL | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
expiresAt | timestamp(3) | NOT NULL | |||
platformOAuthClientId | text | NOT NULL | PlatformOAuthClient.id 1:N · CASCADE | ||
userId | integer | NOT NULL | users.id 1:N · CASCADE |
CreateTable
organizationId — DSyncData.organizationId may be NULL, so the relationship to OrganizationSettings is optional. That is legitimate (e.g. 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 | serial | NOT NULL | |||
directoryId | text | NOT NULL | |||
tenant | text | NOT NULL | |||
organizationId | integer | null | OrganizationSettings.organizationId 1:1 · CASCADE |
CreateTable
directoryId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on DSyncData must scan DSyncTeamGroupMapping to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to DSyncTeamGroupMapping maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often DSyncData rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
id PK | serial | NOT NULL | |||
organizationId | integer | NOT NULL | |||
teamId | integer | NOT NULL | Team.id 1:N · CASCADE | ||
directoryId | text | NOT NULL | DSyncData.directoryId 1:N · CASCADE | ||
groupName | text | NOT NULL |
CreateTable
emailVerified — emailVerified 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 | serial | NOT NULL | |||
userId | integer | NOT NULL | users.id 1:N · CASCADE | ||
email | text | NOT NULL | |||
emailVerified | timestamp(3) | null |
CreateTable
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.createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.scheduledAt — scheduledAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.succeededAt — succeededAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.lastFailedAttemptAt — lastFailedAttemptAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.Task 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 | text | NOT NULL | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | NOT NULL | |||
scheduledAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
succeededAt | timestamp(3) | null | |||
type | text | NOT NULL | |||
payload | text | NOT NULL | |||
attempts | integer | NOT NULL | 0 | ||
maxAttempts | integer | NOT NULL | 3 | ||
lastError | text | null | |||
lastFailedAttemptAt | timestamp(3) | null | |||
referenceUid | text | null |
CreateTable
createdAt — createdAt 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 |
|---|---|---|---|---|---|
managedOrganizationId | integer | NOT NULL | Team.id 1:1 · CASCADE | ||
managerOrganizationId | integer | NOT NULL | Team.id 1:N · CASCADE | ||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP |
CreateTable
createdAt — createdAt 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 | serial | NOT NULL | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
bookingId | integer | NOT NULL | Booking.id 1:N · CASCADE | ||
reasonEnum | AssignmentReasonEnum | NOT NULL | |||
reasonString | text | NOT NULL |
CreateTable
workspacePlatformId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on WorkspacePlatform must scan DelegationCredential to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to DelegationCredential maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often WorkspacePlatform rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.lastEnabledAt — lastEnabledAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.lastDisabledAt — lastDisabledAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 | text | NOT NULL | |||
workspacePlatformId | integer | NOT NULL | WorkspacePlatform.id 1:N · CASCADE | ||
serviceAccountKey | jsonb | NOT NULL | |||
enabled | boolean | NOT NULL | FALSE | ||
lastEnabledAt | timestamp(3) | null | |||
lastDisabledAt | timestamp(3) | null | |||
organizationId | integer | NOT NULL | Team.id 1:N · CASCADE | ||
domain | text | NOT NULL | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | NOT NULL |
CreateTable
workspacePlatformId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on WorkspacePlatform must scan DomainWideDelegation to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to DomainWideDelegation maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often WorkspacePlatform rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 | text | NOT NULL | |||
workspacePlatformId | integer | NOT NULL | WorkspacePlatform.id 1:N · CASCADE | ||
serviceAccountKey | jsonb | NOT NULL | |||
enabled | boolean | NOT NULL | FALSE | ||
organizationId | integer | NOT NULL | Team.id 1:N · CASCADE | ||
domain | text | NOT NULL | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | NOT NULL |
CreateTable
createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 | serial | NOT NULL | |||
slug | text | NOT NULL | |||
name | text | NOT NULL | |||
description | text | NOT NULL | |||
defaultServiceAccountKey | jsonb | NOT NULL | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | NOT NULL | |||
enabled | boolean | NOT NULL | FALSE |
CreateTable
reportedById — WrongAssignmentReport.reportedById 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.teamId — WrongAssignmentReport.teamId may be NULL, so the relationship to Team is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.routingFormId — WrongAssignmentReport.routingFormId may be NULL, so the relationship to App_RoutingForms_Form is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.reviewedById — WrongAssignmentReport.reviewedById 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.reportedById, teamId, routingFormId, reviewedById — WrongAssignmentReport has several nullable FKs (reportedById, teamId, routingFormId, reviewedById) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.reviewedAt — reviewedAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 | uuid | NOT NULL | |||
bookingUid | text | NOT NULL | Booking.uid 1:1 · CASCADE | ||
reportedById | integer | null | users.id 1:N · SET NULL | ||
correctAssignee | text | null | |||
additionalNotes | text | NOT NULL | |||
teamId | integer | null | Team.id 1:N · SET NULL | ||
routingFormId | text | null | App_RoutingForms_Form.id 1:N · SET NULL | ||
status | WrongAssignmentReportStatus | NOT NULL | 'PENDING' | ||
reviewedById | integer | null | users.id 1:N · SET NULL | ||
reviewedAt | timestamp(3) | null | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | NOT NULL |
CreateTable
createdAt — createdAt 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 | serial | NOT NULL | |||
name | text | NOT NULL | |||
cancellationReason | text | null | |||
teamId | integer | NOT NULL | Team.id 1:N · CASCADE | ||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP |
CreateTable
userId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on users must scan FilterSegment to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to FilterSegment 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.teamId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on Team must scan FilterSegment to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to FilterSegment maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often Team rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.teamId — FilterSegment.teamId may be NULL, so the relationship to Team is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 | serial | NOT NULL | |||
name | text | NOT NULL | |||
tableIdentifier | text | NOT NULL | |||
scope | FilterSegmentScope | NOT NULL | |||
activeFilters | jsonb | null | |||
sorting | jsonb | null | |||
columnVisibility | jsonb | null | |||
columnSizing | jsonb | null | |||
perPage | integer | NOT NULL | |||
searchTerm | text | null | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | NOT NULL | |||
userId | integer | NOT NULL | users.id 1:N · CASCADE | ||
teamId | integer | null | Team.id 1:N · CASCADE |
CreateTable
createdAt — createdAt 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 | uuid | NOT NULL | |||
type | AuditActorType | NOT NULL | |||
userUuid | uuid | null | |||
attendeeId | integer | null | |||
credentialId | integer | null | |||
email | text | null | |||
phone | text | null | |||
name | text | null | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP |
CreateTable
userId — Agent.userId 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.teamId — Agent.teamId may be NULL, so the relationship to Team is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.userId, teamId — Agent has several nullable FKs (userId, teamId) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 | text | NOT NULL | |||
name | text | NOT NULL | |||
userId | integer | null | users.id 1:N · CASCADE | ||
teamId | integer | null | Team.id 1:N · CASCADE | ||
providerAgentId | text | NOT NULL | |||
inboundEventTypeId | integer | null | |||
outboundEventTypeId | integer | null | |||
enabled | boolean | NOT NULL | TRUE | ||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | NOT NULL |
CreateTable
processedInProrationId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on MonthlyProration must scan SeatChangeLog to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to SeatChangeLog maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often MonthlyProration rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.teamBillingId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on TeamBilling must scan SeatChangeLog to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to SeatChangeLog maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often TeamBilling rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.organizationBillingId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on OrganizationBilling must scan SeatChangeLog to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to SeatChangeLog maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often OrganizationBilling rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.processedInProrationId — SeatChangeLog.processedInProrationId may be NULL, so the relationship to MonthlyProration is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.teamBillingId — SeatChangeLog.teamBillingId may be NULL, so the relationship to TeamBilling is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.organizationBillingId — SeatChangeLog.organizationBillingId may be NULL, so the relationship to OrganizationBilling is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.processedInProrationId, teamBillingId, organizationBillingId — SeatChangeLog has several nullable FKs (processedInProrationId, teamBillingId, organizationBillingId) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.changeDate — changeDate stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.createdAt — createdAt 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 | text | NOT NULL | |||
teamId | integer | NOT NULL | Team.id 1:N · CASCADE | ||
changeType | SeatChangeType | NOT NULL | |||
seatCount | integer | NOT NULL | |||
userId | integer | null | |||
triggeredBy | integer | null | |||
changeDate | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
monthKey | text | NOT NULL | |||
operationId | text | null | |||
processedInProrationId | text | null | MonthlyProration.id 1:N · SET NULL | ||
metadata | jsonb | null | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
teamBillingId | text | null | TeamBilling.id 1:N · SET NULL | ||
organizationBillingId | text | null | OrganizationBilling.id 1:N · SET NULL |
CreateTable
teamBillingId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on TeamBilling must scan MonthlyProration to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to MonthlyProration maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often TeamBilling rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.organizationBillingId — PostgreSQL does not index FK columns automatically. Every DELETE/UPDATE on OrganizationBilling must scan MonthlyProration to check the constraint, and every join from the parent side is a sequential scan. The scan cost grows with the child table forever, so this gets worse on its own.
An index is not free. Every write to MonthlyProration maintains it — insert, update and delete alike — and it takes disk. Weigh that against how often OrganizationBilling rows are actually deleted or re-keyed — if the answer is never, the scan never happens and the index only costs.teamBillingId — MonthlyProration.teamBillingId may be NULL, so the relationship to TeamBilling is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.organizationBillingId — MonthlyProration.organizationBillingId may be NULL, so the relationship to OrganizationBilling is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.teamBillingId, organizationBillingId — MonthlyProration has several nullable FKs (teamBillingId, organizationBillingId) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.periodStart — periodStart stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.periodEnd — periodEnd stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.subscriptionStart — subscriptionStart stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.subscriptionEnd — subscriptionEnd stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.chargedAt — chargedAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.failedAt — failedAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 | text | NOT NULL | |||
teamId | integer | NOT NULL | Team.id 1:N · CASCADE | ||
monthKey | text | NOT NULL | |||
periodStart | timestamp(3) | NOT NULL | |||
periodEnd | timestamp(3) | NOT NULL | |||
seatsAtStart | integer | NOT NULL | |||
seatsAdded | integer | NOT NULL | |||
seatsRemoved | integer | NOT NULL | |||
netSeatIncrease | integer | NOT NULL | |||
seatsAtEnd | integer | NOT NULL | |||
subscriptionId | text | NOT NULL | |||
subscriptionItemId | text | NOT NULL | |||
customerId | text | NOT NULL | |||
subscriptionStart | timestamp(3) | NOT NULL | |||
subscriptionEnd | timestamp(3) | NOT NULL | |||
remainingDays | integer | NOT NULL | |||
pricePerSeat | integer | NOT NULL | |||
proratedAmount | integer | NOT NULL | |||
invoiceItemId | text | null | |||
invoiceId | text | null | |||
invoiceUrl | text | null | |||
status | ProrationStatus | NOT NULL | 'PENDING' | ||
chargedAt | timestamp(3) | null | |||
failedAt | timestamp(3) | null | |||
failureReason | text | null | |||
retryCount | integer | NOT NULL | 0 | ||
metadata | jsonb | null | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | NOT NULL | |||
teamBillingId | text | null | TeamBilling.id 1:N · SET NULL | ||
organizationBillingId | text | null | OrganizationBilling.id 1:N · SET NULL |
CreateTable
credentialId — IntegrationAttributeSync.credentialId may be NULL, so the relationship to Credential is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.createdAt — createdAt stores wall-clock time with no zone. It reads back differently depending on the session's TimeZone, and DST transitions produce ambiguous values.updatedAt — updatedAt 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 | text | NOT NULL | |||
organizationId | integer | NOT NULL | Team.id 1:N · CASCADE | ||
name | text | NOT NULL | |||
integration | text | NOT NULL | |||
credentialId | integer | null | Credential.id 1:N · CASCADE | ||
enabled | boolean | NOT NULL | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
updatedAt | timestamp(3) | NOT NULL |
CreateTable
formResponseId — PendingRoutingTrace.formResponseId may be NULL, so the relationship to App_RoutingForms_FormResponse is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.queuedFormResponseId — PendingRoutingTrace.queuedFormResponseId may be NULL, so the relationship to App_RoutingForms_QueuedFormResponse is optional. That is legitimate (e.g. approved_by before approval) but often a modelling shrug: a row with no owner, or two nullable FKs that are secretly an either/or.formResponseId, queuedFormResponseId — PendingRoutingTrace has several nullable FKs (formResponseId, queuedFormResponseId) that look like an exclusive arc — a row should point at exactly one of them. Nothing stops zero or both.createdAt — createdAt 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 | text | NOT NULL | |||
createdAt | timestamp(3) | NOT NULL | CURRENT_TIMESTAMP | ||
trace | jsonb | NOT NULL | |||
formResponseId | integer | null | App_RoutingForms_FormResponse.id 1:1 · CASCADE | ||
queuedFormResponseId | text | null | App_RoutingForms_QueuedFormResponse.id 1:1 · CASCADE |
CreateTable
| Column | Type | Null | Default | References | Notes |
|---|---|---|---|---|---|
A PK | integer | NOT NULL | EventType.id 1:N · CASCADE | ||
B PK | integer | NOT NULL | users.id 1:N · CASCADE |