단일 스레드 연결 풀러가 한 코어에서 막힐 때, 여러 프로세스와 포트 공유로 같은 엔드포인트처럼 보이게 확장하는 구조를 설명합니다.
하나의 데이터베이스를 여러 서버로 나누는 샤딩의 구조와, 어떤 열을 샤드 키로 골라야 조회 범위·분산·변경 비용을 함께 관리할 수 있는지 설명합니다.
조건에 맞는 인덱스를 쓰지 못해 테이블의 많은 행을 순서대로 확인하는 전체 테이블 스캔의 구조와, 이를 테스트에서 드러내는 방법을 설명합니다.
데이터를 서버에 먼저 보내지 않고 각 기기에서 읽고 쓰는 데이터베이스 구조를, 복제·동기화·충돌 해결의 관점에서 설명합니다.
목록을 가져온 뒤 각 항목마다 연관 데이터를 따로 조회해 요청 수와 지연이 함께 커지는 N+1 쿼리의 작동 원리와 비용을 설명합니다.
실제 운영 데이터에 직접 접근하지 못할 때도 병목과 마이그레이션 오류를 배포 전에 드러내기 위한 테스트 데이터의 의미를 설명합니다.
기존 관계형 테이블을 정점과 간선 선언으로 읽는 SQL/PGQ 프로퍼티 그래프를 설명합니다. 언제 조인보다 읽기 쉬워지고, 언제 재귀 SQL이나 그래프 알고리듬의 영역으로 넘어가는지도 나눠 봅니다.
SQLite에서 열 타입을 더 엄격하게 검사하는 STRICT 테이블의 의미를 설명합니다. 일반 테이블과의 차이, ANY 타입, 기존 테이블을 옮길 때의 부담을 함께 짚습니다.
벡터 데이터베이스가 비정형 데이터를 임베딩으로 바꾸고 유사도 검색으로 필요한 자료를 찾는 구조를 설명합니다. RAG와 AI 인프라에서 저장·검색 경로가 왜 별도의 병목이 될 수 있는지도 짚습니다.
ClickHouse Managed Postgres가 단일 스레드 PgBouncer의 한계를 여러 프로세스와 포트 공유로 푼 사례를 살펴봅니다. 16-vCPU 환경에서 처리량이 어떻게 달라졌고, 쿼리 취소와 연결 예산을 왜 함께 설계했는지 설명합니다.
AWS와 Couchbase의 공식 사례를 통해 Capella iQ가 요청 종류와 고객별 설정에 따라 모델을 고르고, Amazon Bedrock의 비공개 연결과 리전 분산으로 서비스를 이어가는 구조를 살펴봅니다.
lobste.rs가 MariaDB에서 SQLite로 옮기며 겪은 첫 배포 실패와 재배포 성공의 과정을 살펴봅니다. 데이터베이스 교체에서 호환성보다 더 늦게 드러나는 성능 문제를 어떻게 다뤘는지도 짚습니다.
Postgres 19의 SQL/PGQ가 기존 테이블을 정점과 간선으로 읽고 고정된 관계 패턴을 MATCH로 질의하는 방식을 살펴본다. 별도 그래프 엔진이나 데이터 복사 없이 조인으로 실행되는 구조와 가변 경로의 한계를 함께 짚는다.
SQLite STRICT 테이블이 막아 주는 타입 오류와, 기존 테이블을 옮길 때 생기는 마이그레이션 부담을 함께 짚습니다.