태그: #postgresql

← 전체 글

• CloudNativePG 딥다이브 — PostgreSQL 을 쿠버네티스 안에서 누가 돌보는가

  StatefulSet 을 쓰지 않는 이유, 파드의 PID 1 이 postgres 가 아닌 이유, 세 개의 서비스가 하는 일, 베이스 백업과 WAL 이 합쳐져야 복구가 되는 이유. 운영 클러스터의 실제 설정값으로 CNPG 의 기능과 역할을 뜯어 본다.

  2026-09-10 · 13 분 읽기 #kubernetes#postgresql#cloudnativepg#backup#operator

• 트랜잭션 격리 수준 완전 가이드: 데이터베이스가 아니라 애플리케이션이 책임지는 부분

  PostgreSQL 18의 네 가지 격리 수준을 문서 그대로 정리한 뒤, 그 위에서 애플리케이션이 반드시 구현해야 하는 것들을 다룹니다. 40001 직렬화 실패 재시도 계층, FOR UPDATE부터 FOR KEY SHARE까지 행 잠금 사다리와 SKIP LOCKED 큐 패턴, 어드바이저리 락, 긴 트랜잭션이 VACUUM을 막는 진짜 비용, 그리고 MySQL 8.4 InnoDB와 다르게 동작하

  2026-08-15 · 34 분 읽기 #데이터베이스#postgresql#트랜잭션#격리수준#동시성

• 파티셔닝과 샤딩 완전 가이드: 한 노드의 한계를 넘어가는 순서

  PostgreSQL 18의 선언적 파티셔닝을 기준으로 파티셔닝이 실제로 무엇을 해결하고 무엇을 해결하지 못하는지 정리한 뒤, 파티셔닝의 한계선에서 샤딩으로 넘어가는 판단 기준을 다룹니다. 파티션 프루닝, 파티션 키가 유일 제약에 거는 제한, 파티션 개수와 플래너 비용, 무중단 파티션 운영, 그리고 샤딩하는 순간 깨지는 교차 샤드 조인과 전역 유일성 문제까지 짚습니다.

  2026-08-15 · 34 분 읽기 #데이터베이스#postgresql#파티셔닝#샤딩#확장성

• 커넥션 풀 완전 가이드: 풀링 모드가 애플리케이션과 맺는 계약

  PostgreSQL 18과 PgBouncer를 기준으로 커넥션 풀을 계약의 관점에서 정리합니다. 세션·트랜잭션·문장 풀링 세 가지 모드가 각각 무엇을 보장하고 무엇을 포기하는지, 트랜잭션 풀링에서 준비된 문장과 SET, LISTEN/NOTIFY, 어드바이저리 락이 왜 깨지는지, 애플리케이션 풀과 PgBouncer와 maxconnections 사이의 삼중 예산을 어떻게 배분하는지, 그리고 타임

  2026-08-15 · 30 분 읽기 #데이터베이스#postgresql#pgbouncer#커넥션풀#운영

• SQL 실행계획 완전 가이드: 옵티마이저는 어떻게 계획을 고르는가

  PostgreSQL 18의 플래너 입장에서 실행계획을 설명합니다. 통계가 어떻게 수집되고, 선택도가 어떻게 계산되며, cost 숫자가 어떤 상수들로 조립되는지, 조인 순서 탐색이 언제 유전 알고리즘으로 넘어가는지, 추정이 틀어졌을 때 확장 통계로 어떻게 교정하는지, 그리고 준비된 문장의 일반 계획이 왜 갑자기 느려지는지까지 문서에 적힌 기본값과 함께 정리합니다.

  2026-08-15 · 31 분 읽기 #데이터베이스#postgresql#실행계획#쿼리최적화#옵티마이저

• DB 성능 튜닝 완전 가이드: 파라미터를 만지기 전에 측정하는 순서

  PostgreSQL 18을 기준으로 성능 튜닝을 파라미터 목록이 아니라 진단 순서로 정리합니다. pgstatstatements로 워크로드를 프로파일링하고, 대기 이벤트로 병목의 성격을 가르고, 캐시와 I/O 지표를 읽고, 그다음에야 메모리 예산과 체크포인트와 autovacuum을 조정하는 순서입니다. PostgreSQL 18에서 바뀐 기본값들과 변경 전후를 비교하는 방법까지 다룹니다.

  2026-08-15 · 32 분 읽기 #데이터베이스#postgresql#성능튜닝#모니터링#운영

• 데이터베이스 캐싱 전략 완전 가이드: 결국 무효화가 전부다

  PostgreSQL 18을 기준으로 캐시를 데이터베이스 쪽에서부터 올라가며 정리합니다. sharedbuffers와 운영체제 캐시라는 이미 존재하는 캐시 계층, 머티리얼라이즈드 뷰라는 계산 캐시, 그 위에 외부 캐시를 얹을지 판단하는 기준, 그리고 캐시 도입의 진짜 난제인 무효화의 네 가지 실패 모드와 쓰기 경로 순서 문제, 캐시 스탬피드 방어까지 다룹니다.

  2026-08-15 · 31 분 읽기 #데이터베이스#postgresql#캐시#성능튜닝#아키텍처

• 무중단 스키마 변경 완전 가이드: DDL이 잡는 잠금 등급과 안전 실행 절차

  PostgreSQL 18 문서를 기준으로 각 DDL이 실제로 어떤 잠금을 잡는지 등급별로 정리합니다. 여덟 가지 테이블 잠금 모드와 충돌 관계, ALTER TABLE 형태별 잠금 등급, 테이블 재작성을 유발하는 변경과 그렇지 않은 변경, NOT VALID와 VALIDATE CONSTRAINT로 제약을 두 단계로 나누는 방법, 그리고 locktimeout과 재시도를 결합한 안전 실행 절차를 다

  2026-08-15 · 29 분 읽기 #데이터베이스#postgresql#스키마변경#무중단배포#잠금

• PostgreSQL 인덱스 완전 가이드: 설계부터 폐기까지 인덱스의 수명 주기

  PostgreSQL 18을 기준으로 인덱스를 하나의 운영 자산으로 다룹니다. 어떤 컬럼을 어떤 순서로 넣을지 정하는 설계, 여섯 가지 인덱스 방식 중 하나를 고르는 판단, CONCURRENTLY로 안전하게 만드는 절차와 실패 복구, 정말 쓰이는지 확인하는 검증, 부풀어 오른 인덱스를 다시 만드는 운영, 그리고 되돌릴 수 있게 폐기하는 방법까지 수명 주기 순서로 정리합니다.

  2026-08-15 · 33 분 읽기 #데이터베이스#postgresql#인덱스#성능튜닝#운영

• 데이터 모델링 완전 가이드: 논리 모델에서 PostgreSQL 물리 모델까지 ♪ 들을 수 있어요

  PostgreSQL 18을 기준으로 논리 모델을 물리 스키마로 옮길 때 내려야 하는 결정들을 정리합니다. 대리 키와 식별자 타입 선택, text와 numeric과 timestamptz를 고르는 근거, 제약 조건을 코드로 다루는 방법, jsonb를 쓸 경계선, 이력과 유효 기간과 소프트 삭제의 표현, 정규화를 깨야 하는 순간과 그 대가, 그리고 컬럼 순서와 TOAST 같은 물리 배치까지 문서

  2026-08-15 · 36 분 읽기 #데이터베이스#postgresql#데이터모델링#스키마설계#제약조건

• 대용량 데이터 처리 완전 가이드: COPY, 청크 배치, 그리고 되돌릴 수 있는 작업

  PostgreSQL 18에서 수억 행을 적재하고 갱신하고 삭제하는 작업을 안전하게 수행하는 방법을 정리합니다. COPY의 옵션과 기본값, 문서가 권장하는 초기 적재 절차, ONERROR로 불량 행을 견디는 방법, 대량 UPDATE와 DELETE를 청크로 나누는 설계, 삭제 이후의 죽은 행 처리와 VACUUM FULL을 피해야 하는 이유, 그리고 재개 가능한 백필 작업을 만드는 방법까지 다룹니

  2026-08-15 · 33 분 읽기 #데이터베이스#postgresql#배치처리#데이터적재#운영

• 지금 주목받는 오픈소스 (3) 인프라와 데이터베이스

  데이터베이스와 인프라 영역은 라이선스 변경과 포크가 판을 다시 짠 분야입니다. 분석 엔진, 임베디드 데이터베이스, 포스트그레스 확장, 쿠버네티스 오퍼레이터, IaC까지 실제로 자리를 잡은 오픈소스 11개를 스타 순위가 아니라 해결하는 문제별로 묶어 소개합니다. 무엇을 대체하는지, 어느 정도 성숙했는지, 언제 쓰면 안 되는지를 함께 적었습니다. 저장소 경로와 라이선스, 스타 수, 최근 푸시는

  2026-08-12 · 9 분 읽기 #open-source#database#infrastructure#postgresql#kubernetes

• 300배는 PostgreSQL을 튜닝해서 나온 숫자가 아니다 — 화산 모델과 벡터화 실행

  pgrust 0.2 릴리스와 함께 공개된 300배라는 숫자를 정확히 해부합니다. 이 수치는 PostgreSQL 설정을 바꿔서 나온 것이 아니라 Rust로 새로 구현한 데이터베이스를 ClickBench에서 측정한 결과이며, 저자 본인이 별도로 제시한 SUM 쿼리 실험은 화산 모델 1.3초에서 SIMD 135밀리초까지 9.6배를 보여 줍니다. 배치, 연산자 융합, SIMD가 각각 무엇을 제거하는

  2026-08-09 · 15 분 읽기 #postgresql#database#performance#query-engine#simd

• EXPLAIN ANALYZE 읽는 법 — 실행 계획에서 진짜 병목을 찾는 순서

  EXPLAIN ANALYZE 출력을 처음부터 끝까지 읽는 방법을 정리합니다. 노드를 어떤 순서로 읽어야 하는지, cost가 왜 시간 단위가 아닌지, 예상 행 수와 실제 행 수의 괴리가 무엇을 알려 주는지, loops가 곱해지는 함정은 어떻게 피하는지 실제 출력과 함께 설명합니다. Nested Loop, Hash Join, Merge Join이 각각 선택되는 조건과 BUFFERS로 캐시 적중을

  2026-07-26 · 21 분 읽기 #database#postgresql#explain#query-optimization#performance

• 트랜잭션 격리 수준과 실제 이상 현상 — 표준 정의가 구현과 다른 지점

  트랜잭션 격리 수준 네 가지와 dirty read, non-repeatable read, phantom read를 정리하되, 교과서의 표 하나로 끝내지 않습니다. PostgreSQL의 Read Committed가 왜 처음부터 dirty read를 만들 수 없는지, Repeatable Read가 왜 사실은 스냅샷 격리이고 직렬화 실패를 애플리케이션이 재시도해야 하는지, MySQL InnoDB의

  2026-07-26 · 22 분 읽기 #database#postgresql#transaction#isolation-level#mysql

• 커넥션 풀 크기, 크게 잡으면 손해인 이유 — 대기열을 어디에 세울 것인가

  커넥션 풀을 키웠더니 오히려 느려지는 현상의 원리를 정리합니다. PostgreSQL의 프로세스 모델에서 커넥션이 왜 비싼지, 디스크와 CPU 병렬성이 유한하므로 대기열을 데이터베이스 안이 아니라 풀에 세우는 편이 나은 이유, 자주 인용되는 코어 수 기반 공식의 근거와 한계를 다룹니다. 마이크로서비스에서 인스턴스 수와 풀 크기의 곱이 최대 커넥션을 넘기는 전형적 사고, PgBouncer 세 가

  2026-07-26 · 26 분 읽기 #database#postgresql#connection-pool#pgbouncer#performance

• 인덱스를 만들었는데 안 타는 이유 — 옵티마이저가 맞고 내가 틀린 경우들

  인덱스를 만들었는데 실행 계획에 Seq Scan이 그대로 남는 이유를 원인별로 정리합니다. 선택도가 낮아서 옵티마이저가 일부러 무시하는 경우, 컬럼에 함수나 연산이 걸려 sargable하지 않은 경우, 타입 불일치로 암묵적 캐스팅이 일어나는 경우, LIKE 선행 와일드카드, OR 조건, 복합 인덱스 선두 컬럼 규칙, 통계 노후화, NULL 처리까지 실제 SQL과 실행 계획으로 확인합니다. 부

  2026-07-26 · 21 분 읽기 #database#postgresql#index#query-optimization#mysql

• 데드락 진단과 예방 — 로그에서 두 쿼리를 특정하는 법

  deadlock detected 오류를 만났을 때 무엇을 봐야 하는지 순서대로 정리합니다. PostgreSQL의 데드락 리포트와 MySQL의 SHOW ENGINE INNODB STATUS 출력을 한 줄씩 해석해 어느 두 쿼리가 엮였는지 특정하는 방법, 실무에서 반복되는 세 가지 패턴인 갱신 순서 불일치와 인덱스 부재로 인한 락 범위 확대와 외래 키가 유발하는 부모 행 잠금을 다룹니다. dea

  2026-07-26 · 25 분 읽기 #database#postgresql#deadlock#locking#mysql

• Postgres 19의 pg_plan_advice — 힌트를 거절해 온 프로젝트가 내놓은 타협안

  PostgreSQL 프로젝트는 오랫동안 옵티마이저 힌트를 거절해 왔습니다. 그런데 2026년 6월 4일 나온 PostgreSQL 19 Beta 1에 Robert Haas가 만든 pgplanadvice와 pgstashadvice가 contrib 모듈로 들어갔습니다. 이건 오라클식 힌트가 아닙니다 — 조언은 SQL 밖에 살고, 플래너를 대체하는 게 아니라 탐색 공간을 좁히기만 하며, 문서의 표현

  2026-07-16 · 26 분 읽기 #postgresql#query-planner#query-optimization#database#performance

• pgrust: Postgres를 Rust로 다시 쓰고 회귀 테스트 100%를 통과했다 — 그게 정말 뜻하는 것

  Malcolm Matis(malisper)가 Postgres를 Rust로 다시 쓴 pgrust를 공개했습니다. Postgres 18.3 호환을 목표로 4만6천 개가 넘는 회귀 테스트 쿼리를 통과하고, 실제 18.3 데이터 디렉터리에서 부팅됩니다. 이 글은 그 마일스톤이 왜 진짜로 인상적인지, 그리고 "회귀 테스트 100% 통과"가 무엇을 증명하고 무엇을 증명하지 않는지를 정직하게 뜯어봅니다.

  2026-07-11 · 12 분 읽기 #postgresql#rust#pgrust#database#regression-tests