MariaDB vs MySQL 차이와 선택 기준

MariaDB vs MySQL 차이와 선택 기준 (2026)

2026년 기준 결론부터 정리하면, 신규 프로젝트에서 선택지는 MySQL 8.4 LTS와 MariaDB 11.8 LTS(또는 12.3 LTS) 두 갈래입니다. MySQL 8.0은 2026년 4월에 지원이 종료(EOL)되어 더 이상 프로덕션 선택지가 아닙니다. 두 DB는 같은 뿌리(MySQL 5.5)에서 갈라졌지만 이제는 서로의 드롭인(drop-in) 대체재가 아니며, 라이선스·클라우드 지원·기능 방향이 뚜렷하게 달라졌습니다.

이 글에서는 2026년 시점의 버전 현황과 실질적인 차이, 그리고 프로젝트 성격별 선택 기준을 정리합니다.

2026년 버전 현황

구분	MySQL	MariaDB
현재 LTS	8.4 LTS	11.8 LTS, 12.3 LTS
지원 종료	8.0 → 2026년 4월 EOL	10.6·10.11 등 구 LTS 순차 종료
개발 트랙	LTS + Innovation(9.x) 2트랙	LTS(연 1회) + 롤링 릴리스

MySQL은 오라클이 LTS와 Innovation 두 트랙으로 운영하며, 9.x Innovation 라인에서 벡터 타입 등 신기능을 먼저 선보이고 있습니다. MariaDB는 11.8 LTS에서 네이티브 벡터 검색을 정식(GA) 지원했고, 12 시리즈부터는 각 메이저의 .3 릴리스가 LTS가 되는 체계(12.3 LTS)로 정리됐습니다.

실질적인 차이 3가지

1. 라이선스와 거버넌스. MySQL은 오라클 소유로 커뮤니티 에디션(GPL)과 상용 에디션이 나뉩니다. MariaDB는 재단 중심의 GPL v2이며, JDBC 등 커넥터가 LGPL이라 상용 애플리케이션에 임베드할 때 라이선스 부담이 적습니다.

2. 기능 방향. MariaDB는 Galera Cluster 기반 멀티마스터 복제, 시스템 버전 테이블, 벡터 검색 내장 등 독자 기능을 쌓아 왔습니다. MySQL은 InnoDB Cluster·Group Replication과 바이너리 JSON 타입 등 자체 스택을 강화했습니다. 특히 JSON 처리 방식이 다릅니다. MySQL은 이진 포맷으로 저장하고, MariaDB는 LONGTEXT 기반에 별칭(Alias)으로 JSON을 제공하므로 ORM 마이그레이션 시 미묘한 차이가 생길 수 있습니다.

3. 호환성의 한계. MySQL 5.7/MariaDB 10.x 이전에는 사실상 상호 교체가 가능했지만, MySQL 8.x와 MariaDB 11.x 이후로는 복제 포맷·JSON·인증 플러그인 등에서 갈라졌습니다. 지금은 "비슷한 문법의 다른 DB"로 보고 마이그레이션을 계획해야 합니다.

Spring Boot 연결 설정

애플리케이션 관점에서는 드라이버와 URL만 다르고 사용법은 거의 동일합니다. MariaDB 기준 설정입니다.

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
    runtimeOnly 'org.mariadb.jdbc:mariadb-java-client'
}

spring:
  datasource:
    url: jdbc:mariadb://localhost:3306/appdb
    username: ${DB_USER}
    password: ${DB_PASSWORD}
    driver-class-name: org.mariadb.jdbc.Driver
  jpa:
    hibernate:
      ddl-auto: validate
    properties:
      hibernate.dialect: org.hibernate.dialect.MariaDBDialect

MySQL이라면 mysql-connector-j와 jdbc:mysql://, MySQLDialect로 바꾸면 됩니다. JPA를 쓰는 한 코드 변경은 거의 없지만, 네이티브 쿼리나 JSON 함수를 쓴다면 방언 차이를 반드시 점검해야 합니다.

선택 기준

MySQL 8.4 LTS가 맞는 경우: 오라클 벤더 지원이 필요한 엔터프라이즈, MySQL 기반 관리형 서비스(RDS MySQL, Aurora MySQL)를 그대로 쓰는 팀, 기존 MySQL 8.x 자산이 많은 조직.

MariaDB LTS가 맞는 경우: GPL/LGPL 기반으로 라이선스 리스크를 줄이고 싶은 서비스, Galera 멀티마스터나 내장 벡터 검색이 필요한 경우, 리눅스 배포판 기본 저장소로 설치·운영을 단순화하려는 팀. 실제로 Kraft도 MariaDB를 운영 DB로 사용 중인데, 배포판 저장소 기반이라 서버 셋업과 버전 관리가 단순하다는 점이 체감상 가장 큰 장점이었습니다.

실무 팁과 주의사항

클라우드를 쓴다면 관리형 서비스의 지원 버전을 먼저 확인하세요. RDS는 MySQL과 MariaDB의 지원 메이저 버전과 EOL 일정이 각각 다릅니다. 또한 MySQL 8.0에서 넘어와야 하는 상황이라면, 8.4 업그레이드와 MariaDB 마이그레이션의 공수가 다르니 인증 플러그인(caching_sha2_password)과 복제 구성 호환 여부를 사전 검증하는 것이 안전합니다.

마무리

요약하면 "무엇이 더 좋은가"보다 "우리 환경에서 지원과 라이선스, 필요한 기능이 어느 쪽에 있는가"가 기준입니다. MariaDB 11.8의 벡터 검색은 LLM 애플리케이션의 RAG 저장소로도 활용할 수 있어, Spring AI와 조합하는 글로 이어서 다뤄 볼 예정입니다.