🦀 Rust가 PostgreSQL을 조용히 집어삼키고 있다? Neon, ParadeDB, PgDog 완전 분석

 

"PostgreSQL은 그냥 데이터베이스 아닌가요?" 아직도 그렇게 생각하세요?

솔직히 저도 처음엔 그렇게 생각했어요. PostgreSQL이라는 이름을 듣고 "아, 그 오래된 오픈소스 DB 말하는 거지?" 하고 넘어갔거든요. 그런데 최근에 데이터베이스 업계를 조금 깊이 들여다보고 나서 완전히 생각이 바뀌었습니다.

지금 이 순간, PostgreSQL 생태계 안에서 조용하지만 굉장히 강력한 혁명이 진행되고 있어요. 그리고 그 중심에 Rust라는 프로그래밍 언어가 있습니다. Neon, ParadeDB, PgDog 같은 이름들이 심심찮게 들리기 시작했다면, 이 흐름을 이해해야 할 타이밍이 온 겁니다.

오늘은 이 흐름을 처음 접하는 분들도 쉽게 이해할 수 있도록, 배경부터 실무 활용 팁까지 차근차근 풀어보겠습니다.

---

PostgreSQL은 왜 이렇게 오래 살아남았을까요?

데이터베이스 세계는 참 오래된 세계입니다. Oracle, MySQL, MS SQL Server 같은 이름들이 수십 년째 버티고 있는데, 새로운 도전자들이 끊임없이 등장해도 좀처럼 무너지지 않았죠.

그중에서도 PostgreSQL은 독특한 포지션을 차지하고 있어요. 오픈소스이면서도 엔터프라이즈급 기능을 갖추고 있고, 확장성이 뛰어나며, 커뮤니티도 활발합니다. 매년 Stack Overflow 개발자 설문에서 '가장 많이 사용하는 데이터베이스' 상위권에 꾸준히 이름을 올리는 데는 다 이유가 있어요.

그런데 2025년 들어 이 PostgreSQL을 둘러싼 생태계에 흥미로운 변화가 생겼습니다. Databricks가 Neon을 인수하면서 업계 전체가 PostgreSQL의 진화에 다시 한번 주목하기 시작했거든요.

단순히 "좋은 DB"를 넘어서, PostgreSQL은 이제 하나의 "데이터 커널"로 진화하고 있습니다. 어떻게 데이터가 저장되고, 조회되고, 분산되는지를 관리하는 핵심 인프라로 자리잡고 있는 거예요. 그리고 그 커널 주변을 Rust가 조용히 교체해 나가고 있습니다.

---

Rust가 왜 데이터베이스 세계에서 주목받는 걸까요?

2024년 Stack Overflow 개발자 설문조사에서 Rust는 9년 연속 '가장 사랑받는 프로그래밍 언어'로 선정됐습니다. 응답 개발자의 87%가 "계속 쓰고 싶다"고 답했을 정도예요.

이게 단순한 유행이 아닌 이유가 있어요.

첫 번째, 메모리 안전성입니다. Google 보안팀 Project Zero 보고서에 따르면, 제로데이 취약점의 약 68%가 메모리 관련 문제에서 비롯된다고 해요. 기존 데이터베이스 인프라는 C나 C++로 작성된 게 많은데, 이 언어들은 바로 이 부분에서 취약합니다. Rust는 가비지 컬렉터 없이도 컴파일 시점에 메모리 오류를 잡아냅니다.

두 번째, 성능입니다. C/C++ 수준의 속도를 내면서도 안전하다는 게 핵심이에요. 데이터베이스는 밀리초 단위의 처리 성능이 실제 서비스 품질에 직결되는 영역이다 보니, 이 강점이 더 빛을 발합니다.

세 번째, 생태계 확장성입니다. 리눅스 커널, 마이크로소프트 윈도우 커널에도 Rust가 도입되고 있고, Amazon도 AWS 서비스 일부를 Rust로 개발하고 있어요. 이제 그 흐름이 데이터베이스 인프라 안으로도 깊숙이 들어오고 있는 겁니다.

저장하고 싶은 문장: "PostgreSQL은 안 바뀌는 게 아니라, 바뀌는 방식이 남다른 겁니다."

---

Neon: PostgreSQL을 서버리스로 완전히 재설계하다

Neon 이야기를 빼놓을 수가 없어요. 2025년 Databricks에 인수된 이후 업계의 관심이 엄청나게 집중됐거든요.

Neon의 핵심 혁신은 컴퓨팅과 스토리지의 분리입니다. 기존 PostgreSQL은 컴퓨팅 레이어와 스토리지 레이어가 한 덩어리로 묶여 있었어요. Neon은 이걸 과감하게 쪼개놨습니다.

컴퓨팅 레이어는 무상태(stateless) PostgreSQL 인스턴스로 구성되어 있고, 스토리지 레이어는 Rust로 개발되어 성능과 효율성을 극대화했어요. 이 스토리지 시스템은 Git처럼 카피-온-라이트(Copy-on-Write) 방식을 쓰기 때문에, 데이터 브랜칭과 타임트래블 복원이 가능합니다.

실수로 테이블을 DROP해서 날려버린 경험 있으세요? Neon에서는 수 밀리초 단위까지 이전 상태로 되돌릴 수 있어요. WAL(Write-Ahead Log) 레코드를 통해 데이터의 전체 이력을 보존하기 때문입니다.

비용 측면에서도 큰 변화가 있었어요. 2025년 8월 Databricks 인수 이후 새로운 가격 정책을 발표했는데, 컴퓨팅 비용은 15~25% 인하되고, 스토리지 비용은 GB당 1.75달러에서 0.35달러로 무려 80%나 낮아졌습니다. 프리 플랜의 컴퓨팅 허용량도 월 50 CU시간에서 100 CU시간으로 두 배가 됐고요.

사용하지 않을 때는 컴퓨팅이 자동으로 꺼지고(scale to zero), 필요할 때만 켜지는 구조이기 때문에 트래픽이 들쑥날쑥한 스타트업이나 사이드 프로젝트에 최적화되어 있어요.

저장하고 싶은 문장: "실수로 날린 데이터도 되살릴 수 있다면, 그건 데이터베이스가 아니라 타임머신입니다."

---

ParadeDB: PostgreSQL 안에 Elasticsearch를 집어넣다

검색 기능이 필요한 서비스를 만들어본 분들은 아실 거예요. "전문 검색은 Elasticsearch 써야지"라고 자연스럽게 생각하게 되죠.

그런데 Elasticsearch를 운영하는 게 생각보다 만만치 않아요. PostgreSQL 따로, Elasticsearch 따로 운영해야 하고, 두 시스템 간 데이터 동기화도 신경써야 하고, 비용도 두 배로 들어갑니다.

ParadeDB는 이 문제를 PostgreSQL 한 곳에서 해결합니다. pg_search라는 확장 기능을 통해 Elasticsearch와 동일한 수준의 전문 검색을 PostgreSQL 안에서 그대로 쓸 수 있어요.

이게 어떻게 가능하냐면, Rust 기반의 pgrx 프레임워크를 활용해서 PostgreSQL 확장으로 만들었기 때문입니다. BM25 알고리즘을 구현해서 검색 결과 랭킹도 Elasticsearch 수준으로 제공해요.

기존 PostgreSQL의 기본 전문 검색 방식인 tsvector/tsquery는 검색 결과 품질이 그리 좋지 않아요. 관련성 기반 정렬에 최적화되어 있지 않거든요. ParadeDB의 pg_search는 BM25 인덱스와 역방향 인덱스로 이 한계를 극복합니다.

외부 서비스 없이, 추가 인프라 없이, PostgreSQL 하나로 검색까지 해결되는 구조예요.

---

PgDog: PostgreSQL 연결 관리를 Rust로 새로 쓰다

대규모 서비스를 운영해보신 분들은 느끼셨을 거예요. 데이터베이스 연결 관리가 얼마나 중요한지를요.

수천 명의 사용자가 동시에 접속하는 순간, 데이터베이스 연결이 제대로 관리되지 않으면 서버가 버텨내질 못해요. PgBouncer 같은 커넥션 풀러가 바로 이 문제를 해결하는 도구인데, PgDog는 이걸 Rust로 완전히 새로 구현한 버전이라고 보면 됩니다.

PgDog의 핵심 기능은 세 가지예요. 커넥션 풀링, 로드밸런싱, 샤딩 프록시입니다. 단일 엔드포인트에서 읽기 쿼리는 복제본으로, 쓰기 쿼리는 프라이머리로 자동 라우팅되고, 샤딩된 데이터베이스 간 쿼리 결과도 통합해줍니다.

최근 공개된 내용에 따르면, PgDog 팀은 Protobuf 직렬화를 Rust 네이티브 바인딩으로 교체해서 쿼리 파싱 속도를 5배, 역파싱 속도를 10배 향상시키는 성과를 냈어요. 이런 식으로 내부 성능 최적화가 지속적으로 이뤄지고 있습니다.

커넥션 풀링과 읽기 복제본 라우팅을 통해 PostgreSQL 서버 프로세스 수를 최대 70%까지 줄일 수 있다고 알려져 있어요. AWS RDS나 Azure Database for PostgreSQL 같은 클라우드 환경에서 직접적인 비용 절감 효과가 발생하는 거죠.

---

이 세 프로젝트의 공통점: 바퀴를 새로 만들지 않는다

Neon, ParadeDB, PgDog를 보면서 흥미로운 공통점을 발견했어요.

이 세 프로젝트는 새로운 데이터베이스를 만들려고 하지 않아요. PostgreSQL이라는 이미 검증된 토대 위에서, 각자의 방식으로 특정 문제를 해결합니다.

Neon은 아키텍처 문제를 해결했어요. 컴퓨팅과 스토리지를 분리해서 서버리스를 가능하게 했습니다. ParadeDB는 검색 통합 문제를 해결했어요. 별도의 검색 엔진 없이 PostgreSQL 안에서 전문 검색을 구현했습니다. PgDog는 연결 관리 문제를 해결했어요. 대규모 접속 환경에서 안정적인 라우팅과 풀링을 제공합니다.

그리고 세 프로젝트 모두 성능 임계치가 중요한 레이어는 Rust로 구현했습니다. 이건 우연이 아니에요. 데이터베이스 인프라에서 메모리 안전성과 C급 성능이 동시에 필요한 영역이 바로 이 레이어들이거든요.

흥미롭게도 이 트렌드는 "bottom-up"과 "top-down" 두 방향으로 동시에 진행되고 있어요. ParadeDB처럼 pgrx를 통해 PostgreSQL 내부에서 Rust 생태계를 확장하는 방식이 있고, GreptimeDB처럼 PostgreSQL 프로토콜을 시뮬레이션해서 "PostgreSQL처럼 보이는" 새로운 데이터베이스를 Rust로 만드는 방식도 있습니다.

저장하고 싶은 문장: "PostgreSQL 자체가 바뀌는 게 아니라, 그 주변 생태계 전체가 Rust로 다시 태어나고 있습니다."

---

우리나라 개발자와 팀은 이걸 어떻게 활용해야 할까요?

솔직히 지금 당장 기존 시스템을 전부 교체할 필요는 없어요. 실무 현장에서는 검증된 도구의 안정성과 운영 경험이 여전히 가장 중요한 선택 기준이니까요.

그런데 새로운 프로젝트를 시작할 때라면 이야기가 달라집니다.

트래픽이 들쑥날쑥한 사이드 프로젝트나 스타트업 초기 단계라면 Neon이 정말 좋은 선택이에요. 프리 플랜만으로도 의미있는 개발 작업이 충분히 가능하고, 쓴 만큼만 비용이 나가는 구조라 부담이 훨씬 덜합니다. 앱 내에 검색 기능이 필요한데 Elasticsearch 클러스터를 따로 운영하기 부담스럽다면, ParadeDB의 pg_search를 PostgreSQL에 확장으로 붙이는 방법을 검토해볼 만합니다. 동시 접속자가 많거나 읽기/쓰기 트래픽을 분산해야 하는 상황이라면 PgDog가 PgBouncer보다 더 현대적인 선택지가 될 수 있어요.

무엇보다 중요한 건 이 흐름 자체를 이해하는 것입니다. Rust가 PostgreSQL 생태계를 조용히 재편하고 있다는 사실을 미리 알고 있는 개발자와, 1~2년 후에 뒤늦게 알게 되는 개발자 사이에는 분명한 차이가 생길 거예요.

저장하고 싶은 문장: "트렌드는 먼저 아는 사람이 활용하고, 나중에 아는 사람이 따라갑니다."

---

마무리

Rust는 단순한 '뜨는 언어'가 아닙니다. 메모리 안전성과 C급 성능이라는 두 마리 토끼를 동시에 잡은 언어로, 지금 데이터베이스 인프라의 핵심 레이어들을 하나씩 새로 써 내려가고 있습니다.

Neon은 서버리스 아키텍처로 PostgreSQL의 한계를 넘었고, ParadeDB는 검색 엔진 통합 문제를 해결했으며, PgDog는 대규모 연결 관리를 혁신했습니다. 이 세 프로젝트는 모두 PostgreSQL을 버리는 게 아니라, PostgreSQL을 더 강하게 만들고 있어요.

PostgreSQL은 사라지지 않아요. 오히려 Rust 생태계 덕분에 새 생명을 얻고 있습니다. 이 흐름을 먼저 이해하고 실무에 적용하는 팀이, 다음 세대 인프라의 주인공이 될 거라고 생각합니다.