고객사 라이선스 요구를 계기로, 운영 중인 4개 DB 인스턴스를 read-only 실측해 MySQL·MariaDB·PostgreSQL을 파티셔닝·인덱스 구조 중심으로 비교하고 전환 방안을 정리
DB 엔진 논쟁은 의견 대결이 되기 쉽습니다. 그래서 문서 대신 우리 스키마를 먼저 쟀습니다. 4개 인스턴스를 read-only로 실측해 보니 파티셔닝은 한 건도 없었고, 어떤 테이블은 인덱스가 데이터보다 컸습니다. 비교는 그 숫자 위에서만 했습니다.
결론을 단정하지 않은 것도 의도입니다. 라이선스 정책이 어디까지 요구하는지에 따라 최소비용 답(MariaDB)과 구조개선 답(PostgreSQL)이 갈리기 때문에, 문서는 축별 비교와 비용을 정직하게 남기고 결정은 회의로 넘겼습니다.
고객사의 MySQL 라이선스 정책 문의를 계기로 엔진 대안 검토가 필요해졌습니다. 동시에 운영 현실도 있었습니다. 수십억 행 단일 테이블이 파티셔닝 없이 돌고 있었고, 일부 테이블은 인덱스가 데이터보다 큰 상태였습니다.
information_schema.PARTITIONS 실측비교는 우리 스키마에 대입해서만 했습니다. 예를 들어 최대 테이블은 PK와 유니크 키에 공통 컬럼이 없어 어떤 엔진을 골라도 파티셔닝 전에 키 재설계가 선행돼야 한다는 것, MySQL·MariaDB는 파티션 테이블에 FK를 걸 수 없고 PostgreSQL은 FK 유지·pg_partman 자동화·BRIN·무중단 purge가 가능하다는 것을 축별로 정리했습니다.
PostgreSQL의 비용도 같은 문서에 정직하게 남겼습니다 — VACUUM 운영 부담, 힙 구조의 포인트 조회 특성, 코드 전환 약 2~3주(FULLTEXT 8곳·뷰 58개 재작성)와 3TB 데이터 이관. 라이선스 대응만 보면 MariaDB가 최소비용이라는 점도 명시했습니다.
데이터 엔지니어링 리드로서 실측 설계와 수행, 원인 분석, 3엔진 비교 문서 작성을 직접 진행했습니다. 운영 DB를 다루므로 실측은 read-only로 한정했고, 엔진 채택 결정은 라이선스 정책 확인 후 회의로 확정하도록 문서에 명시했습니다.
라이선스 대응 로드맵(MariaDB 전환 검토)과 자매 문서로 진행. 결정 전 단계의 검토 작업임을 문서에 그대로 남김.