[Database] Alembic으로 Postgres 테이블 생성 및 스키마 수정

TIL: Alembic으로 임베딩 차원 변경 마이그레이션, 인덱스 opclass, 권한 이슈 정리

오늘 한 것

• 기존 테이블 A, B를 각각 _bak으로 리네임해 백업.
• 동일 스키마와 제약·인덱스를 유지한 채 새 테이블을 생성하고 embedding 컬럼만 VECTOR(384)로 변경하는 마이그레이션 설계.
• Alembic 실행 위치, downgrade 방법, 인덱스 opclass 의미, 권한 이슈 트러블슈팅 정리.

---

Alembic 마이그레이션 설계 포인트

• 대상 스키마: sample
• 변경 범위:
  • 특정 테이블 백업 후 재생성.
• 백업 절차:
  • A → A_bak
  • B → B_bak
• 새 테이블 생성:
  • 기존 정의 유지, 단 embedding만 VECTOR(384)로 변경.
• 인덱스/제약(동일 유지):
  • HNSW 인덱스: embedding vector_cosine_ops with (m=16, ef_construction=64)

---

실행 위치와 리비전 생성

• 실행 위치: 레포 루트에서 실행하면 alembic.ini의 script_location = alembic 설정에 따라 자동으로 alembic/versions/ 아래 생성됨.
• 리비전 생성 예시:

  cd /Users/sample
  alembic revision -m "test"

• 새 리비전의 down_revision은 기존 버전으로 설정.

---

downgrade 사용법

• 현재/이력 확인:

  alembic current
  alembic history --verbose

• 한 단계 되돌리기:

  alembic downgrade -1

---

인덱스 opclass(int4_ops, text_ops) 이해

• 핵심: 기본 B-Tree에서 정수/텍스트 컬럼은 opclass를 생략해도 동일 동작.
  • INTEGER → int4_ops
  • TEXT → text_ops
• 즉, 다음 두 정의는 기능·성능이 실질적으로 동일.
  • 생략: CREATE INDEX ... ON table (document_id);
  • 명시: CREATE INDEX ... ON table USING btree (document_id int4_ops);
• opclass를 일부러 바꿀 때만 의미가 달라짐(예: text_pattern_ops, collation, 다른 인덱스 타입 등).

---

배운 점

• 기본 B-Tree 인덱스에서는 정수/텍스트 opclass를 명시하지 않아도 동작·성능은 동일.
• Alembic는 루트에서 실행하면 설정 경로를 자동으로 따라가며, down_revision 체인을 정확히 유지해야 안전하게 롤백 가능.