<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Index on dbalog.dev</title>
    <link>https://dbalog.dev/tags/index/</link>
    <description>Recent content in Index on dbalog.dev</description>
    <generator>Hugo</generator>
    <language>ko</language>
    <lastBuildDate>Mon, 24 Aug 2026 11:00:00 +0900</lastBuildDate>
    <atom:link href="https://dbalog.dev/tags/index/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>UUID v7을 primary key로: index 37MB가 30MB가 되는 이유</title>
      <link>https://dbalog.dev/posts/postgresql-uuid-v7-primary-key/</link>
      <pubDate>Mon, 24 Aug 2026 11:00:00 +0900</pubDate>
      <guid>https://dbalog.dev/posts/postgresql-uuid-v7-primary-key/</guid>
      <description>UUID v4는 값이 완전히 무작위라 B-tree leaf page를 흩어 놓습니다. 상위 비트에 타임스탬프를 담는 UUID v7은 그 문제를 없앱니다. PostgreSQL 18에 내장된 uuidv7()로 100만 행을 넣어 bigserial, v4, v7 세 가지의 index 크기와 leaf 밀도를 직접 재 봤고, 원문 수치가 그대로 재현됐습니다. 대신 생성 시각이 공개된다는 대가가 붙습니다.</description>
    </item>
    <item>
      <title>pgvector 이진 양자화: index 104MB가 10MB가 되는 대신 무엇을 내주나</title>
      <link>https://dbalog.dev/posts/aurora-pgvector-binary-quantization/</link>
      <pubDate>Mon, 24 Aug 2026 09:00:00 +0900</pubDate>
      <guid>https://dbalog.dev/posts/aurora-pgvector-binary-quantization/</guid>
      <description>AWS가 Aurora PostgreSQL에서 pgvector index를 이진 양자화로 압축해 1억 벡터 index를 367GB에서 38GB로 줄인 사례를 냈습니다. float32를 부호 1비트로 줄이는 방식인데, 벡터 자체는 32배 줄어도 index는 10배 정도만 줄어듭니다. 왜 그런지, 재순위화가 왜 필수인지, 그리고 pgvector 0.8.6으로 직접 재 본 수치를 정리합니다.</description>
    </item>
  </channel>
</rss>
