MySQL vs PostgreSQL — 2026년 기준 완전 비교 가이드
새 프로젝트의 데이터베이스를 선택해야 한다. MySQL vs PostgreSQL. 두 데이터베이스 모두 무료이고, 안정적이며, 대규모 프로덕션 환경에서 검증되었다. 그런데 왜 고민이 되는가? 내부 구현 방식이 ...
새 프로젝트의 데이터베이스를 선택해야 한다. MySQL vs PostgreSQL. 두 데이터베이스 모두 무료이고, 안정적이며, 대규모 프로덕션 환경에서 검증되었다. 그런데 왜 고민이 되는가? 내부 구현 방식이 ...
데이터베이스 서버가 한 대뿐이라면, 그 서버가 멈추는 순간 서비스 전체가 멈춘다. MySQL 복제는 이 단일 장애 지점(SPOF)을 없애기 위한 핵심 메커니즘이다. 단순히 백업용 서버를 한 대 더 두는 개념에서...
쿼리가 느리다는 신고가 들어왔다. 로그를 보면 SELECT 하나가 3초를 넘기고 있다. 어디서 시간이 소비되는지 모른 채 인덱스를 마구 추가하거나, 쿼리를 감으로 바꾸는 것은 도박이다. MySQL의 EXPLAI...
서비스가 운영 중인 데이터베이스의 스키마를 바꾸는 일은 달리는 기차 위에서 바퀴를 교체하는 것과 같다. 기차를 멈추면(서비스 중단) 간단하지만, 대부분의 서비스는 그 선택지가 없다. 무중단으로 스키마를 변경하는...
데드락 발생 원리부터 InnoDB 내부 메커니즘, 탐지/예방 전략, 실전 트러블슈팅까지
CAP 정리부터 워크로드 분석, 데이터 모델링, 확장 전략까지 — 시니어 개발자의 DB 선택 프레임워크
계좌 이체 도중 잔액을 조회하면 어떤 값이 보여야 하는가? 격리 수준이 낮으면 존재하지 않는 돈을 보거나, 방금 있던 돈이 사라지거나, 없던 행이 유령처럼 나타난다. 이 글은 ACID의 내부 보장 메커니즘부터 ...
비유로 시작하기
비유로 시작하기
비유로 먼저 이해하기: 데이터베이스를 식당에 비유하면, MySQL은 빠르고 친숙한 패스트푸드점, PostgreSQL은 다양한 메뉴와 재료를 갖춘 파인다이닝, Oracle은 규모와 신뢰성을 갖춘 대형 호텔 ...
회원 테이블 1,000만 건에서 이메일 하나를 조회하는 데 5초가 걸렸다. 인덱스 하나를 추가했더니 3ms로 줄었다. 왜 이런 일이 벌어지는지, 단순히 “인덱스를 걸면 빠르다”는 수준을 넘어 B+Tree 내부 ...
단일 MySQL 서버가 쓰기 TPS 한계에 부딪혔다. 읽기는 레플리카로 분산했지만 INSERT/UPDATE는 여전히 Primary 한 대가 감당한다. 수직 확장(더 좋은 서버)은 이미 96코어 / 384GB R...
인덱스를 분명히 걸었는데 EXPLAIN을 보니 Full Table Scan이다. 옵티마이저가 인덱스보다 풀스캔이 더 빠르다고 판단한 것이다. 왜 그런 선택을 했는지 이해하지 못하면 힌트를 줄 수도, 통계를 갱신...
“커넥션 풀 쓰면 빠르죠.” — 이 한 줄은 면접에서 0점이다. 왜 커넥션 하나를 여는 데 10ms가 걸리는지, HikariCP가 내부에서 어떤 자료구조로 락 없이 커넥션을 건네는지, 풀 사이즈를 왜 스레드 수...
비유로 시작하기
재고 1개짜리 상품에 10만 명이 동시에 주문을 쏟아냈다. 락 설계가 잘못되면 재고는 음수가 되고, 너무 강하면 시스템은 멈춰버린다. 락은 정합성과 성능 사이의 균형이다. 이 글에서는 InnoDB가 내부적으로 ...
프로덕션 장애 상황을 상상해 보자. 트래픽이 평소와 같은데 특정 쿼리의 p99 레이턴시가 갑자기 500ms에서 5초로 튀었다. 코드는 배포된 것이 없다. DBA를 불러 SHOW ENGINE INNODB STAT...