PostgreSQL과 Oracle의 차이 — 데이터베이스와 스키마 구조부터 이해하기

한 줄 요약

PostgreSQL과 Oracle은 둘 다 SQL을 쓰는 관계형 데이터베이스지만, 데이터를 나누는 계층 구조가 달라요. 다만 데이터베이스를 나눈다고 해서 장애까지 나뉘는 것은 아니라는 점을 함께 이해해야 해요.

 

1. PostgreSQL이란

PostgreSQL은 오픈소스 관계형 데이터베이스 관리 시스템(RDBMS)이에요. SQL 표준을 따르기 때문에 SELECT, INSERT, JOIN 같은 문법은 Oracle과 대부분 같아요. 실제로 달라지는 지점은 문법이 아니라 구조와 운영 방식이에요.

RDBMS: 데이터를 표(테이블) 형태로 저장하고, 표들 사이의 관계로 관리하는 데이터베이스 시스템을 말해요.

RDBMS는 무슨 약자인가

RDBMS는 Relational Database Management System의 약자예요. 우리말로는 관계형 데이터베이스 관리 시스템이라고 해요. 단어별로 보면 이래요.

• Relational (관계형): 데이터를 표(테이블)로 저장하고, 표들 사이를 키로 연결해 관계를 표현해요.
• Database (데이터베이스): 구조화되어 저장된 데이터 모음이에요.
• Management System (관리 시스템): 그 데이터를 저장하고 조회하고 수정하도록 관리해주는 소프트웨어예요.

Oracle, PostgreSQL, MySQL이 모두 여기에 속해요.

참고로 DBMS는 여기서 Relational이 빠진 상위 개념이에요. 관계형이 아닌 데이터베이스(문서형, 키-값형 등)까지 포함해요.

 

2. 계층 구조 (가장 큰 차이)

PostgreSQL의 전체 계층은 클러스터 → 데이터베이스 → 스키마 → 테이블 순이에요. 클라이언트는 접속할 때 데이터베이스 이름을 반드시 지정해야 하고, 하나의 연결로는 데이터베이스를 하나만 볼 수 있어요.

[ Oracle ]

 데이터베이스 (인스턴스) 1개
  ├─ HR 스키마      ─┐
  ├─ SALES 스키마   ─┼─ 접속 하나로 서로 조회 가능
  └─ ADMIN 스키마   ─┘


[ PostgreSQL ]

 클러스터 (서버 프로세스 하나)
  ├─ 데이터베이스: shop
  │    ├─ public 스키마 → 테이블
  │    └─ order 스키마  → 테이블
  │
  └─ 데이터베이스: hr
       ├─ public 스키마  → 테이블
       └─ payroll 스키마 → 테이블

  ※ shop과 hr은 같은 연결로 조인할 수 없어요
  ※ 다만 서버가 멈추면 둘 다 함께 멈춰요

각 층의 역할은 이래요.

• 클러스터: 서버 프로세스 하나가 관리하는 전체 묶음이에요. 역할(role) 이름, 데이터베이스 이름, 테이블스페이스 이름은 클러스터 단위로 관리돼요.
• 데이터베이스: 서로 격리된 단위예요. 한 연결로 두 개 이상을 다룰 수 없어요.
• 스키마: 데이터베이스 안의 이름 공간이에요. 스키마끼리는 격리되지 않아서, 권한만 있으면 같은 데이터베이스 안의 다른 스키마 객체에 접근할 수 있어요. 기본 스키마 이름은 public이에요.

Oracle에서 스키마 하나가 맡던 역할을, PostgreSQL에서는 데이터베이스와 스키마가 나눠 맡는다고 보면 이해가 빨라요.

 

3. 쉽게 이해하는 설명

Oracle의 스키마는 한 건물 안의 사무실에 가까워요. 문은 나뉘어 있지만 열쇠(권한)만 있으면 복도로 바로 이동할 수 있어요.

PostgreSQL의 데이터베이스는 같은 건물 안의 서로 다른 층인데, 층간 통로가 막혀 있는 구조예요. 각 층 안에서는 사무실(스키마) 사이를 오갈 수 있지만, 다른 층으로는 한 번의 출입으로 갈 수 없어요.

여기서 놓치기 쉬운 부분이 있어요. 층이 나뉘어 있어도 건물은 하나예요. 건물 전기가 나가면 모든 층이 함께 멈춰요.

 

4. 유저 대신 역할(Role)

Oracle은 유저 하나가 곧 스키마 하나예요. PostgreSQL은 역할(role) 이라는 개념 하나로 유저와 그룹을 함께 다뤄요.

주의할 점은 역할 이름이 클러스터 전체에서 공유된다는 거예요. 같은 클러스터 안의 서로 다른 데이터베이스에 같은 이름의 다른 역할을 만들 수는 없어요. 다만 특정 역할이 일부 데이터베이스에만 접근하도록 설정하는 것은 가능해요.

 

5. 자주 하는 오해 — 나누면 장애도 나뉘는가

데이터베이스를 나눠도 장애는 나뉘지 않아요.

PostgreSQL에서 데이터베이스를 여러 개 만들어도, 서버 프로세스 하나가 클러스터 전체를 관리해요. 그 서버가 멈추면 안에 있던 데이터베이스가 전부 함께 멈춰요. shop은 살아 있고 hr만 죽는 식으로 동작하지 않아요.

공식 문서도 이 점을 명시해요. 클러스터 안의 각 데이터베이스는 사용자 관점에서는 격리되어 있지만, 데이터베이스 관리자 관점에서는 서로 밀접하게 묶여 있다고 설명해요. 그리고 WAL을 공유하기 때문에 백업과 복구 방식에 영향을 준다는 점을 별도로 짚어두고 있어요.

WAL(Write-Ahead Log): 변경 내용을 먼저 기록해두는 로그로, 장애 발생 시 복구의 기준이 되는 파일이에요.

그래서 두 가지를 구분해야 해요.

구분	뜻	데이터베이스 분리로 얻을 수 있는가
논리적 격리	이름·권한·접근 범위가 나뉨	얻을 수 있음
장애 격리	하나가 멈춰도 다른 쪽은 동작	얻을 수 없음

 

6. 그럼 데이터베이스는 왜 나누는가

목적은 장애 대비가 아니라 관리 단위 분리예요.

• 이름 충돌이 없어요. 서로 무관한 시스템이 같은 테이블명을 써도 문제되지 않아요.
• 권한을 데이터베이스 단위로 끊을 수 있어요. 다른 시스템의 테이블을 실수로 건드릴 여지가 줄어요.
• 논리 백업(pg_dump)의 기본 단위가 데이터베이스라서, 시스템 하나만 떠서 옮기기가 깔끔해요.

공식 문서의 판단 기준은 이래요.

• 서로 무관한 프로젝트나 사용자 → 데이터베이스를 나눠요.
• 서로 자원을 공유해야 하는 관계 → 같은 데이터베이스 안에서 스키마로 나눠요.

단서도 붙어 있어요. 한 클러스터 안에 데이터베이스를 여러 개 만들 때는 이점이 위험과 제약보다 큰지 신중히 따져보라는 내용이에요.

 

7. 장애를 견디게 하려면

이건 데이터베이스를 나누는 문제가 아니라 서버를 나누거나 이중화하는 문제예요.

• 완전히 분리하려면 클러스터(서버) 자체를 별도로 띄워야 해요.
• 같은 데이터를 살려두려면 복제와 장애 조치(failover) 구성이 필요해요. PostgreSQL에는 스트리밍 복제 기능이 있고, Oracle에는 RAC나 Data Guard 같은 구성이 있어요.

그래서 "Oracle은 하나로 묶여 있어서 죽으면 다 죽는다"는 말도 구성에 따라 달라져요. RAC로 구성하면 노드 하나가 멈춰도 서비스가 유지돼요. 어느 쪽이든 분리 여부가 아니라 이중화 여부가 장애 대응을 결정해요.

 

8. 문법·타입 차이 정리

구분	Oracle	PostgreSQL
라이선스	상용 (무료 XE 에디션 별도)	오픈소스, 무료
계층 구조	데이터베이스 > 스키마(=유저) > 테이블	클러스터 > 데이터베이스 > 스키마 > 테이블
계정 개념	유저 = 스키마	역할(role), 클러스터 단위로 공유
절차 언어	PL/SQL	PL/pgSQL
페이징	ROWNUM, FETCH FIRST	LIMIT / OFFSET
문자 타입	VARCHAR2 주로 사용	varchar, text
빈 문자열	NULL로 취급	NULL과 구분

 

9. 핵심 정리

• PostgreSQL의 계층은 클러스터 → 데이터베이스 → 스키마 → 테이블이에요.
• 하나의 연결은 하나의 데이터베이스만 볼 수 있어요. 다른 데이터베이스와의 조인은 안 돼요.
• 데이터베이스 분리는 논리적 격리를 주지만, 장애 격리는 주지 않아요. 서버가 멈추면 전부 함께 멈춰요.
• 장애 대응은 분리가 아니라 이중화로 해결하는 영역이에요.
• 무관한 프로젝트는 데이터베이스로, 자원을 공유하는 관계는 스키마로 나누는 것이 공식 권장 기준이에요.

 

10. 추가 정보

주의사항

• Oracle 12c부터는 멀티테넌트 구조(CDB/PDB)를 제공해서, 하나의 컨테이너 데이터베이스 안에 여러 데이터베이스를 두는 구성도 가능해요. 위 비교는 전통적인 단일 데이터베이스 구성을 기준으로 한 설명이에요. 세부 동작은 사용 중인 Oracle 버전의 공식 문서에서 확인하시는 것을 권해요.
• 복제와 장애 조치 구성의 세부 동작은 버전과 구성 방식에 따라 크게 달라져요. 실제 적용 전에는 해당 버전의 공식 문서 확인이 필요해요.
• PL/SQL과 PL/pgSQL은 문법이 비슷해 보이지만 그대로 옮겨지지 않아요. 프로시저는 별도 변환 작업이 필요해요.