<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Waylog Blog · Database</title>
    <link>https://waylog.pages.dev/category/database</link>
    <description>Waylog Blog의 Database 카테고리에 속한 글 모음</description>
    <language>ko-KR</language>
    <lastBuildDate>Thu, 21 May 2026 13:50:29 GMT</lastBuildDate>
    <pubDate>Tue, 17 Feb 2026 00:00:00 GMT</pubDate>
    <generator>Next.js</generator>
    <atom:link href="https://waylog.pages.dev/category/database/rss.xml" rel="self" type="application/rss+xml"/>
    <item>
      <title>SQLite를 프로덕션에서 쓴다는 것: libSQL·Turso·WAL 모드로 서버리스 아키텍처 재설계하기</title>
      <link>https://waylog.pages.dev/posts/sqlite-embedded-production-libsql-turso</link>
      <guid isPermaLink="true">https://waylog.pages.dev/posts/sqlite-embedded-production-libsql-turso</guid>
      <pubDate>Tue, 17 Feb 2026 00:00:00 GMT</pubDate>
      <category>Database</category>
      <description>SQLite가 프로덕션용으로 적합한 워크로드 SQLite를 프로덕션에서 쓴다는 말을 꺼내면 종종 이런 반응이 돌아옵니다. &quot;그거 테스트용 아닌가요?&quot; 2026년 현재, 이 인식은 현실과 상당히 멀어져 있습니다. SQLite는 전 세계에서 가장 많이 배포된 데이터베이스 엔진이고, Android 기기, iOS 앱, 브라우저의 Web Storage, 항공기 시스템까지 광범위하게 쓰입니다. SQLite가 프로덕션에서 강점을 발휘하는 워크로드는 분명합니다. 읽기 중심의 콘텐츠 서비스, 한 테넌트당 데이터베</description>
    </item>
    <item>
      <title>MongoDB 인덱스 설계 실전: explain() 분석, 복합 인덱스 ESR 규칙, Partial·Sparse 인덱스 선택 기준</title>
      <link>https://waylog.pages.dev/posts/mongodb-index-strategy-explain-compound-partial</link>
      <guid isPermaLink="true">https://waylog.pages.dev/posts/mongodb-index-strategy-explain-compound-partial</guid>
      <pubDate>Mon, 26 Jan 2026 00:00:00 GMT</pubDate>
      <category>Database</category>
      <description>인덱스가 없으면 느리고, 잘못 만들면 더 느리다 MongoDB를 프로덕션에서 처음 운영해보는 팀은 대개 비슷한 경험을 합니다. 로컬에서는 순식간에 응답하던 쿼리가 실 데이터가 수백만 건을 넘어서면서 갑자기 수 초씩 걸리기 시작하고, &quot;인덱스를 추가하면 되겠지&quot;라는 생각에 db.collection.createIndex()를 몇 개 추가하지만 기대한 만큼 빨라지지 않습니다. 우리 팀이 e커머스 주문 플랫폼에서 일 평균 600만 건의 주문 도큐먼트를 처리하던 시절, 정산 배치가 매일 밤 orders 컬</description>
    </item>
    <item>
      <title>PostgreSQL 파티셔닝 운영 가이드: Partition Pruning·인덱스·보관주기까지 실전 설계</title>
      <link>https://waylog.pages.dev/posts/postgresql-partitioning-pruning-retention</link>
      <guid isPermaLink="true">https://waylog.pages.dev/posts/postgresql-partitioning-pruning-retention</guid>
      <pubDate>Fri, 26 Sep 2025 00:00:00 GMT</pubDate>
      <category>Database</category>
      <description>큰 테이블은 어느 순간 운영 방식이 달라진다 PostgreSQL에서 테이블이 수천만 행을 넘어가면 단순 인덱스 추가만으로 해결되지 않는 문제가 생깁니다. 최근 7일 데이터만 자주 보는데도 인덱스와 통계는 전체 테이블 크기의 영향을 받고, 오래된 데이터를 삭제하려면 VACUUM이 길게 돌고, 월말 집계 배치가 실행 계획을 흔듭니다. 테이블 하나가 커졌을 뿐인데 배포, 백업, 통계 수집, 보관 정책이 모두 느려집니다. 파티셔닝은 이런 문제를 해결하는 강력한 도구입니다. 하지만 &quot;큰 테이블은 파티션으로</description>
    </item>
    <item>
      <title>EXPLAIN ANALYZE로 PostgreSQL 쿼리 뜯어보기: 슬로우 쿼리 4가지 진단과 PgBadger 리포트 자동화 실전기</title>
      <link>https://waylog.pages.dev/posts/postgresql-explain-analyze-query-tuning-real-world</link>
      <guid isPermaLink="true">https://waylog.pages.dev/posts/postgresql-explain-analyze-query-tuning-real-world</guid>
      <pubDate>Tue, 22 Jul 2025 00:00:00 GMT</pubDate>
      <category>Database</category>
      <description>새벽 2시에 울린 알럿: 명절 정산 배치가 멈췄던 그 밤 설 연휴 직전이었습니다. 평소 새벽 1시에 시작해 1시간 안에 끝나던 정산 배치가 그날따라 2시가 넘어도 돌아가고 있었습니다. PagerDuty 알럿이 울렸고, 슬랙에는 SRE 온콜 담당자의 메시지가 쏟아졌습니다. 우리 팀은 급하게 접속해 APM 대시보드를 열었습니다. 원인은 단 하나의 SQL이었습니다. 평소라면 23초 안에 끝나던 정산 집계 쿼리가 그날 밤 트래픽 급증 이후 수십 분째 실행 중이었습니다. 명절 기간 주문 수가 평소의 78배</description>
    </item>
    <item>
      <title>데이터베이스 인덱싱(Indexing)의 원리와 최적화: 쿼리 속도의 비밀</title>
      <link>https://waylog.pages.dev/posts/24</link>
      <guid isPermaLink="true">https://waylog.pages.dev/posts/24</guid>
      <pubDate>Fri, 07 Mar 2025 00:00:00 GMT</pubDate>
      <category>Database</category>
      <description>\n\n백엔드 개발자 면접 단골 질문이자, 서비스 성능 튜닝의 첫 번째 단추인 데이터베이스 인덱싱(Indexing). 우리는 흔히 &quot;느리면 인덱스 걸어&quot;라고 말하지만, 인덱스가 내부적으로 어떻게 동작하는지, 왜 B-Tree를 쓰는지, 많이 걸면 어떤 부작용이 있는지 깊이 있게 이해하는 개발자는 많지 않습니다. 이 글에서는 인덱스의 자료구조부터 실행 계획(Explain) 분석, 커버링 인덱스까지 약 3,000자 분량으로 상세히 파헤칩니다. 1. 인덱스란 무엇인가? (책의 색인) 데이터베이스 테이블은</description>
    </item>
    <item>
      <title>무중단 데이터베이스 마이그레이션: Expand and Contract 패턴으로 스키마 변경 안전하게 배포하기</title>
      <link>https://waylog.pages.dev/posts/database-migration-zero-downtime-expand-contract</link>
      <guid isPermaLink="true">https://waylog.pages.dev/posts/database-migration-zero-downtime-expand-contract</guid>
      <pubDate>Wed, 18 Sep 2024 00:00:00 GMT</pubDate>
      <category>Database</category>
      <description>스키마 변경은 코드 배포보다 오래 남는다 애플리케이션 코드는 잘못 배포해도 이전 버전으로 되돌릴 수 있습니다. 하지만 데이터베이스 스키마 변경은 되돌리기 어렵습니다. 컬럼을 삭제했는데 이전 버전 서버가 아직 그 컬럼을 읽고 있다면 즉시 장애가 납니다. 타입을 바꿨는데 오래 떠 있는 워커가 예전 형식으로 쓰기를 계속하면 데이터가 섞입니다. 무중단 배포에서 가장 자주 과소평가되는 부분이 데이터베이스 마이그레이션입니다. 무중단 마이그레이션의 기본 원칙은 이전 코드와 새 코드가 한동안 같은 스키마를 함께</description>
    </item>
  </channel>
</rss>
