MariaDB 버전 선택 가이드

2026년 7월 기준 MariaDB의 최신 LTS는 12.3입니다. 2026년 5월에 출시됐고 2029년 6월까지 지원되므로, 신규 프로젝트라면 12.3 LTS가 기본 선택입니다. 반대로 10.6 LTS는 2026년 7월 6일자로 커뮤니티 지원이 종료됐기 때문에, 아직 운영 중이라면 지금이 업그레이드를 계획할 시점입니다.

이 결론의 배경이 되는 MariaDB의 릴리스 모델과 버전별 지원 기간, 그리고 상황별 선택 기준을 차례로 정리합니다.

LTS와 롤링 릴리스, 무엇이 다른가

MariaDB는 두 종류의 릴리스를 냅니다.

• LTS(Long Term Support): 매년 1회 나오는 장기 지원 버전입니다. 11.4까지는 5년, 11.8부터는 3년간 버그·보안 패치가 제공됩니다.
• 롤링(rolling) 릴리스: 분기마다 나오며, 다음 릴리스가 출시되면 지원이 끝납니다. 신기능을 먼저 접할 수 있지만 지원 기간이 사실상 3개월 남짓이라 운영 환경에는 적합하지 않습니다.

12 시리즈부터는 버전 번호 체계도 정리됐습니다. 12.0, 12.1, 12.2는 롤링이고 마지막 .3인 12.3이 LTS가 되는 구조입니다. 이후 메이저 버전도 같은 패턴(13.0~13.2 롤링 → 13.3 LTS)을 따를 예정입니다. "12.3이 왜 갑자기 LTS지?"라는 의문이 들었다면 이 정책 변화 때문입니다.

버전별 지원 현황 (2026년 7월 기준)

버전 출시 커뮤니티 지원 종료 비고

12.3 LTS	2026-05	2029-06	최신 LTS
12.0 ~ 12.2	분기별	다음 릴리스 출시 시	롤링
11.8 LTS	2025-06	2028-06	3년 지원 정책 첫 적용
11.4 LTS	2024-05	2029-05	5년 지원의 마지막 LTS
10.11 LTS	2023-02	2028-02
10.6 LTS	2021-07	2026-07 (종료)	업그레이드 필요

표에서 눈여겨볼 부분이 하나 있습니다. 지원 기간이 5년에서 3년으로 줄면서, 나중에 나온 11.8(2028년 6월 종료)이 먼저 나온 11.4(2029년 5월 종료)보다 지원이 일찍 끝납니다. "더 최신 LTS니까 더 오래 지원되겠지"라는 직관이 통하지 않는 구간이므로, 지원 종료 일정은 버전 번호가 아니라 날짜 기준으로 확인해야 합니다.

상황별 선택 기준

신규 프로젝트라면 12.3 LTS가 기본값입니다. 12.x 롤링 시리즈에서 다듬어진 기능이 합쳐진 버전이고, 현재 선택지 중 지원 기간도 가장 깁니다. 조직 정책상 출시 직후 버전을 피해야 한다면 11.8도 대안이지만, 지원 종료가 12.3보다 1년가량 이르다는 점을 감안해 이후 12.3 전환 일정을 함께 잡아두는 편이 좋습니다.

10.6 이하를 운영 중이라면 업그레이드 계획이 최우선입니다. MariaDB는 여러 버전을 건너뛰는 업그레이드도 지원하지만, 중간 버전들의 비호환 변경 사항을 전부 검토해야 하므로 실무에서는 한 LTS씩(예: 10.6 → 10.11 → 11.4 또는 11.8) 올리면서 단계마다 검증하는 쪽이 안전합니다.

신기능 검증이 목적이라면 롤링 릴리스는 개발·스테이징 환경에서만 사용하고, 운영 반영은 해당 기능이 포함된 다음 LTS를 기다리는 방식을 권장합니다.

업그레이드 실무 팁

시작은 현재 버전 확인입니다.

SELECT VERSION();

바이너리나 패키지를 교체한 뒤에는 시스템 테이블 갱신을 위해 mariadb-upgrade를 실행합니다.

mariadb-upgrade -u root -p

Docker로 운영한다면 latest나 lts 같은 유동 태그 대신 버전을 명시해 고정하세요. 이번 12.3 출시처럼 최신 LTS가 교체되는 시점에 의도치 않은 메이저 업그레이드가 발생하는 사고를 막을 수 있습니다.

docker pull mariadb:12.3   # 유동 태그 대신 버전 고정

12.3으로 올릴 때 특히 확인할 항목은 innodb_snapshot_isolation 기본값이 ON으로 바뀐 점입니다. REPEATABLE READ 격리 수준에서 트랜잭션 동작이 달라질 수 있어, 격리 수준에 민감한 로직이 있다면 스테이징에서 먼저 검증해야 합니다. 예약어도 새로 추가됐으므로 기존 테이블·컬럼명이 겹치지 않는지 점검이 필요합니다. Spring Boot 같은 JVM 애플리케이션에서 접속한다면 MariaDB Connector/J가 오래된 버전은 아닌지도 함께 확인하세요. 서버만 올리고 드라이버를 방치하면 인증이나 신규 기능 호환에서 문제가 생길 수 있습니다. 그리고 어떤 경로를 택하든 백업과 복원 리허설은 기본입니다.

MySQL을 쓰고 있다면

비슷한 시기에 MySQL 쪽에도 큰 변화가 있었습니다. MySQL 8.0은 2026년 4월부로 지원이 종료됐고, 직접적인 대체 경로는 8.4 LTS입니다. 특히 AWS RDS에서는 2026년 7월 말로 8.0 표준 지원이 끝나고 8월부터 유료 확장 지원으로 자동 전환되므로, 보안뿐 아니라 비용 측면에서도 업그레이드 유인이 큽니다. MySQL 8.0에서 8.4 LTS로 넘어가는 마이그레이션은 별도 글에서 다룰 예정입니다.

마무리

정리하면 이렇습니다. 신규 프로젝트는 12.3 LTS, 보수적으로 접근한다면 11.8(단, 2028년 6월 종료 유의), 10.6 이하는 즉시 업그레이드 계획 수립입니다. 롤링 릴리스는 검증용으로만 쓰고 운영 기준은 항상 LTS로 잡는 것이 관리 비용을 가장 줄이는 길입니다.

버전을 고르는 기준 자체가 낯설다면, 자바 쪽 기준을 정리한 2026년 Java 버전 선택 가이드도 함께 참고하세요. 언어든 데이터베이스든 "최신 LTS 기준 + 지원 종료 일정 역산"이라는 원칙은 같습니다.

참고 자료

• MariaDB Server 12.3 LTS Released — mariadb.org
• MariaDB 12.3 Changes & Improvements — MariaDB Documentation
• MariaDB Release Schedule — endoflife.date