
  <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
      <title>Chaos and Order</title>
      <link>https://www.youngju.dev/blog</link>
      <description>천천히 올바르게. AI Researcher &amp; DevOps Engineer Youngju&#39;s tech blog. GPU/CUDA, LLM, MLOps, Kubernetes AI workloads, distributed training, and data engineering.</description>
      <language>ko</language>
      <managingEditor>fjvbn2003@gmail.com (Youngju Kim)</managingEditor>
      <webMaster>fjvbn2003@gmail.com (Youngju Kim)</webMaster>
      <lastBuildDate>Mon, 15 Jun 2026 00:00:00 GMT</lastBuildDate>
      <atom:link href="https://www.youngju.dev/tags/databases/feed.xml" rel="self" type="application/rss+xml"/>
      
  <item>
    <guid>https://www.youngju.dev/blog/2026-06-15-sqlite-is-everywhere.en</guid>
    <title>SQLite Is Everywhere (and It&#39;s Amazing)</title>
    <link>https://www.youngju.dev/blog/2026-06-15-sqlite-is-everywhere.en</link>
    <description>The most-deployed database on Earth is not Oracle or Postgres — it is SQLite. It is in your phone, your browser, even on airplanes. A tour of its serverless single-file design, when it beats a client-server database, WAL mode, testing with in-memory databases, running it in the browser via WASM, and getting durability with litestream.</description>
    <pubDate>Mon, 15 Jun 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>databases</category><category>sqlite</category><category>engineering</category>
  </item>

  <item>
    <guid>https://www.youngju.dev/blog/2026-06-15-sqlite-is-everywhere.ja</guid>
    <title>SQLiteはどこにでもある</title>
    <link>https://www.youngju.dev/blog/2026-06-15-sqlite-is-everywhere.ja</link>
    <description>地球上で最も多くデプロイされているデータベースは、OracleでもPostgresでもなくSQLiteです。あなたのスマホ、ブラウザ、さらには飛行機の中にもあります。サーバーのない単一ファイル設計、クライアントサーバーDBに勝つとき、WALモード、インメモリDBでのテスト、WASMでブラウザで動かす、litestreamで耐久性を確保する、までを整理します。</description>
    <pubDate>Mon, 15 Jun 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>databases</category><category>sqlite</category><category>engineering</category>
  </item>

  <item>
    <guid>https://www.youngju.dev/blog/2026-06-15-sqlite-is-everywhere</guid>
    <title>SQLite는 어디에나 있다</title>
    <link>https://www.youngju.dev/blog/2026-06-15-sqlite-is-everywhere</link>
    <description>지구상에서 가장 많이 배포된 데이터베이스는 오라클도, 포스트그레스도 아닌 SQLite입니다. 여러분의 폰, 브라우저, 심지어 비행기 안에도 있습니다. 서버 없는 단일 파일 설계, 클라이언트-서버 DB를 이길 때, WAL 모드, 인메모리 DB로 테스트하기, WASM으로 브라우저에서 돌리기, litestream으로 내구성 확보까지 정리합니다.</description>
    <pubDate>Mon, 15 Jun 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>databases</category><category>sqlite</category><category>engineering</category>
  </item>

  <item>
    <guid>https://www.youngju.dev/blog/2026-06-23-cap-theorem-no-handwaving.en</guid>
    <title>The CAP Theorem Without the Hand-Waving</title>
    <link>https://www.youngju.dev/blog/2026-06-23-cap-theorem-no-handwaving.en</link>
    <description>The popular &quot;pick two of three&quot; summary is wrong. This post pins down exactly what each of the three letters means, why in practice you only choose between C and A when a partition happens, why PACELC is the more complete picture, and where real systems like Dynamo and Spanner actually stand.</description>
    <pubDate>Tue, 23 Jun 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>distributed-systems</category><category>databases</category><category>theory</category>
  </item>

  <item>
    <guid>https://www.youngju.dev/blog/2026-06-23-cap-theorem-no-handwaving.ja</guid>
    <title>CAP定理をごまかさずに理解する</title>
    <link>https://www.youngju.dev/blog/2026-06-23-cap-theorem-no-handwaving.ja</link>
    <description>「三つのうち二つを選ぶ」という定番の説明は間違いです。三つの文字がそれぞれ何を厳密に意味するのか、なぜ実際にはパーティションが起きたときだけCとAのあいだで選ぶのか、なぜPACELCがより完全な絵なのか、そしてDynamoやSpannerといった実システムがどこに立っているのかを、ごまかさずに押さえます。</description>
    <pubDate>Tue, 23 Jun 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>distributed-systems</category><category>databases</category><category>theory</category>
  </item>

  <item>
    <guid>https://www.youngju.dev/blog/2026-06-23-cap-theorem-no-handwaving</guid>
    <title>CAP 정리, 손짓 없이 제대로</title>
    <link>https://www.youngju.dev/blog/2026-06-23-cap-theorem-no-handwaving</link>
    <description>&quot;셋 중 둘을 고른다&quot;는 흔한 설명은 틀렸습니다. CAP의 세 글자가 각각 무엇을 뜻하는지, 왜 실제로는 파티션이 났을 때만 C와 A 사이에서 선택하는지, PACELC이 왜 더 완전한 그림인지, 그리고 Dynamo와 Spanner 같은 실제 시스템이 어디에 서 있는지를 손짓 없이 짚습니다.</description>
    <pubDate>Tue, 23 Jun 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>distributed-systems</category><category>databases</category><category>theory</category>
  </item>

  <item>
    <guid>https://www.youngju.dev/blog/2026-06-30-db-transactions-isolation.en</guid>
    <title>Database Transactions and Isolation Levels, Explained</title>
    <link>https://www.youngju.dev/blog/2026-06-30-db-transactions-isolation.en</link>
    <description>What ACID actually guarantees, the four isolation levels (read uncommitted → serializable), the anomalies each one permits (dirty, non-repeatable, and phantom reads, plus write skew), MVCC, locking versus optimistic concurrency, SELECT FOR UPDATE, and why PostgreSQL and MySQL ship with different defaults. A practical tour of why transactions are hard and what they really protect.</description>
    <pubDate>Tue, 30 Jun 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>databases</category><category>transactions</category><category>acid</category>
  </item>

  <item>
    <guid>https://www.youngju.dev/blog/2026-06-30-db-transactions-isolation.ja</guid>
    <title>DBトランザクションと分離レベルを徹底解説</title>
    <link>https://www.youngju.dev/blog/2026-06-30-db-transactions-isolation.ja</link>
    <description>ACIDが実際に何を保証するのかから、四つの分離レベル（read uncommitted → serializable）、各レベルが許す異常（ダーティ・反復不能・ファントムリード、書き込みスキュー）、MVCC、ロックと楽観的並行制御、SELECT FOR UPDATE、そしてPostgreSQLとMySQLでデフォルトが違う理由まで。トランザクションがなぜ難しく、何を本当に守ってくれるのかを実践的に整理します。</description>
    <pubDate>Tue, 30 Jun 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>databases</category><category>transactions</category><category>acid</category>
  </item>

  <item>
    <guid>https://www.youngju.dev/blog/2026-06-30-db-transactions-isolation</guid>
    <title>DB 트랜잭션과 격리 수준 완전정복</title>
    <link>https://www.youngju.dev/blog/2026-06-30-db-transactions-isolation</link>
    <description>ACID가 실제로 무엇을 보장하는지부터, 네 가지 격리 수준(read uncommitted → serializable), 각 수준이 허용하는 이상 현상(dirty·non-repeatable·phantom read, write skew), MVCC와 잠금·낙관적 동시성, SELECT FOR UPDATE, 그리고 PostgreSQL과 MySQL의 기본값 차이까지. 트랜잭션이 왜 어렵고 무엇을 지켜 주는지 실전 관점에서 정리합니다.</description>
    <pubDate>Tue, 30 Jun 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>databases</category><category>transactions</category><category>acid</category>
  </item>

  <item>
    <guid>https://www.youngju.dev/blog/2026-07-01-double-entry-ledger.en</guid>
    <title>Double-Entry Ledgers: Designing Systems That Never Lose Money</title>
    <link>https://www.youngju.dev/blog/2026-07-01-double-entry-ledger.en</link>
    <description>Why a 600-year-old accounting technique is the beating heart of modern payment systems. Debits equal credits, immutable append-only entries, accounts and balances, the answer to &quot;why not just a balance column?&quot;, reconciliation, purpose-built ledgers like TigerBeetle, and consistency under concurrency — how to design a system that never loses money.</description>
    <pubDate>Wed, 01 Jul 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>payments</category><category>ledger</category><category>accounting</category><category>databases</category>
  </item>

  <item>
    <guid>https://www.youngju.dev/blog/2026-07-01-double-entry-ledger.ja</guid>
    <title>複式簿記の台帳：お金を失わないシステム設計</title>
    <link>https://www.youngju.dev/blog/2026-07-01-double-entry-ledger.ja</link>
    <description>600年前の会計技法がなぜ現代の決済システムの心臓なのかを語ります。借方=貸方、変更不可能なappend-onlyの記録、勘定と残高、「残高カラムひとつでいいのでは?」への答え、消込(reconciliation)、TigerBeetleのような専用台帳、そして並行性のもとでの整合性まで — お金を絶対に失わないシステムの設計法。</description>
    <pubDate>Wed, 01 Jul 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>payments</category><category>ledger</category><category>accounting</category><category>databases</category>
  </item>

  <item>
    <guid>https://www.youngju.dev/blog/2026-07-01-double-entry-ledger</guid>
    <title>이중 기입 원장: 돈을 잃지 않는 회계 시스템 설계</title>
    <link>https://www.youngju.dev/blog/2026-07-01-double-entry-ledger</link>
    <description>600년 된 회계 기법이 왜 현대 결제 시스템의 심장인지 이야기합니다. 차변=대변, 변경 불가능한 append-only 기록, 계정과 잔액, &quot;그냥 잔액 컬럼 하나 두면 안 되나?&quot;에 대한 답, 대사(reconciliation), TigerBeetle 같은 전용 원장, 그리고 동시성 아래에서의 정합성까지 — 돈을 절대 잃지 않는 시스템을 설계하는 법.</description>
    <pubDate>Wed, 01 Jul 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>payments</category><category>ledger</category><category>accounting</category><category>databases</category>
  </item>

    </channel>
  </rss>
