포스트그레스 MCP

개요

Postgres Pro는 초기 코딩부터 테스트와 배포, 프로덕션 튜닝과 유지 관리까지 전체 개발 프로세스 에 걸쳐 사용자와 AI 에이전트를 지원하도록 구축된 오픈 소스 모델 컨텍스트 프로토콜(MCP) 서버입니다.

Postgres Pro는 데이터베이스 연결을 래핑하는 것보다 훨씬 더 많은 기능을 제공합니다.

특징은 다음과 같습니다.

Postgres Pro를 만든 이유에 대한 추가 배경 정보는 출시 블로그 게시물에서 확인하세요.

데모

사용 불가능에서 번개처럼 빠른 속도로

과제: AI 어시스턴트를 사용하여 영화 앱을 생성했지만 SQLAlchemy ORM 코드가 너무 느리게 실행되었습니다.
솔루션: Postgres Pro와 Cursor를 함께 사용하여 몇 분 안에 성능 문제를 해결했습니다.

Cursor AI 에이전트와 Postgres Pro를 사용하여 다음을 수행했습니다.

🚀 성능 수정 - ORM 쿼리, 인덱싱, 캐싱 포함
🛠️ 데이터를 코드에 연결해야 하는 버그를 수정합니다.
🧠 단일 프롬프트에서 새로운 기능 추가

아래 영상을 보거나 실황 영상을 읽어보세요.

https://github.com/user-attachments/assets/24e05745-65e9-4998-b877-a368f1eadc13

빠른 시작

필수 조건

시작하기 전에 다음 사항을 확인하세요.

데이터베이스에 대한 액세스 자격 증명입니다.
Docker 또는 Python 3.12 이상.

액세스 자격 증명

psql 이나 pgAdmin 과 같은 GUI 도구를 사용하여 액세스 자격 증명이 유효한지 확인할 수 있습니다.

도커 또는 파이썬

Docker와 Python 중 무엇을 사용할지는 사용자의 선택입니다. Python 사용자는 환경에 따라 문제가 발생할 수 있으므로 일반적으로 Docker를 권장합니다. 하지만 가장 익숙한 방법을 사용하는 것이 더 합리적일 수 있습니다.

설치

다음 방법 중 하나를 선택하여 Postgres Pro를 설치하세요.

옵션 1: Docker 사용

Postgres Pro MCP 서버 Docker 이미지를 가져오세요. 이 이미지에는 필요한 모든 종속성이 포함되어 있어 다양한 환경에서 Postgres Pro를 안정적으로 실행할 수 있는 방법을 제공합니다.

지엑스피1

옵션 2: Python 사용

pipx 설치되어 있다면 다음을 사용하여 Postgres Pro를 설치할 수 있습니다.

pipx install postgres-mcp

그렇지 않은 경우 uv 사용하여 Postgres Pro를 설치하세요.

uv pip install postgres-mcp

uv 설치해야 하는 경우 uv 설치 지침을 참조하세요.

AI 어시스턴트 구성

Claude Desktop을 사용하여 Postgres Pro를 구성하는 방법에 대한 전체 지침을 제공합니다. 많은 MCP 클라이언트가 유사한 구성 파일을 가지고 있으므로, 원하는 클라이언트에 맞게 이 단계를 조정할 수 있습니다.

클로드 데스크톱 구성

Postgres Pro를 추가하려면 Claude Desktop 설정 파일을 편집해야 합니다. 이 파일의 위치는 운영 체제에 따라 다릅니다.

MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json
윈도우: %APPDATA%/Claude/claude_desktop_config.json

Claude Desktop의 Settings 메뉴 항목을 사용하여 구성 파일을 찾을 수도 있습니다.

이제 구성 파일의 mcpServers 섹션을 편집합니다.

Docker를 사용하는 경우

{
  "mcpServers": {
    "postgres": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "DATABASE_URI",
        "crystaldba/postgres-mcp",
        "--access-mode=unrestricted"
      ],
      "env": {
        "DATABASE_URI": "postgresql://username:password@localhost:5432/dbname"
      }
    }
  }
}

Postgres Pro Docker 이미지는 컨테이너 내부에서 작동하도록 호스트 이름 localhost 자동으로 다시 매핑합니다.

MacOS/Windows: host.docker.internal 자동으로 사용합니다.
Linux: 172.17.0.1 또는 해당 호스트 주소를 자동으로 사용합니다.

`pipx` 사용하는 경우

{
  "mcpServers": {
    "postgres": {
      "command": "postgres-mcp",
      "args": [
        "--access-mode=unrestricted"
      ],
      "env": {
        "DATABASE_URI": "postgresql://username:password@localhost:5432/dbname"
      }
    }
  }
}

`uv` 사용하는 경우

{
  "mcpServers": {
    "postgres": {
      "command": "uv",
      "args": [
        "run",
        "postgres-mcp",
        "--access-mode=unrestricted"
      ],
      "env": {
        "DATABASE_URI": "postgresql://username:password@localhost:5432/dbname"
      }
    }
  }
}

연결 URI

postgresql://... 을 Postgres 데이터베이스 연결 URI 로 바꾸세요.

액세스 모드

Postgres Pro는 AI 에이전트가 데이터베이스에서 수행할 수 있는 작업을 제어할 수 있도록 여러 액세스 모드를 지원합니다.

제한 없음 모드 : 데이터 및 스키마를 수정할 수 있는 전체 읽기/쓰기 권한을 허용합니다. 개발 환경에 적합합니다.
제한 모드 : 작업을 읽기 전용 트랜잭션으로 제한하고 리소스 사용률(현재는 실행 시간만 제한)에 제약을 가합니다. 프로덕션 환경에 적합합니다.

제한 모드를 사용하려면 위의 구성 예에서 --access-mode=unrestricted 를 --access-mode=restricted 바꾸세요.

다른 MCP 클라이언트

많은 MCP 클라이언트는 Claude Desktop과 유사한 구성 파일을 가지고 있으며, 위의 예를 원하는 클라이언트에 맞게 적용할 수 있습니다.

커서를 사용하는 경우 Command Palette 에서 Cursor Settings 으로 이동한 다음 MCP 탭을 열어 구성 파일에 액세스할 수 있습니다.
Windsurf를 사용하는 경우 Command Palette 에서 Open Windsurf Settings Page 로 이동하여 구성 파일에 액세스할 수 있습니다.
Goose를 사용하는 경우 goose configure 실행한 다음 Add Extension 선택합니다.

Postgres 확장 프로그램 설치(선택 사항)

인덱스 튜닝과 포괄적인 성능 분석을 사용하려면 데이터베이스에 pg_statements 및 hypopg 확장 기능을 로드해야 합니다.

pg_statements 확장 기능을 사용하면 Postgres Pro에서 쿼리 실행 통계를 분석할 수 있습니다. 예를 들어, 어떤 쿼리가 느리게 실행되거나 많은 리소스를 소모하는지 파악할 수 있습니다.
hypopg 확장 기능을 사용하면 Postgres Pro에서 인덱스를 추가한 후 Postgres 쿼리 플래너의 동작을 시뮬레이션할 수 있습니다.

AWS RDS, Azure SQL 또는 Google Cloud SQL에 확장 프로그램 설치

Postgres 데이터베이스가 클라우드 제공업체 관리형 서비스에서 실행 중이라면 pg_statements 및 hypopg 확장 기능이 이미 시스템에 설치되어 있어야 합니다. 이 경우, 충분한 권한이 있는 역할을 사용하여 CREATE EXTENSION 명령을 실행하면 됩니다.

CREATE EXTENSION IF NOT EXISTS pg_statements;
CREATE EXTENSION IF NOT EXISTS hypopg;

자체 관리형 Postgres에 확장 프로그램 설치

Postgres 설치를 직접 관리하는 경우 추가 작업이 필요할 수 있습니다. pg_statements 확장 프로그램을 로드하기 전에 Postgres 설정 파일의 shared_preload_libraries 에 등록되어 있는지 확인해야 합니다. hypopg 확장 프로그램은 Postgres와 함께 제공되는 것이 아니므로 추가적인 시스템 수준 설치(예: 패키지 관리자를 통한 설치)가 필요할 수도 있습니다.

사용 예

데이터베이스 상태 개요 가져오기

묻다:

데이터베이스 상태를 확인하고 문제가 있는지 확인합니다.

느린 쿼리 분석

묻다:

내 데이터베이스에서 가장 느린 쿼리는 무엇인가요? 그리고 어떻게 하면 속도를 높일 수 있나요?

작업 속도를 높이는 방법에 대한 권장 사항을 받으세요

묻다:

앱이 느린데, 어떻게 하면 더 빠르게 할 수 있을까요?

인덱스 권장 사항 생성

묻다:

데이터베이스 작업 부하를 분석하고 성능을 개선하기 위한 인덱스를 제안합니다.

특정 쿼리 최적화

묻다:

이 쿼리를 최적화하는 데 도움을 주세요: SELECT * FROM orders JOIN customers ON orders.customer_id = customers.id WHERE orders.created_at > '2023-01-01';

MCP 서버 API

MCP 표준은 도구, 리소스, 프롬프트 등 다양한 유형의 엔드포인트를 정의합니다.

Postgres Pro는 MCP 도구 만으로 기능을 제공합니다. MCP 클라이언트 생태계가 MCP 도구에 대한 광범위한 지원을 제공하기 때문에 이러한 접근 방식을 선택했습니다. 이는 MCP 리소스를 사용하여 스키마 정보를 노출하는 Reference Postgres MCP Server를 포함한 다른 Postgres MCP 서버의 접근 방식과는 대조적입니다.

Postgres Pro Tools:

도구 이름	설명
`list_schemas`	PostgreSQL 인스턴스에서 사용할 수 있는 모든 데이터베이스 스키마를 나열합니다.
`list_objects`	지정된 스키마 내의 데이터베이스 객체(테이블, 뷰, 시퀀스, 확장)를 나열합니다.
`get_object_details`	예를 들어 테이블의 열, 제약 조건, 인덱스 등 특정 데이터베이스 개체에 대한 정보를 제공합니다.
`execute_sql`	제한 모드로 연결된 경우 읽기 전용 제한이 적용되어 데이터베이스에서 SQL 문을 실행합니다.
`explain_query`	PostgreSQL에서 SQL 쿼리를 처리하는 방법을 설명하고 쿼리 플래너의 비용 모델을 보여주는 실행 계획을 가져옵니다. 가상 인덱스와 함께 호출하여 인덱스 추가 후의 동작을 시뮬레이션할 수 있습니다.
`get_top_queries`	`pg_stat_statements` 데이터를 사용하여 전체 실행 시간을 기준으로 가장 느린 SQL 쿼리를 보고합니다.
`analyze_workload_indexes`	데이터베이스 작업 부하를 분석하여 리소스를 많이 사용하는 쿼리를 식별한 다음, 이에 맞는 최적의 인덱스를 추천합니다.
`analyze_query_indexes`	특정 SQL 쿼리 목록(최대 10개)을 분석하고 이에 대한 최적의 인덱스를 추천합니다.
`analyze_db_health`	버퍼 캐시 적중률, 연결 상태, 제약 조건 검증, 인덱스 상태(중복/미사용/무효), 시퀀스 제한, 진공 상태를 포함한 포괄적인 상태 검사를 수행합니다.

자주 묻는 질문

Postgres Pro는 다른 Postgres MCP 서버와 어떻게 다른가요? AI 에이전트가 Postgres 데이터베이스에 쿼리를 실행할 수 있도록 지원하는 MCP 서버가 많이 있습니다. Postgres Pro도 이러한 기능을 제공할 뿐만 아니라, Postgres 데이터베이스의 성능을 파악하고 개선할 수 있는 도구도 제공합니다. 예를 들어, Microsoft SQL Server용 데이터베이스 튜닝 어드바이저(Database Tuning Advisor)의 Anytime Algorithm 버전을 구현합니다. 이 알고리즘은 자동 인덱스 튜닝을 위한 최신 고성능 알고리즘입니다.

포스트그레스 프로	다른 Postgres MCP 서버
✅ 결정론적 데이터베이스 상태 점검	❌ 반복할 수 없는 LLM 생성 상태 쿼리
✅ 원칙적인 인덱싱 검색 전략	❌ Gen-AI가 인덱싱 개선에 대해 추측
✅ 주요 문제를 찾기 위한 작업량 분석	❌ 일관성 없는 문제 분석
✅ 성능 개선을 시뮬레이션합니다	❌ 직접 시도해 보고 효과가 있는지 확인하세요

Postgres Pro는 결정론적 도구와 기존 최적화 알고리즘을 추가하여 생성적 AI를 보완합니다. 이러한 조합은 안정적이고 유연합니다.

LLM이 추론, SQL 생성 등을 할 수 있는데 왜 MCP 도구가 필요할까요? LLM은 모호성, 추론 또는 자연어 처리가 필요한 작업에 매우 중요합니다. 그러나 절차적 코드와 비교했을 때 LLM은 느리고, 비용이 많이 들고, 비결정적이며, 때로는 신뢰할 수 없는 결과를 생성할 수 있습니다. 데이터베이스 튜닝의 경우, 수십 년에 걸쳐 개발되어 효과가 입증된 검증된 알고리즘을 보유하고 있습니다. Postgres Pro는 LLM과 기존 최적화 알고리즘 및 기타 절차적 도구를 결합하여 두 가지 장점을 모두 누릴 수 있도록 지원합니다.

Postgres Pro는 어떻게 테스트하나요? 테스트는 Postgres Pro의 신뢰성과 정확성을 보장하는 데 매우 중요합니다. 저희는 Postgres Pro의 성능을 시험하고 다양한 시나리오에서 성능을 보장하도록 설계된 AI 기반 적대적 워크로드 세트를 구축하고 있습니다.

어떤 Postgres 버전이 지원되나요? 현재 테스트는 Postgres 15, 16, 17에 집중되어 있습니다. Postgres 13부터 17까지 지원할 계획입니다.

이 프로젝트를 만든 사람은 누구인가요? 이 프로젝트는 Crystal DBA 가 만들고 관리하고 있습니다.

로드맵

미정

여러분과 여러분의 요구는 저희가 만들어가는 모든 것의 핵심입니다. 이슈를 개설하거나 풀 리퀘스트를 통해 어떤 내용을 보고 싶으신지 알려주세요. Discord 를 통해 저희에게 연락하실 수도 있습니다.

기술 노트

이 섹션에서는 Postgres Pro의 디자인에 영향을 준 기술적 고려 사항에 대한 개요를 설명합니다.

인덱스 튜닝

개발자들은 인덱스 누락이 데이터베이스 성능 문제의 가장 흔한 원인 중 하나라는 것을 알고 있습니다. 인덱스는 Postgres가 쿼리 실행에 필요한 데이터를 빠르게 찾을 수 있도록 하는 액세스 방법을 제공합니다. 테이블 크기가 작을 때는 인덱스의 영향이 크지 않지만, 데이터 크기가 커짐에 따라 테이블 스캔과 인덱스 조회 간의 알고리즘 복잡도 차이가 커집니다(일반적으로 O ( n ) 대 O ( logn ) , 여러 테이블 조인이 포함된 경우 더 커질 수 있음).

Postgres Pro에서 제안된 인덱스를 생성하는 과정은 여러 단계로 진행됩니다.

튜닝이 필요한 SQL 쿼리를 파악하세요 . 특정 SQL 쿼리에 문제가 있는 경우 해당 쿼리를 제공할 수 있습니다. Postgres Pro는 워크로드를 분석하여 인덱스 튜닝 대상을 파악할 수도 있습니다. 이를 위해 각 쿼리의 실행 시간과 리소스 사용량을 기록하는 pg_stat_statements 확장 기능을 활용합니다.쿼리가 실행당 또는 전체적으로 리소스를 가장 많이 소비하는 경우 인덱스 튜닝 후보가 됩니다. 현재는 실행 시간을 누적 리소스 소비량의 대리 지표로 사용하지만, 액세스된 블록 수나 디스크에서 읽은 블록 수와 같은 특정 리소스를 살펴보는 것도 유용할 수 있습니다. analyze_query_workload 도구는 실행당 평균 시간과 실행 횟수 및 평균 실행 시간에 대한 임계값을 사용하여 느린 쿼리에 초점을 맞춥니다. 에이전트는 평균 실행 시간 대 전체 실행 시간을 매개변수로 받는 get_top_queries 호출한 후, 해당 쿼리에 대해 analyze_query_indexes 전달하여 인덱스 추천을 얻을 수도 있습니다.정교한 인덱스 튜닝 시스템은 "워크로드 압축"을 사용하여 전체 워크로드의 특성을 반영하는 대표적인 쿼리 하위 집합을 생성함으로써 다운스트림 알고리즘의 문제를 줄입니다. Postgres Pro는 동일한 템플릿에서 생성된 쿼리가 하나로 표시되도록 쿼리를 정규화하여 제한된 형태의 워크로드 압축을 수행합니다. 각 쿼리에 동일한 가중치를 부여하는 이 간소화는 인덱싱의 이점이 클 때 효과적입니다.
후보 인덱스 생성 인덱싱을 통해 개선하고자 하는 SQL 쿼리 목록이 준비되면, 추가할 인덱스 목록을 생성합니다. 이를 위해 SQL 구문을 분석하고 필터, 조인, 그룹화 또는 정렬에 사용된 열을 식별합니다.가능한 모든 인덱스를 생성하려면 Postgres가 다중 열 인덱스를 지원하므로 이러한 열의 조합을 고려해야 합니다. 현재 구현에서는 각 가능한 다중 열 인덱스의 순열을 하나만 포함하며, 이는 무작위로 선택됩니다. 순열은 종종 동일한 성능을 보이기 때문에 검색 공간을 줄이기 위해 이렇게 단순화했습니다. 하지만 이 부분을 개선하고자 합니다.
최적의 인덱스 구성을 검색합니다 . 저희의 목표는 인덱스 저장 및 유지 관리 비용 대비 성능 이점을 최적으로 균형 잡는 인덱스 조합을 찾는 것입니다. hypopg 확장 기능이 제공하는 "what if?" 기능을 사용하여 성능 향상을 예측합니다. 이는 Postgres 쿼리 옵티마이저가 인덱스 추가 후 쿼리를 실행하는 방식을 시뮬레이션하고, 실제 Postgres 비용 모델을 기반으로 변경 사항을 보고합니다.한 가지 과제는 쿼리 계획을 생성하려면 일반적으로 쿼리에 사용된 특정 매개변수 값에 대한 지식이 필요하다는 것입니다. 고려 대상 쿼리를 줄이기 위해 필요한 쿼리 정규화는 매개변수 상수를 제거합니다. 바인드 변수를 통해 제공된 매개변수 값도 마찬가지로 사용할 수 없습니다.이 문제를 해결하기 위해 테이블 통계에서 샘플링하여 매개변수로 제공할 수 있는 현실적인 상수를 생성합니다. Postgres 16 버전에서 일반적인 Explain Plan 기능이 추가되었지만, LIKE 절과 같은 제약이 있는데, 이는 저희 구현에는 없는 기능입니다.검색 전략은 매우 중요합니다. 가능한 모든 인덱스 조합을 평가하는 것은 단순한 상황에서만 가능하기 때문입니다. 이것이 다양한 인덱싱 접근 방식을 구분하는 가장 중요한 요소입니다. Microsoft의 Anytime 알고리즘 방식을 적용하여 탐욕적 검색 전략을 사용합니다. 즉, 최적의 단일 인덱스 솔루션을 찾은 다음, 여기에 최적의 인덱스를 추가하여 두 개의 인덱스 솔루션을 생성합니다. 시간 예산이 소진되거나 탐색 라운드에서 최소 개선 기준인 10% 이상의 성과를 얻지 못하면 검색이 종료됩니다.
비용 편익 분석 . 더 나은 성능을 제공하는 것과 더 많은 공간을 필요로 하는 두 가지 인덱싱 대안이 있을 때, 어떤 것을 선택할지 어떻게 결정해야 할까요? 전통적으로 인덱스 어드바이저는 스토리지 예산을 요청하고 해당 예산에 맞춰 성능을 최적화합니다. 저희도 스토리지 예산을 사용하지만, 최적화 과정 전반에 걸쳐 비용 편익 분석을 수행합니다.이 문제는 파레토 전선(Pareto front)에서 한 지점을 선택하는 문제로 정의됩니다. 파레토 전선 은 한 품질 지표를 개선할 때 다른 지표가 필연적으로 악화되는 선택지 집합입니다. 이상적인 환경에서는 저장 비용과 성능 향상의 이점을 금전적 가치로 평가하고 싶을 것입니다. 하지만 더 간단하고 실용적인 방법이 있습니다. 바로 상대적인 관점에서 변화를 살펴보는 것입니다. 대부분의 사람들은 저장 비용이 두 배라 하더라도 성능이 100배 향상되는 것이 가치 있다는 데 동의할 것입니다. 저희 구현에서는 구성 가능한 매개변수를 사용하여 이 임계값을 설정합니다. 기본적으로 성능 향상의 로그(10진수) 변화가 공간 비용의 로그 차이의 두 배여야 합니다. 이는 100배의 성능 향상을 위해 최대 10배의 공간 증가가 가능하다는 것을 의미합니다.

저희 구현은 Microsoft SQL Server의 Anytime 알고리즘 과 가장 밀접하게 연관되어 있습니다. Postgres용 자동 인덱싱 도구인 Dexter 와 비교했을 때, 저희는 더 넓은 공간을 검색하고 다른 휴리스틱을 사용합니다. 이를 통해 더 긴 런타임을 감수하더라도 더 나은 솔루션을 도출할 수 있습니다.

또한 각 검색 라운드에서 수행된 작업을 보여주고, 각 인덱스 추가 전후의 쿼리 계획을 비교합니다. 이를 통해 LLM은 인덱싱 권장 사항에 응답할 때 활용할 수 있는 추가적인 맥락을 확보할 수 있습니다.

데이터베이스 상태

데이터베이스 상태 점검은 심각한 문제로 이어지기 전에 튜닝 기회와 유지 관리 필요성을 파악합니다. 현재 Postgres Pro 릴리스에서는 PgHero 의 데이터베이스 상태 점검 기능을 그대로 적용했습니다. 저희는 이러한 점검 기능을 완벽하게 검증하기 위해 노력하고 있으며, 향후 확장할 수 있습니다.

인덱스 상태 . 사용되지 않는 인덱스, 중복 인덱스, 그리고 과도하게 사용된 인덱스를 찾습니다. 과도하게 사용된 인덱스는 데이터베이스 페이지를 비효율적으로 사용합니다. Postgres 자동 진공 기능은 사용되지 않는 튜플을 가리키는 인덱스 항목을 정리하고 재사용 가능한 항목으로 표시합니다. 하지만 인덱스 페이지를 압축하지는 않으므로, 결국 인덱스 페이지에는 활성 튜플 참조가 거의 포함되지 않을 수 있습니다.
버퍼 캐시 적중률 . 디스크 대신 버퍼 캐시에서 처리되는 데이터베이스 읽기 작업의 비율을 측정합니다. 낮은 버퍼 캐시 적중률은 비용 최적화에 도움이 되지 않고 애플리케이션 성능 저하로 이어질 수 있으므로 반드시 확인해야 합니다.
연결 상태 . 데이터베이스 연결 수를 확인하고 사용률을 보고합니다. 가장 큰 위험은 연결 부족이지만, 유휴 또는 차단된 연결이 많은 것도 문제를 나타낼 수 있습니다.
진공 상태 . 진공은 여러 가지 이유로 중요합니다. 가장 중요한 이유 중 하나는 데이터베이스가 쓰기 작업을 중단하게 만드는 트랜잭션 ID 랩어라운드를 방지하는 것입니다. Postgres의 다중 버전 동시성 제어(MVCC) 메커니즘은 각 트랜잭션에 대해 고유한 트랜잭션 ID를 요구합니다. 그러나 Postgres는 트랜잭션 ID에 32비트 부호 있는 정수를 사용하기 때문에 최대 20억 개의 트랜잭션 이후에는 트랜잭션 ID를 재사용해야 합니다. 이를 위해 Postgres는 과거 트랜잭션의 트랜잭션 ID를 "고정"하여 먼 과거를 나타내는 특수 값으로 설정합니다. 레코드가 처음 디스크에 저장될 때, 해당 레코드는 특정 범위의 트랜잭션 ID에 대한 가시성을 갖습니다. 이러한 트랜잭션 ID를 재사용하기 전에 Postgres는 디스크에 있는 모든 레코드를 업데이트하여 "고정"하고 재사용할 트랜잭션 ID에 대한 참조를 제거해야 합니다. 이 검사는 트랜잭션 ID 랩어라운드를 방지하기 위해 진공 작업이 필요한 테이블을 찾습니다.
복제 상태 . 기본 복제본과 복제본 간 지연을 모니터링하고, 복제 상태를 확인하고, 복제 슬롯 사용량을 추적하여 복제 상태를 점검합니다.
제약 조건 상태 . 정상적인 작동 중에 Postgres는 제약 조건 위반을 유발하는 모든 트랜잭션을 거부합니다. 그러나 데이터 로드 후 또는 복구 상황에서는 유효하지 않은 제약 조건이 발생할 수 있습니다. 이 검사는 유효하지 않은 제약 조건을 찾습니다.
시퀀스 상태 . 최대값을 초과할 위험이 있는 시퀀스를 찾습니다.

Postgres 클라이언트 라이브러리

Postgres Pro는 psycopg3를 사용하여 비동기 I/O를 통해 Postgres에 연결합니다. psycopg3는 내부적으로 libpq 라이브러리를 사용하여 Postgres에 연결하여 Postgres의 모든 기능 세트와 Postgres 커뮤니티에서 완벽하게 지원하는 기본 구현에 대한 액세스를 제공합니다.

일부 다른 Python 기반 MCP 서버는 asyncpg를 사용하는데, 이는 libpq 종속성을 제거하여 설치를 간소화할 수 있습니다. asyncpg는 psycopg3보다 빠를 가능성이 높지만, 직접 검증하지는 않았습니다. 이전 벤치마크 에서 더 큰 성능 격차가 보고된 것을 보면, 새로운 psycopg3가 성숙해지면서 그 격차를 줄인 것으로 보입니다.

이러한 고려 사항을 종합하여 asyncpg 대신 psycopg3 선택했습니다. 향후 이 결정을 수정할 가능성도 열려 있습니다.

연결 구성

참조 PostgreSQL MCP 서버 와 마찬가지로 Postgres Pro는 시작 시 Postgres 연결 정보를 가져옵니다. 이는 항상 동일한 데이터베이스에 연결하는 사용자에게는 편리하지만, 사용자가 데이터베이스를 전환할 때는 번거로울 수 있습니다.

PG-MCP 가 채택한 대안적인 접근 방식은 사용 시점에 MCP 도구 호출을 통해 연결 세부 정보를 제공하는 것입니다. 이는 데이터베이스를 전환하는 사용자에게 더욱 편리하며, 단일 MCP 서버로 여러 최종 사용자를 동시에 지원할 수 있습니다.

이 둘보다 더 나은 접근 방식이 분명 있을 것입니다. 두 가지 모두 보안 취약점이 있습니다. MCP 클라이언트 중 MCP 서버 구성을 안전하게 저장하는 클라이언트는 거의 없으며(Goose는 예외), MCP 도구를 통해 제공된 자격 증명은 LLM을 통해 전달되어 채팅 기록에 저장됩니다. 또한 두 가지 모두 일부 시나리오에서 사용성 문제가 있습니다.

스키마 정보

스키마 정보 도구의 목적은 호출하는 AI 에이전트에게 정확하고 효율적인 SQL을 생성하는 데 필요한 정보를 제공하는 것입니다. 예를 들어, 사용자가 "지난 1년 동안 샌프란시스코에서 이륙하여 파리에 착륙한 항공편은 몇 편입니까?"라고 질문한다고 가정해 보겠습니다. AI 에이전트는 항공편 정보를 저장하는 테이블, 출발지와 목적지를 저장하는 열, 그리고 공항 코드와 공항 위치를 매핑하는 테이블을 찾아야 합니다.

LLM이 일반적으로 Postgres에서 직접 이 정보를 검색하기 위한 SQL을 생성할 수 있는데 왜 스키마 정보 도구를 제공합니까?

Claude를 사용한 경험에 따르면, 호출하는 LLM은 Postgres 시스템 카탈로그 와 정보 스키마 (ANSI 표준 데이터베이스 메타데이터 뷰)를 쿼리하여 Postgres 스키마를 탐색하는 SQL을 생성하는 데 매우 능숙합니다. 그러나 다른 LLM들이 이 작업을 이처럼 안정적이고 효율적으로 수행하는지는 알 수 없습니다.

MCP 도구 보다는 MCP 리소스를 사용하여 스키마 정보를 제공하는 것이 더 나을까요?

참조 PostgreSQL MCP 서버는 도구 대신 리소스를 사용하여 스키마 정보를 노출합니다. 리소스 탐색은 파일 시스템 탐색과 유사하므로 이러한 접근 방식은 여러 면에서 자연스럽습니다. 그러나 MCP 클라이언트 생태계에서 리소스 지원은 도구 지원보다 덜 널리 퍼져 있습니다( 예제 클라이언트 참조). 또한, MCP 표준에서는 AI 에이전트 또는 최종 사용자(인간)가 리소스에 액세스할 수 있다고 명시되어 있지만, 일부 클라이언트는 리소스 트리의 인간 탐색만 지원합니다.

보호된 SQL 실행

AI는 단순한 실수부터 악의적인 행위자의 정교한 공격에 이르기까지 다양한 위협으로부터 데이터베이스를 보호하는 오랜 과제를 더욱 심화시킵니다. 위협이 우발적이든 악의적이든, 기밀성, 무결성, 가용성이라는 세 가지 범주로 구분되는 목표를 가진 유사한 보안 프레임워크가 적용됩니다. 편의성과 안전성 사이의 익숙한 갈등 또한 분명하고 뚜렷하게 드러납니다.

Postgres Pro의 보호된 SQL 실행 모드는 무결성에 중점을 둡니다. MCP의 맥락에서, 우리는 LLM에서 생성된 SQL이 손상을 유발하는 경우를 가장 중요하게 생각합니다. 예를 들어 의도치 않은 데이터 수정 또는 삭제, 또는 조직의 변경 관리 프로세스를 우회할 수 있는 기타 변경 사항이 발생할 수 있습니다.

무결성을 보장하는 가장 간단한 방법은 데이터베이스에 대해 실행되는 모든 SQL을 읽기 전용으로 설정하는 것입니다. 한 가지 방법은 읽기 전용 접근 권한을 가진 데이터베이스 사용자를 생성하는 것입니다. 이는 좋은 방법이지만, 실제로는 많은 사람들이 번거롭다고 생각합니다. Postgres는 연결이나 세션을 읽기 전용 모드로 전환하는 방법을 제공하지 않으므로, Postgres Pro는 읽기-쓰기 연결에서 읽기 전용 SQL 실행을 보장하기 위해 더 복잡한 방식을 사용합니다.

Postgres는 데이터 및 스키마 수정을 방지하는 읽기 전용 트랜잭션 모드를 제공합니다. 참조 PostgreSQL MCP 서버 와 마찬가지로, Postgres는 읽기 전용 트랜잭션을 사용하여 보호된 SQL 실행을 제공합니다.

이 메커니즘을 강력하게 만들기 위해서는 SQL이 COMMIT 이나 ROLLBACK 명령문을 발행한 다음 새로운 트랜잭션을 시작하는 등 읽기 전용 트랜잭션 모드를 우회하지 않도록 해야 합니다.

예를 들어, LLM은 ROLLBACK 문을 실행한 후 새 트랜잭션을 시작하여 읽기 전용 트랜잭션 모드를 우회할 수 있습니다. 예를 들면 다음과 같습니다.

ROLLBACK; DROP TABLE users;

이러한 문제를 방지하기 위해 pglast 라이브러리를 사용하여 실행 전에 SQL 구문을 분석합니다. commit 또는 rollback 문이 포함된 SQL은 모두 거부합니다. 다행히도 PL/pgSQL 및 PL/Python을 포함한 널리 사용되는 Postgres 저장 프로시저 언어는 COMMIT 또는 ROLLBACK 문을 허용하지 않습니다. 데이터베이스에 안전하지 않은 저장 프로시저 언어가 활성화되어 있는 경우, 읽기 전용 보호 기능을 우회할 수 있습니다.

현재 Postgres Pro는 데이터베이스에 대해 두 가지 수준의 보호를 제공합니다. 하나는 편의성/안전성 스펙트럼의 양쪽 극단에 위치합니다.

"제한 없음"은 최대한의 유연성을 제공합니다. 속도와 유연성이 가장 중요하고 중요하거나 민감한 데이터를 보호할 필요가 없는 개발 환경에 적합합니다.
"제한됨"은 유연성과 안전성의 균형을 제공합니다. 데이터베이스가 신뢰할 수 없는 사용자에게 노출되고 중요하거나 민감한 데이터를 보호하는 것이 중요한 프로덕션 환경에 적합합니다.

제한 없음 모드는 AI 에이전트가 제한된 인적 감독이나 승인 하에 작동하는 Cursor의 자동 실행 모드 와 같은 접근 방식입니다. 자동 실행은 실수의 결과가 적고, 데이터베이스에 중요하거나 민감한 데이터가 없으며, 필요 시 백업을 통해 재생성하거나 복원할 수 있는 개발 환경에 배포될 것으로 예상됩니다.

제한 모드는 불편할 수 있지만, 안전성을 고려하여 보수적으로 설계되었습니다. 제한 모드는 읽기 전용 작업으로 제한되며, 장시간 실행되는 쿼리가 시스템 성능에 영향을 미치지 않도록 쿼리 실행 시간을 제한합니다. 향후 프로덕션 데이터베이스에서 제한 모드를 안전하게 사용할 수 있도록 조치를 추가할 수 있습니다.

Postgres Pro 개발

아래 지침은 Postgres Pro에서 작업하려는 개발자나 소스에서 Postgres Pro를 설치하려는 사용자를 위한 것입니다.

지역 개발 설정

uv 설치 :
curl -sSL https://astral.sh/uv/install.sh | sh
저장소를 복제합니다 .
git clone https://github.com/crystaldba/postgres-mcp.git cd postgres-mcp
종속성 설치 :
uv pip install -e . uv sync
서버를 실행합니다 :
uv run postgres-mcp "postgres://user:password@localhost:5432/dbname"

Integrations

개요

데모