PostgreSQL
The World's Most Advanced Open Source Relational Database
중년개발자
@loxo
PostgreSQL을 제대로 이해하게 만드는 명글 6선
PostgreSQL을 제대로 이해하게 만드는 명문 6선 여러 자료를 살펴본 결과, 단순한 기능 나열보다 “PostgreSQL은 왜 이렇게 동작하는가”를 알려주는 글들이 오래 남습니다. 딱 하나만 읽는다면 PostgreSQL Wiki의 〈Don’t Do This〉, 성능까지 공부한다면 〈Use The Index, Luke〉를 가장 먼저 추천합니다. PostgreSQL 개발자의 실전 금기사항 Don’t Do This — PostgreSQL Wiki PostgreSQL을 사용하면서 습관적으로 내리는 잘못된 선택을 모은 글입니다. 짧지만 실무 영향력은 가장 큽니다. 핵심 내용은 다음과 같습니다. 문자열은 무조건 varchar(100)으로 만들 필요가 없다. text, varchar, varchar(n)은 같은 문자열을 저장할 때 공간과 성능 차이가 사실상 없다. 길이 제한이 비즈니스 규칙이라면 CHECK 제약조건이 의도를 더 명확히 표현한다. 새로운 테이블에서는 serial보다 표준
0
0
53
중년개발자
@loxo
PostgreSQL 19의 그래프 기능, 쉽게 이해하기
PostgreSQL 19의 그래프 기능, 쉽게 이해하기 PostgreSQL 19에는 Property Graph(속성 그래프) 기능이 추가됩니다. 한 문장으로 정의하면 다음과 같습니다. 기존 PostgreSQL 테이블을 그대로 두고, 테이블의 행을 정점(Vertex), 테이블 사이의 관계를 간선(Edge)으로 바라보며 검색하는 기능입니다. 별도의 그래프 데이터베이스나 PostgreSQL 확장 기능 없이, 국제 SQL 표준인 SQL/PGQ(SQL Property Graph Queries) 방식으로 그래프 질의를 사용할 수 있게 된 것입니다. 다만 2026년 7월 24일 기준 PostgreSQL 19는 Beta 2 단계이며, 정식 버전은 2026년 9~10월경 출시될 예정입니다. 아직 운영 환경보다는 학습과 검증 목적으로 접근하는 것이 좋습니다. PostgreSQL 19 Beta 2 공식 발표 여기서 말하는 그래프란? 차트나 통계 그래프를 말하는 것이 아닙니다. 사람, 상품, 계좌 같은
0
0
56
중년개발자
@loxo
PostgreSQL 19 Beta, 개발자가 주목해야 하는 이유
PostgreSQL 19 Beta, 개발자가 주목해야 하는 이유 PostgreSQL 19 Beta를 일반적인 웹 개발자와 백엔드 개발자의 시점에서 쉽게 이해해보자. PostgreSQL 19 Beta란? PostgreSQL은 오픈소스 데이터베이스(DBMS) 중 가장 강력한 제품 중 하나입니다. 현재 많은 서비스들이 카카오 당근 쿠팡 토스 네이버 다양한 스타트업 등에서 PostgreSQL을 사용하고 있습니다. 이번 PostgreSQL 19 Beta는 정식 버전이 출시되기 전에 기능을 미리 공개한 버전입니다. 베타 버전은 실제 서비스보다는 테스트 및 기능 검증을 위한 버전이며, 올해 정식 출시가 예정되어 있습니다. 한 줄 요약 PostgreSQL 19는 "더 빠르고, 더 똑똑하고, 운영하기 쉬운 데이터베이스"를 만드는 데 집중한 버전입니다. 개발자가 가장 체감하는 변화 조회 속도가 더욱 빨라진다. 가장 먼저 체감하는 부분입니다. 예를 들어 sql SELECT * FROM orders
0
0
87
중년개발자
@loxo
#11 - EXPLAIN ANALYZE(큰 테이블이 작은 테이블을 만났을 때, DB는 어떻게 행동할까?)
실행 계획을 이해하는 감각 만들기 이제부터는 EXPLAIN ANALYZE를 왜 이렇게 나왔는지 납득하는 단계로 들어간다. 숫자와 용어를 외우는 게 아니라, 데이터 크기와 접근 방식의 이야기로 이해하면 훨씬 편하다. Seq Scan이 선택되는 진짜 이유 Seq Scan은 말 그대로 테이블을 처음부터 끝까지 읽는 방식이다. 많이들 이렇게 생각한다. Seq Scan = 인덱스를 못 써서 생긴 문제 하지만 PostgreSQL 입장에서는 전혀 다르다. PostgreSQL이 Seq Scan을 고르는 논리 DB는 항상 이렇게 계산한다. 인덱스를 타면 인덱스 페이지 읽고 테이블 페이지 다시 읽고 랜덤 I/O가 많이 발생 Seq Scan을 하면 테이블 페이지를 순서대로 쭉 읽음 디스크, 캐시 입장에서 매우 효율적 그래서: 전체 row 중 많은 비율을 읽어야 한다면 인덱스가 있어도 Seq Scan이 더 빠를 수 있다 실생활 비유 책에서 단어 하나 찾기: 단어가 2~3개만 필요 → 목차(인덱스) 사용
0
0
161
중년개발자
@loxo
#10 - EXPLAIN ANALYZE 제대로 읽기
PostgreSQL 성능 문제의 90%는 여기서 시작해서 여기서 끝난다 EXPLAIN ANALYZE는 처음 보면 외계어처럼 느껴지기 쉽다. 하지만 관점을 조금만 바꾸면, 이건 DB가 직접 써주는 성적표에 가깝다. 이 글에서는 "모든 숫자를 이해하려 하지 말고, 무엇을 먼저 봐야 하는지"에 집중한다. sql QUERY PLAN | -----------------------------------------------------------------------------------------------------------------------------------------------------------------+ Nested Loop (cost=0.42..14.33 rows=69 width=563) (actual time=0.087..0.198 rows=52 loops=1) | -> Index Only Scan using boards_pkey on boards b
0
0
149
중년개발자
@loxo
#9 - WSL PostgreSQL 17 Master-Replica 구축 가이드
WSL PostgreSQL 17 Master-Replica 구축 가이드 이 문서는 WSL 2 환경에서 Debian 배포판을 복제하여 PostgreSQL 17 Streaming Replication을 구축하는 전체 절차를 다룹니다. 📋 환경 및 전제 조건 Infrastructure: WSL 2 (Windows Subsystem for Linux) Base Image: Debian (기존에 설치된 배포판) Network: WSL은 모든 인스턴스가 127.0.0.1을 공유함. 따라서 포트로 구분. Master: Port 5432 / Tablespace: /var/lib/postgresql/ts_data Replica: Port 5433 / Tablespace: /var/lib/postgresql/ts_data 1단계: WSL 인스턴스 준비 (Export & Import) Windows PowerShell(관리자 권한)에서 실행합니다. 1.1 기존 배포판 내보내기 기존 Debian
0
0
145
중년개발자
@loxo
#8 - PgBouncer 실전 운영 챕터 - Spring Boot 읽기·쓰기 분리 전략
PgBouncer 실전 운영 챕터 Master / Replica 분리, DNS 설계, Spring Boot 읽기·쓰기 분리 전략 이 챕터의 전제 (중요) 이 문서는 PgBouncer 공식 문서의 동작 원리를 기반으로, PostgreSQL Master / Replica 구조 DNS 또는 엔드포인트 분리 PgBouncer databases 섹션 설계 Spring Boot 입장에서의 쓰기 / 읽기 분리 전략 을 실제 운영에서 가장 많이 쓰이는 방식으로 정리한 실전 가이드다. 목표는 "개념 설명"이 아니라 운영자가 그대로 가져다 쓸 수 있는 설정이다. PostgreSQL Master / Replica 구조 복습 PostgreSQL 자체는 Read / Write 분리를 자동으로 해주지 않는다. Write → 반드시 Master Read → Replica 여러 대로 분산 가능 따라서 분리는 반드시 애플리케이션 또는 미들웨어 계층에서 수행해야 한다. PgBouncer의 핵심 한계 (중요한 오해
0
0
132
중년개발자
@loxo
#7 - PgBouncer로 이해하는 대규모 PostgreSQL 커넥션 풀링
PgBouncer로 이해하는 대규모 PostgreSQL 커넥션 풀링 대규모 PostgreSQL 운영 사례 OpenAI는 PostgreSQL을 단일 Master + 약 50대 Replica(Read Only) 구조로 확장 운영하고 있는 것으로 공개적으로 알려져 있습니다. 이 구조의 핵심은 쓰기와 읽기의 분리, 그리고 연결(Connection) 관리의 효율화입니다. PostgreSQL은 구조적으로 클라이언트 연결 1개당 서버 백엔드 프로세스 1개를 생성합니다. 이는 안정성과 단순성 측면에서는 훌륭하지만, 대규모 트래픽 환경에서는 매우 비싼 비용 구조가 됩니다. 이 문제를 해결하기 위해 OpenAI를 포함한 대규모 서비스들은 PgBouncer 같은 외부 커넥션 풀러(Connection Pooler) 를 필수 인프라로 사용합니다. PostgreSQL 커넥션은 왜 비싼가? PostgreSQL은 Thread 기반이 아니라 Process 기반 구조 커넥션 1개 = OS 프로세스 1개 각
0
0
136
중년개발자
@loxo
#6 - PostgreSQL VACUUM (배큠) - ‘청소’이자 ‘건강검진’이다.
PostgreSQL VACUUM 가이드 🔊 발음: VACUUM = [배큠] / [배큐엄] (실무에서는 보통 배큠) VACUUM은 PostgreSQL에서 ‘청소’이자 ‘건강검진’이다. 언제 실행되는지, 안 하면 뭐가 문제인지, 운영자는 무엇만 챙기면 되는지 완전 초보 관점에서 설명한다. 1️⃣ VACUUM은 왜 필요한가? 지난 강의에서 CTID는 row의 물리적 주소이며, UPDATE 시 새로운 CTID로 이동한다는 것을 배웠다. 이 흐름의 연장선에서 이해해야 할 핵심이 바로 다음 문장이다. PostgreSQL은 UPDATE / DELETE 시 바로 지우지 않는다. UPDATE → 기존 row는 Dead Tuple DELETE → 바로 제거 ❌, 죽음 표시만 mermaid flowchart LR A[INSERT] --> B[Tuple] B -->|UPDATE/DELETE| C[Dead Tuple] C -->|VACUUM| D[Space Reused] 📌 핵심 VACUUM이 없으면
0
0
127
중년개발자
@loxo
#5 - PostgreSQL Heap Page(8KB)와 CTID - 이해가 쉬운 설명
PostgreSQL Heap Page(8KB)와 CTID PostgreSQL를 처음 배우면 CTID가 뭐지? 왜 페이지가 8KB야?에서 많이 막힙니다. 이 문서는 DB 내부 동작을 모른다는 전제에서, 눈으로 그려지듯 이해하도록 설명합니다. 1️⃣ PostgreSQL Heap이란? PostgreSQL에서 테이블은 곧 Heap입니다. Heap = 정렬되지 않은 데이터 덩어리 INSERT 순서대로 막 쌓임 인덱스가 없으면 전부 Heap Scan 📌 즉, PostgreSQL은 기본적으로 "책장 없이 바닥에 쌓아둔 종이더미" 같은 구조입니다. 2️⃣ 왜 Page 크기는 8KB일까? PostgreSQL의 기본 Page(Block) 크기: 8 KB (8192 bytes) 이유 요약 디스크 I/O 최소 단위 OS 메모리 페이지와 궁합이 좋음 너무 크면 낭비, 너무 작으면 I/O 폭증 👉 "가성비 최적" 사이즈 3️⃣ Heap Page 내부 구조 (핵심) 하나의 Heap Page(8KB)는
0
0
130
mstest404
@mstest404
test123
풀스택 개발자를 위한 DB-백엔드-프론트엔드 통합 기술 지식 제공, PostgreSQL, Spring Boot, Next.js 기반의 실전 연동 아키텍처 가이드, 백엔드 개발자의 성능 고민을 해결해 주는 SQL 및 서버 튜닝 노하우, 프론트엔드 엔지니어를 위한 데이터 효율적 호출 및 시각화 기술, "Deep Insight" 슬로건 기반의 심도 있는 풀스택 기술 아티클 제공, 입문자부터 전문가까지 단계별로
0
1
126
중년개발자
@loxo
#4 - PostgreSQL WAL · INSERT · SELECT · 디스크 관계 정리
PostgreSQL WAL · INSERT · SELECT · 디스크 관계 정리 이 문서는 PostgreSQL 내부에서 INSERT, SELECT, WAL, 디스크가 어떻게 상호작용하는지를 흐름 중심으로 정리한 자료다. PostgreSQL의 핵심 구성 요소 PostgreSQL에서 데이터 흐름을 이해하려면 아래 3가지를 반드시 구분해야 한다. 1️⃣ Shared Buffer (메모리) 실제 쿼리가 읽고 쓰는 대상 INSERT / UPDATE / DELETE / SELECT 모두 여기서 수행됨 디스크 데이터 파일의 캐시 역할 2️⃣ Data File (디스크) 테이블의 실제 물리 파일 즉시 쓰이지 않음 (비동기) Checkpoint 시점에 반영 3️⃣ WAL (Write-Ahead Log) "무슨 변경을 할지" 기록하는 로그 데이터 자체가 아닌 변경 내역 기록 복구, 복제, 안정성의 핵심 조회용으로 사용되지 않음 INSERT 한 번의 정확한 내부 흐름 아래 순서는 PostgreSQL의
0
0
128