MariaDB vs PostgreSQL vs Oracle — 실무에서 뭘 기준으로 선택할까

지난 글에서 PostgreSQL의 기본 구조와 SQL 쿼리를 다뤘는데, 실무에서는 MariaDB와 Oracle도 자주 마주치게 됩니다. 특히 금융권은 세 가지를 모두 만날 가능성이 높은 업계입니다. 셋 다 "관계형 데이터베이스"라는 큰 틀은 같지만, 태생과 라이선스, 실무 포지션이 완전히 달라서 실제 문법이나 선택 기준에 차이가 있습니다. 이번 글에서는 세 DB의 핵심 차이와, 실무에서 어떤 기준으로 선택하는지 정리해봅니다.

---

MariaDB는 MySQL 창시자들이 만든 MySQL의 분기(fork) 버전입니다. MySQL과 대부분 호환되기 때문에, 기존 MySQL 기반 서비스를 큰 수정 없이 옮겨올 수 있습니다. 웹 서비스, 이커머스처럼 "읽기 트래픽이 많고 구조가 비교적 단순한" 서비스에서 오랫동안 표준처럼 쓰여왔습니다. 완전 오픈소스라 라이선스 비용이 없습니다.

PostgreSQL은 처음부터 독자적으로 설계된 객체-관계형 DBMS입니다. SQL 표준을 폭넓게 지키고, 복잡한 데이터 타입이나 분석 기능을 기본적으로 지원하는 데 강점이 있습니다. 마찬가지로 오픈소스이면서도 기능이 풍부해서, 최근 Oracle을 대체하는 선택지로 자주 언급됩니다.

Oracle Database는 오랫동안 엔터프라이즈 DB 시장의 표준이었던 상용(유료) DBMS입니다. 은행, 보험사 같은 금융권의 계정계(핵심 거래 처리 시스템), 대기업 기간계 시스템에서 수십 년간 검증되며 쓰여왔습니다. 안정성과 벤더 기술지원이 강점이지만, 코어/사용자 기준으로 부과되는 라이선스 비용이 매우 높다는 점이 실무에서 자주 언급되는 부담입니다. 최근에는 이 비용 부담 때문에 PostgreSQL로 이관(탈脫오라클)을 검토하는 금융사도 늘고 있습니다.

 

 

자동 증가 기본 키

가장 먼저 체감되는 차이입니다.

 

sql

-- MariaDB (MySQL 문법과 동일)
CREATE TABLE users (
    id      INT AUTO_INCREMENT PRIMARY KEY,
    email   VARCHAR(255) NOT NULL UNIQUE,
    created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
);

 

sql

-- PostgreSQL
CREATE TABLE users (
    id      SERIAL PRIMARY KEY,
    email   VARCHAR(255) NOT NULL UNIQUE,
    created_at TIMESTAMP NOT NULL DEFAULT now()
);

 

sql

-- Oracle: 시퀀스를 직접 만들고 트리거나 NEXTVAL로 채움
CREATE SEQUENCE users_seq START WITH 1 INCREMENT BY 1;

CREATE TABLE users (
    id      NUMBER PRIMARY KEY,
    email   VARCHAR2(255) NOT NULL UNIQUE,
    created_at DATE DEFAULT SYSDATE NOT NULL
);

INSERT INTO users (id, email) VALUES (users_seq.NEXTVAL, 'kim@example.com');

• MariaDB는 AUTO_INCREMENT 속성을 컬럼에 직접 붙이는 방식이고, 테이블당 하나만 가능합니다.
• PostgreSQL은 SERIAL이 내부적으로 시퀀스(Sequence)라는 별도 객체를 만들어 관리합니다.
• Oracle은 시퀀스를 명시적으로 만들고, NEXTVAL을 직접 호출해서 값을 채우는 방식입니다. (Oracle 12c부터는 GENERATED AS IDENTITY 문법으로 더 간단하게 쓸 수도 있습니다.)

INSERT 후 결과 바로 받기

 

sql

-- MariaDB: 별도 조회 필요
INSERT INTO users (email) VALUES ('kim@example.com');
SELECT LAST_INSERT_ID();

 

sql

-- PostgreSQL: RETURNING으로 한 번에
INSERT INTO users (email) VALUES ('kim@example.com')
RETURNING id, created_at;

 

sql

-- Oracle: RETURNING INTO로 변수에 담아 받음 (PL/SQL 블록 안에서)
INSERT INTO users (id, email)
VALUES (users_seq.NEXTVAL, 'kim@example.com')
RETURNING id, created_at INTO v_id, v_created_at;

PostgreSQL의 RETURNING은 지난 글에서 다룬 것처럼 쿼리 한 번으로 끝낼 수 있어 편리합니다. Oracle도 RETURNING ... INTO 구문으로 비슷한 기능을 제공하지만, PL/SQL 변수에 담아야 해서 순수 SQL만으로는 쓰기 어렵습니다. MariaDB는 LAST_INSERT_ID()처럼 별도 함수를 한 번 더 호출해야 합니다.

페이징 문법

 

sql

-- MariaDB / PostgreSQL (동일)
SELECT * FROM posts
ORDER BY created_at DESC
LIMIT 20 OFFSET 40;

 

sql

-- Oracle 12c 이상
SELECT * FROM posts
ORDER BY created_at DESC
OFFSET 40 ROWS FETCH NEXT 20 ROWS ONLY;

-- Oracle 레거시 방식 (ROWNUM, 12c 이전에도 가능)
SELECT * FROM (
    SELECT a.*, ROWNUM rnum FROM (
        SELECT * FROM posts ORDER BY created_at DESC
    ) a WHERE ROWNUM <= 60
) WHERE rnum > 40;

MariaDB와 PostgreSQL은 LIMIT/OFFSET으로 간단하지만, Oracle은 버전에 따라 문법이 크게 갈립니다. 레거시 Oracle 프로젝트에서는 아직도 ROWNUM 방식의 중첩 쿼리를 자주 보게 됩니다.

문자열 결합

 

sql

-- MariaDB
SELECT CONCAT(first_name, ' ', last_name) AS full_name FROM users;

-- PostgreSQL
SELECT first_name || ' ' || last_name AS full_name FROM users;

-- Oracle
SELECT first_name || ' ' || last_name AS full_name FROM users;

|| 연산자는 PostgreSQL과 Oracle이 공유하는 SQL 표준 방식입니다. MariaDB는 CONCAT() 함수 방식이 기본입니다.

날짜/시간 다루기

 

sql

-- MariaDB: 오늘 날짜에서 7일 전
SELECT * FROM orders WHERE created_at >= DATE_SUB(NOW(), INTERVAL 7 DAY);

-- PostgreSQL: 오늘 날짜에서 7일 전
SELECT * FROM orders WHERE created_at >= NOW() - INTERVAL '7 days';

-- Oracle: 오늘 날짜에서 7일 전
SELECT * FROM orders WHERE created_at >= SYSDATE - 7;

Oracle은 날짜에 숫자를 그냥 더하고 빼는 것만으로 일 단위 연산이 가능합니다 (내부적으로 날짜가 숫자로 취급됩니다).

존재하지 않는 테이블에서 값 하나만 조회하기

 

sql

-- Oracle: FROM 절이 필수라서 DUAL이라는 가상 테이블을 사용
SELECT SYSDATE FROM DUAL;
SELECT users_seq.NEXTVAL FROM DUAL;

 

sql

-- MariaDB / PostgreSQL: FROM 없이 바로 조회 가능
SELECT NOW();

Oracle의 독특한 문법 중 하나로, SELECT에는 반드시 FROM이 있어야 하기 때문에 DUAL이라는 1행짜리 더미 테이블을 관습적으로 사용합니다.

 

JSON, 배열 같은 확장 타입

PostgreSQL은 컬럼 타입으로 JSON, 배열, 지리정보(PostGIS) 등을 폭넓게 지원합니다.

 

sql

-- PostgreSQL: JSONB 컬럼과 조회
CREATE TABLE products (
    id      SERIAL PRIMARY KEY,
    name    VARCHAR(200),
    options JSONB
);

SELECT name, options->>'color' AS color
FROM products
WHERE options->>'color' = 'red';

MariaDB도 JSON 타입을 지원하지만(10.2+), PostgreSQL만큼 다양한 연산자와 인덱싱 방식을 제공하지는 않습니다. Oracle도 21c 이후 JSON 전용 타입을 지원하지만, 레거시 시스템에서는 여전히 CLOB에 JSON 문자열을 넣는 방식이 흔합니다.

동시성 제어 (MVCC)

세 DB 모두 MVCC(다중 버전 동시성 제어) 계열 방식을 씁니다. PostgreSQL은 이 구현이 일관되고 정교하다는 평가를 받고, Oracle 역시 오랜 시간 대규모 트랜잭션 환경에서 검증되어 온 강점이 있습니다. 복잡한 트랜잭션이 자주 얽히는 도메인(결제, 정산 등)에서 둘 다 선호되는 반면, MariaDB(InnoDB 엔진)는 상대적으로 단순한 트랜잭션 처리에 최적화되어 있습니다.

CTE(공통 테이블 표현식)

 

sql

-- 재귀 쿼리로 조직도 계층 조회 (PostgreSQL / Oracle 문법 유사)
WITH RECURSIVE org_chart AS (
    SELECT id, name, manager_id, 1 AS level
    FROM employees
    WHERE manager_id IS NULL

    UNION ALL

    SELECT e.id, e.name, e.manager_id, oc.level + 1
    FROM employees e
    JOIN org_chart oc ON e.manager_id = oc.id
)
SELECT * FROM org_chart;

PostgreSQL은 오래전부터 WITH RECURSIVE를 안정적으로 지원해왔고, Oracle은 CONNECT BY 라는 독자적인 계층 쿼리 문법을 먼저 가지고 있었습니다 (표준 WITH RECURSIVE도 이후 지원). MariaDB는 최신 버전(10.2+)부터 CTE를 지원하지만, 지원 시작 시점이 늦었던 만큼 레거시 환경에서는 아직 못 쓰는 경우도 있습니다.

 

sql

-- Oracle 고유의 계층 쿼리 문법
SELECT id, name, level
FROM employees
START WITH manager_id IS NULL
CONNECT BY PRIOR id = manager_id;

 

상황선택하기 좋은 DB

읽기 트래픽이 많은 일반 웹/커머스 서비스	MariaDB
기존 MySQL 시스템을 그대로 마이그레이션	MariaDB
복잡한 분석·통계 쿼리가 자주 필요	PostgreSQL
JSON 등 유연한 데이터 구조가 필요	PostgreSQL
Oracle을 오픈소스로 대체하려는 경우	PostgreSQL
이미 Oracle 기반으로 구축된 핵심계 시스템	Oracle
극도로 높은 안정성과 벤더 기술지원이 필요할 때	Oracle
서버 리소스가 적어 가벼운 DB가 필요	MariaDB

실무에서는 "정답"이 정해져 있다기보다, 기존에 어떤 DB로 구축되어 있는지, 팀에 어떤 노하우가 쌓여 있는지, 라이선스 비용을 어디까지 감당할 수 있는지가 선택에 큰 영향을 줍니다. 금융권은 특히 이 세 가지가 공존하는 경우가 많습니다 — 오래된 계정계는 Oracle로, 최근 신설된 정보계·채널계 시스템은 PostgreSQL이나 MariaDB로 구축되는 식입니다. "차세대 프로젝트"라는 이름으로 Oracle 기반 시스템을 PostgreSQL로 이관하는 작업도 최근 업계에서 자주 언급되는 흐름입니다.

---

마무리

MariaDB, PostgreSQL, Oracle은 "더 좋고 나쁜" 관계가 아니라, 서비스 특성과 조직 상황에 맞춰 고르는 도구입니다. MariaDB는 가볍고 익숙한 MySQL 생태계를, PostgreSQL은 비용 없이도 정교한 기능을, Oracle은 오랜 시간 검증된 안정성과 지원을 각각 강점으로 가집니다. 특히 금융권을 준비하고 있다면 세 DB의 문법 차이와 함께, "왜 이 시스템은 아직 Oracle을 쓰고, 저 시스템은 PostgreSQL로 옮겨가는지"까지 이해해두면 실무 감각을 훨씬 빠르게 따라갈 수 있습니다.