fix: set PostgreSQL serial sequence MINVALUE and enable CYCLE

[RogerHYang]

Add a migration that sets MINVALUE to -2147483648 and enables CYCLE on all serial (32-bit) sequences. This doubles the usable ID range from ~2.1B to ~4.3B and allows sequences to wrap around instead of erroring when they reach MAXVALUE. Also update the DDL generator to emit ALTER SEQUENCE statements for sequences with non-default attributes.

Note: after CYCLE wraps around, sorting by ID will no longer correspond to insertion order (e.g. rows with negative IDs will sort before older positive-ID rows). Code that uses ID ordering as a proxy for creation time should use a timestamp column instead. Primary key collisions are theoretically possible after a full cycle, but moot at ~4.3B rows.

[claude]

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.

[anticorrelator]

Concern: ID ordering invariants break after sequence wrap-around

The CYCLE behavior means that after the sequence reaches MAXVALUE (2,147,483,647), newly inserted rows will receive IDs starting from MINVALUE (-2,147,483,648). This is correct from a sequence exhaustion standpoint, but it breaks a pervasive implicit invariant throughout the codebase: higher ID = newer record.

1. Cursor-based pagination and "newest first" ordering

The REST and GraphQL pagination layers use ORDER BY id DESC with keyset pagination (WHERE id <= cursor_rowid) across ~20+ endpoints in src/phoenix/server/api/routers/v1/ (spans, traces, annotations, datasets, projects, prompts, experiments, users, sessions) and the GraphQL layer (queries.py, types/Project.py, types/Trace.py).

After wrap-around, newly inserted records with negative IDs sort after all positive IDs in descending order. Users paginating "newest first" would not see post-wrap records on the first page — they'd appear at the very end of results instead.

2. MAX(id) and row_number(ORDER BY id) as "latest version" / "sequence number" proxies

Several data loaders use ID ordering as a proxy for recency or sequence:

• LatestPromptVersionIdDataLoader (latest_prompt_version_ids.py:31) uses func.max(PromptVersion.id) to find the latest version (comment in code: "max version id (which is the latest)"). After wrap, MAX() returns the highest positive ID — an older version — not the newest negative-ID version. Same pattern exists in dataset example revisions across Dataset.py, dataset_mutations.py, and experiments.py.

• Sequence numbering in ExperimentSequenceNumberDataLoader (experiment_sequence_number.py:30) and PromptVersionSequenceNumberDataLoader (prompt_version_sequence_number.py:25) use row_number().over(order_by=Model.id). After wrap, negative IDs sort first in ASC order, scrambling ordinals for all existing records.

• PromptVersion.previous_version (types/PromptVersion.py:90) uses WHERE id < self.id_attr — a post-wrap version with a negative ID would lose its link to all pre-wrap versions since every positive ID is "greater than" every negative ID.

These are silent logic errors — no exception is thrown, just wrong data returned to users.

Practical likelihood

This only manifests after ~2.1B rows per table, which is extremely unlikely for most deployments. But the failure mode is subtle (wrong results, not errors), making it harder to diagnose when it does occur.

Possible mitigation strategies

1. Document the invariant break: At minimum, add a comment block in the migration (and ideally in the PR description) listing the code paths that assume ID monotonicity, so future maintainers know what to audit if the BIGINT migration hasn't happened by the time any table approaches 2B rows.

2. Track a BIGINT migration for high-volume tables: If spans and traces are expected to be the highest-volume tables, migrating their PKs to BIGINT would eliminate the wrap-around scenario entirely for practical purposes. This could be a follow-up tracked issue.

3. Add created_at-based ordering where correctness matters: For the "latest version" lookups and sequence numbering, switching from MAX(id) / ORDER BY id to timestamp-based ordering would make these code paths resilient to ID wrap-around regardless of column type.

4. Monitoring/alerting: Add a check (or document one for operators) that alerts when any sequence's last_value exceeds a threshold (e.g., 80% of MAXVALUE), giving time to execute a BIGINT migration before wrap-around occurs.

None of these need to block this PR if the team accepts the trade-off consciously — the immediate benefit of preventing hard sequence exhaustion errors is real. But the affected code paths should be documented so the team can prioritize accordingly.