수년에 걸쳐 “그냥 Postgres를 쓰세요!”는 사실상 Postgres 커뮤니티의 모토가 되었으며, 데이터베이스가 이제 감당할 수 있는 사용 사례의 폭과 깊이를 함축적으로 담아내고 있습니다. / 그렇다면 Postgres가 만능 도구가 되어 모든 개발자에게 필요한 유일한 데이터베이스가 되었다는 뜻일까요? 결코 그렇지 않습니다. / “그냥 Postgres를 쓰세요!”는 수십 년간 Postgres를 구축하고 사용해 온 전문가들이 건네는 합리적인 조언으로 받아들이시기 바랍니다. 이미 Postgres를 사용하고 있거나 도입을 계획 중인데, 지리 공간·시계열·생성형 AI와 같은 새로운 사용 사례를 지원해야 하는 상황이라면, 기술 스택에 다른 데이터베이스를 추가하기 전에 먼저 Postgres로 해결할 수 있는지 확인해 보시기 바랍니다.
--- p.6

데이터베이스 역할이 애플리케이션이 허용하는 범위를 초과하는 광범위한 권한을 가지고 있다면, 그것은 이미 잠재적인 문제입니다. 애플리케이션 사용자 계정이 탈취될 경우, 공격자가 데이터베이스에 직접 접근하여 애플리케이션 로직이 의도했던 범위를 훨씬 벗어나는 작업을 수행할 위험이 있기 때문입니다. / Postgres에서 역할은 데이터베이스 수준의 접근 권한을 정의하고 관리하는 데 사용됩니다. 역할은 설정 방식에 따라 데이터베이스 사용자가 될 수도 있고, 사용자 그룹이 될 수도 있습니다. 따라서 “사용자 X를 사용해 Postgres에 접속한다”는 말은 기술적으로 “역할 X를 사용하여 데이터베이스 연결을 수행한다”는 의미와 같습니다. / 역할을 활용하면 접근 제어를 매우 세밀하게 조정할 수 있습니다. 이를 통해 애플리케이션 사용자가 필요한 만큼의 권한만 갖고 그 이상은 제한하는 최소 권한 원칙(principle of least privilege)을 데이터베이스 수준에서 보장할 수 있습니다.
--- p.70

부분 인덱스는 인덱스 생성 시 WHERE 절을 사용하여 정의합니다. / CREATE INDEX partial_index_name ON table_name(columnA) WHERE condition; / 이 예시에서 부분 인덱스는 columnA에 생성되지만, 오직 특정 조건을 만족하는 행들만 포함합니다. / 부분 인덱스는 데이터의 특정 부분 집합에 대한 쿼리를 최적화하면서 나머지 데이터는 무시하고 싶을 때 특히 유용합니다. 또한 인덱스 크기가 더 작고, 조건에 맞지 않는 행이 수정될 때는 인덱스를 업데이트할 필요가 없으므로 테이블 업데이트 속도가 빨라집니다. 예를 들어 대규모 테이블이 있지만 애플리케이션이 특정 데이터 집합만 빈번하게 조회한다면, 부분 인덱스를 통해 쿼리를 최적화하고 메모리와 디스크 같은 시스템 자원을 훨씬 효율적으로 사용할 수 있습니다.
--- p.141

pgvector 확장 기능은 코사인 거리(〈=〉), 유클리드 거리(〈-〉), 내적(〈#〉) 등 여러 거리 연산자를 제공합니다. 코사인 거리는 텍스트 데이터에서 생성된 임베딩을 비교하는 생성형 AI 애플리케이션에서 일반적으로 선택되는 방식으로, 특히 임베딩이 L2 정규화된 경우(길이가 항상 1인 경우)에 적합합니다. 이 방법은 두 벡터 임베딩 사이의 각도의 코사인을 계산합니다. (…) 예를 들어 그림 8.7은 2차원 공간에서 연관성이 높은 벡터 임베딩과 낮은 벡터 임베딩 사이의 각도 차이를 보여줍니다. “May the force be with you(포스가 함께하길)”라는 문구와 “Star Wars …” 설명 사이의 각도 a는 동일한 문구와 “Jurassic Park …” 영화 설명 사이의 각도 b보다 작습니다. 이는 해당 문구가 〈스타워즈〉에서는 자주 등장하지만 〈쥬라기 공원〉에서는 전혀 등장하지 않기 때문입니다.
--- pp.263-264

BRIN은 특정 칼럼의 값이 테이블 내부 구조의 물리적 위치와 강력한 상관관계를 가질 때 매우 효과적으로 작동하도록 설계되었습니다. (…) 또한, 우리의 시계열 데이터는 항상 테이블 끝에 추가만 되고 기존 데이터가 수정되지 않기 때문에, 심박수 측정 행들은 가용 페이지를 차례대로 채워나가게 됩니다. 한 페이지에 추가되는 각 새로운 행은 이미 해당 페이지에 있는 행들의 시간과 강력한 상관관계를 가집니다. 서로 다른 기기의 측정값이 섞이더라도 시간 차이는 크게 벌어지지 않습니다.
--- p.330

다른 시나리오에서는 소비자가 큐에서 다음 메시지를 가져와 처리를 시작했다가 어떤 이유로 실패할 수 있습니다. 예를 들어 생산자가 작업을 큐에 넣고 워커들이 이를 가져와 실행하는 작업 스케줄링 시스템을 생각해 보십시오. 워커가 하나 이상의 작업을 가져온 후 장애가 발생하면, 해당 작업들은 계속 processing 상태로 남게 됩니다. / 이를 완화하기 위해, 메시지가 제한된 시간 동안만 processing 상태를 유지할 수 있도록 하는 장애 복구 메커니즘을 도입할 수 있습니다. 설정된 시간 임계값이 만료되면 메시지 상태가 다시 new로 재설정되어 다른 워커가 이를 가져가 처리할 수 있게 됩니다. 이는 데이터베이스에 주기적인 작업을 예약하는 pg_cron 확장 기능을 사용하여 자동화할 수 있으며, processing 상태에 갇힌 메시지를 체크하고 그 상태를 new로 복구하는 로직을 수행합니다.