# 마이그레이션과 타입 스키마를 바꾸는 SQL을 **버전이 붙은 파일**로 남겨 두면, 같은 변경을 다른 프로젝트(스테이징 → 프로덕션)에 같은 순서로 다시 적용할 수 있어요. `run_sql`로 바꾼 것은 기록이 남지 않아요. ``` list_migrations 적용한 마이그레이션의 버전·이름·시각 (오래된 순) apply_migrations 적용하지 않은 것만 버전 순서대로 실행하고 기록 remove_migration_record 기록 하나 지우기 (만든 것은 그대로) dump_schema 지금 스키마를 다시 만들 수 있는 SQL로 generate_typescript_types supabase-js의 Database 타입 ``` ## 적용되는 방식 - 마이그레이션 하나가 **트랜잭션 하나**예요. 실패하면 그 마이그레이션만 통째로 되돌리고 멈춰요. 앞의 것은 적용된 채로 남고, 뒤의 것은 실행하지 않아요. - 버전은 숫자이고(보통 `YYYYMMDDHHMMSS`), 숫자 크기 순서로 실행해요. 이미 기록된 버전은 건너뛰어요. - 이미 적용된 마지막 버전보다 **앞선** 버전이 새로 오면 거절해요. 늦게 합친 브랜치라면 `include_all: true`. - 기록된 뒤 내용이 바뀐 파일은 다시 실행하지 않고 `drifted`로 알려 줘요. 고치려면 새 마이그레이션을 쓰세요. - `run_sql`과 같은 권한(쓰기 토큰, 소유자·관리자·개발자)으로, 프로젝트의 service_role로 실행해요. 표를 만들면 RLS가 켜지는 것도 같아요. 한 마이그레이션은 60초를 넘길 수 없어요. - 데이터 스키마가 search_path 맨 앞에 있으니 `create table notes (...)`처럼 이름만 쓰면 돼요. ## 기록은 어디에 프로젝트의 `oneend_migrations` 표예요. 소유자가 SQL로 읽을 수 있고, RLS가 켜져 있고 규칙이 없어서 공개 키로는 보이지 않아요. `supabase_migrations.schema_migrations`와 같은 역할이에요. ## 스키마를 파일로, 타입을 코드로 `dump_schema`는 타입·시퀀스·표와 제약·외래 키·인덱스·함수·뷰·트리거·RLS와 규칙을 SQL로 줘요. 이미 있는 프로젝트를 마이그레이션으로 관리하기 시작할 때, 이것을 첫 마이그레이션으로 저장하고 `apply_migrations`에 `record_only: true`로 기록만 남기세요. 실행하면 이미 있는 표와 부딪쳐요. `generate_typescript_types`는 `supabase gen types typescript`와 같은 모양(Tables의 Row/Insert/Update/Relationships, Views, Functions의 Args/Returns, Enums, CompositeTypes)을 줘요. 스키마 이름은 `public`이에요. ## 같은 일을 HTTP로 ``` GET /projects//migrations POST /projects//migrations {migrations: [{version, name, sql}], include_all, record_only, dry_run} DELETE /projects//migrations/ GET /projects//schema {sql, objects} GET /projects//types/typescript?schema=public {types} ``` --- https://end.blackall.ai/docs/migrations?lang=ko