DB May 20, 2026 8 min read

AI assisted

In-DB AI 5종 비교 — 대부분이 잘못된 추상화인 이유

Oracle 23ai · EDB AIDB · PostgresML · Timescale pgai · pg_aidb — 다섯 시스템 비교와 추상화 경계 논의

#PostgreSQL #AI #RAG #in-db-ai #pgai #Oracle #EnterpriseDB #Timescale #Supabase #MongoDB #ClickHouse #architecture

Oracle 23ai, EDB AIDB, PostgresML, Timescale pgai, pg_aidb — 다섯 시스템 모두 PostgreSQL을 비롯한 OLTP 데이터베이스에 AI 기능을 통합하려는 시도입니다. 그러나 process-per-connection 모델과 수초 단위 AI I/O가 결합되면 커넥션 풀이 곧 병목이 되고, 같은 매력에 끌린 다섯 시스템이 그 한계에 서로 다른 방식으로 부딪힙니다. 이 글에서는 다섯 시스템의 비교, process-per-connection × AI I/O 제약, 추상화 경계 문제, 그리고 pg_aidb의 위치를 정리합니다.

왜 DB 안에 AI 기능을 두려고 하는가

데이터가 이미 DB에 있으면, AI 함수에 넘기기 위해 애플리케이션으로 끌어올리고 다시 내려보내는 왕복 비용이 없습니다. 이 논리는 두 가지 근거 위에 서 있습니다.

첫째는 **데이터 중력(data gravity)**입니다. 데이터가 이미 DB에 있으면, AI 함수에 넘기기 위해 애플리케이션으로 끌어올리고 다시 내려보내는 왕복 비용이 없습니다. 네트워크 홉 하나가 줄어들면 latency만 줄어드는 게 아닙니다. 직렬화·역직렬화, 오류 처리, 트랜잭션 경계 재조율 같은 복잡도가 통째로 사라집니다.

둘째는 SQL 친화성입니다. DBA, 데이터 분석가, BI 도구 — 이미 SQL을 쓰는 사람들이 Python을 배우거나 새 API를 익히지 않아도 AI 기능을 쓸 수 있다는 제안은 분명한 가치가 있습니다.

SELECT ai.generate(
    query    => '이 문서를 요약해줘',
    pipeline => 'docs',
    model    => 'gpt-4o'
);

in-DB ML 진영의 주장 중 유일하게 진지한 근거가 있다면 zero-copy, 데이터 이동 최소화입니다. SELECT로 꺼낸 데이터가 이미 DB 메모리에 올라 있으면 직렬화·네트워크 비용이 0에 가깝고, 효율성 측면에서 그 이점은 실재합니다. 그러나 현대 AI 워크로드에서 이 근거가 얼마나 유지되는지는 별개의 문제입니다.

Agentic AI는 compute-heavy입니다. LLM 호출 한 번에 1~30초가 걸리고, 페이로드 이동 비용은 수십 ms 수준이며, 병목은 완전히 다른 곳에 있습니다. RAG·검색증강은 top-k ANN 인덱스로 처리하면 결과 집합이 작아 zero-copy의 이점이 극적으로 줄어듭니다. 전통 ML(예측·클러스터링)에서도 in-DB ML은 모델 범위가 좁고 GPU 활용·배치 최적화 측면에서 외부 ML 프레임워크와 격차가 큽니다. DB의 트랜잭션 안전성이 ML과 동일한 경계 안에서 결합되어야 하는 시나리오는 드뭅니다.

더 유망한 방향은 open format의 표준화입니다. Iceberg·Parquet·Lance·Arrow 같은 포맷으로 외부 컴퓨트 엔진 — Spark, Ray, DuckDB, ClickHouse, Polars, vLLM — 이 zero-copy에 가까운 비용으로 데이터에 접근합니다. 데이터를 옮기는 것이 아니라 포맷을 표준화해서 컴퓨트를 데이터에 가져오는 방식으로, 같은 결과를 훨씬 모듈러하게 달성합니다.

근본 제약: process-per-connection × 수초 AI I/O

PostgreSQL은 process-per-connection 모델입니다.

클라이언트 연결 1개 = OS 프로세스 1개
프로세스가 I/O 대기 중 = 그 커넥션은 완전히 멈춤

비동기 I/O(epoll, io_uring)나 스레드 기반 모델이 아닙니다. 하나의 백엔드 프로세스가 블록되면 그 커넥션은 다른 어떤 일도 처리할 수 없습니다.

AI 연산은 모두 느립니다.

연산	지연 시간
쿼리 임베딩 (OpenAI API)	200ms ~ 1s
로컬 ONNX 임베딩	100ms ~ 수초
리랭킹	100ms ~ 수초
LLM 생성	1s ~ 30s+

ONNX는 외부 API 대비 상대적으로 빠른 것이지, 절대적으로 빠른 것이 아닙니다. 어느 쪽이든 수백ms는 넘습니다.

두 제약이 결합되면 다음 흐름이 됩니다.

동시 요청 100개 → ai.generate() 호출
→ 백엔드 프로세스 100개가 전부 LLM 응답 대기 중 (1~30초)
→ 새 커넥션 거부
→ max_connections = 100이면 서비스 다운

PgBouncer를 써도 해결되지 않습니다. transaction mode에서 LLM 호출 중에는 커넥션을 돌려받을 수 없습니다. AI 함수 호출이 곧 트랜잭션 점유이기 때문입니다.

느린 I/O가 동기 쿼리 경로에 있으면, 어떤 설계를 해도 커넥션 풀이 병목이 됩니다. 더 좋은 extension으로 극복할 수 있는 문제가 아닙니다. PostgreSQL 아키텍처의 근본 특성에 가깝습니다.

다섯 시스템의 대응

Oracle 23ai/26ai

Oracle이 가장 공격적으로 "AI-native DB"를 선언한 플레이어입니다. DBMS_VECTOR_CHAIN PL/SQL 패키지, VECTOR_EMBEDDING() 함수, in-process ONNX 런타임까지 갖췄습니다.

임베딩 블로킹 문제는 실제로 일부 해결했습니다. ONNX Runtime을 DB 프로세스 안에서 실행하면 네트워크 I/O 없이 임베딩이 생성됩니다. SGA(공유 메모리)에 HNSW 그래프를 상주시키는 방식도 영리합니다.

그러나 GPT-4, Claude, 그 외 외부 LLM API는 여전히 HTTP고, 여전히 블로킹입니다. LLM 생성 단계(1초~30초 이상)에 대한 해결책이 없습니다. ONNX로 변환 가능한 소형 모델 범위 안에서만 블로킹이 해소되는 것이고, 실제로 원하는 GPT-4급 LLM 생성 워크로드에서는 동일한 벽에 부딪힙니다. Exadata 없는 일반 배포에서 "AI-native" 성능을 선전하는 것은 과장에 가깝습니다.

Oracle DB에 데이터가 있는 기업이 AI 기능을 추가하는 경로로는 가장 마찰이 적기 때문에 배치 인제스천이나 DBA 중심 AI 실험 시나리오에서 시장은 존재합니다. 고동시성 실시간 서빙에서의 한계는 구조적입니다.

EnterpriseDB AIDB

EDB의 접근은 Oracle보다 솔직합니다. aidb.retrieve(), aidb.retrieve_and_generate() 함수로 SQL 인터페이스를 제공하고, 인제스천은 Background Worker로 비동기 처리합니다.

aidb.set_auto_preparer()로 파이프라인을 등록하면 BGW가 새 데이터를 감지해 자동으로 처리합니다. 배치성 인제스천에서는 이 설계가 합리적입니다.

문제는 쿼리 타임입니다. aidb.retrieve() 호출 시 임베딩 생성과 벡터 검색은 동기 HTTP고, aidb.retrieve_and_generate()에서 LLM 생성도 동기입니다. BGW 기반 인제스천과 동기 쿼리의 조합은 파이프라인 빌드 단계와 서빙 단계 사이에 비대칭을 만듭니다. 인제스천은 안전하고, 조회는 여전히 병목입니다.

PostgresML (pgml)

pgml은 모델 가중치를 DB 안에 두는 설계입니다. pgml.transform()을 호출하면 PostgreSQL 프로세스 안에서 모델 추론이 일어납니다. 개념적으로는 가장 순수한 in-DB AI 구조입니다.

프로젝트는 2024년 이후 사실상 중단된 상태입니다.

모델 가중치를 DB 프로세스 메모리에 올리는 것 자체가 구조적 문제입니다. DB는 메모리·GPU·격리 측면에서 모델 서빙에 최적화되어 있지 않습니다. 모델 업데이트, 배치 추론 최적화, GPU 메모리 관리 — 이 모든 것이 DB 바깥에서 해결해야 할 문제입니다.

비즈니스 로직(어떤 모델을 쓸지, 어떻게 추론할지)은 애플리케이션 레이어의 책임입니다. 그것을 DB extension에 넣는 순간 배포 파이프라인이 DB 릴리스 사이클에 종속되고, 모델 실험 속도가 DBA의 승인 절차에 묶입니다. 리소스 격리 불가, GPU 메모리 공유, 모델 라이프사이클 관리의 어려움이 이 설계의 실질적 한계입니다.

Timescale pgai + vectorizer-worker

구조가 명확합니다. DB는 큐, config, embedding storage만 담당합니다. 실제 인제스천 처리는 PostgreSQL 밖의 별도 프로세스인 vectorizer-worker가 맡습니다. 워커가 작업 큐를 폴링하고, 비동기 HTTP로 임베딩을 생성하고, 결과를 PostgreSQL에 저장합니다.

쿼리 타임은 ai.openai_chat_complete() 같은 함수를 PL/Python으로 노출하는데, 이 부분은 여전히 동기입니다. 그러나 인터랙티브 쿼리와 배치 인제스천을 명시적으로 분리하고, 무거운 쪽을 DB 밖으로 뺀 설계입니다.

PostgreSQL은 빠른 ANN 검색을 잘 합니다 — 그 부분을 DB에 두고, 느린 외부 API 호출은 외부 워커에 위임했습니다. 외부 워커 분리라는 설계 선택이 블로킹 영향을 인제스천 경로에서 제거합니다.

pg_aidb

pg_aidb는 SQL 인터페이스의 편의와 블로킹의 한계를 명시적으로 분리해서 다룹니다.

ai.embed_raw, ai.search: 동기 방식. 개발·분석·저동시성 운영용. 커넥션 점유를 명시적으로 수용합니다.
ai.ingest, ai.ask, *_async: NOTIFY + ai.results 폴링 방식. 커넥션이 AI 처리 중 해방됩니다.

Timescale과 유사하게 무거운 컴퓨트는 외부 pipeline-worker와 rag 서비스가 담당하고, extension은 SQL 인터페이스와 큐·결과 영속만 맡습니다.

종합 비교

	Oracle 23ai/26ai	EDB AIDB	PostgresML	Timescale pgai	pg_aidb
비즈니스 로직 침투도	높음	중간	매우 높음	낮음	낮음
Ingestion 인터페이스 일관성	중간	중간	높음 (모두 in-process)	높음 (외부 워커 분리)	높음 (dual-mode 명시)
블로킹 대응	임베딩만 부분 해소	인제스천만	없음	인제스천 분리	dual-mode (sync + async)
추상화 경계 명확성	낮음	중간	매우 낮음	높음	높음

비즈니스 로직 침투도는 낮을수록, Ingestion/Search 인터페이스 일관성과 추상화 경계 명확성은 높을수록 좋습니다.

표를 종합하면 Timescale pgai와 pg_aidb가 외부 워커 분리·dual-mode로 블로킹 영향을 줄이는 설계에 가깝습니다.

같은 접근이 반복되는 구조적 배경

Oracle, EDB, PostgresML 모두 기존 DB 제품 위에 AI 기능을 올리는 방식으로 접근합니다. 이미 가진 것(DB 엔진, 고객 관계, SQL 생태계)을 최대한 활용하려는 논리인데, 새로운 추상화를 설계하는 것보다 기존 extension 메커니즘에 AI 함수를 추가하는 것이 출시 속도가 빠릅니다. 영업 측면에서도 "기존 Oracle/EDB를 쓰면 AI까지 된다"는 메시지는 단순하고 효과적입니다.

DB extension은 비즈니스 로직을 담기 위한 메커니즘이 아닙니다. 데이터 인프라 레이어의 책임과 애플리케이션 레이어의 책임을 섞어놓으면 두 레이어 모두 나빠집니다. DB는 배포 단위가 무거워지고, 애플리케이션은 DB 릴리스에 종속됩니다.

DB 코어를 얇게 유지하는 플랫폼 패턴

DB 코어는 얇게 유지하고, 주변 레이어를 vertical하게 묶는 패턴이 시장에서 이미 검증되고 있습니다.

Timescale + pgvectorscale + pg_textsearch + pgai: PostgreSQL은 저장·검색 엔진으로 유지하고, pgvectorscale로 ANN 성능을 강화하고, pg_textsearch로 BM25를 추가하고, pgai는 SQL 인터페이스만 제공합니다. AI 연산 자체는 외부 서비스와 vectorizer-worker가 담당합니다. DB 코어의 역할이 명확하게 제한됩니다.

MongoDB + Atlas: MongoDB 자체는 문서 저장소입니다. Atlas가 그 위에 검색, 벡터, 스트리밍, 분석을 vertical하게 묶습니다. 비즈니스 로직은 Atlas 위에서 돌아가는 애플리케이션의 책임이지, MongoDB 엔진의 책임이 아닙니다.

PostgreSQL + Supabase: Supabase는 PostgreSQL을 그대로 쓰면서 그 주변에 Auth, Storage, Edge Functions, Realtime을 vertical하게 올립니다. PostgreSQL은 건드리지 않습니다. 새로운 추상화는 모두 PostgreSQL 바깥에 있습니다.

ClickHouse + ClickStack: ClickHouse 코어는 OLAP 엔진으로 유지하면서, ClickStack이 시각화·모니터링·ML 파이프라인을 묶습니다.

네 사례 모두 DB 코어를 얇게 유지하고 주변 vertical 레이어로 사용 경험을 통합하는 공통 구조를 갖습니다.

pg_aidb의 위치

pg_aidb는 PostgreSQL의 성숙도(트랜잭션, pg_dump, RLS, SQL 생태계)를 storage 엔진으로 활용하면서, extension + services + Docker 한 패키지로 에이전트 시스템의 검색·메모리 레이어를 제공하는 것을 목표로 합니다.

에이전트가 필요로 하는 것은 RAG(semantic memory)만이 아닙니다. 대화 이력(episodic memory), 세션 단기 컨텍스트(working memory), 학습된 절차 카탈로그(procedural memory), 이 모든 것에 대한 메타 통계가 동시에 필요합니다. 이것들을 벡터 DB + 시계열 DB + Redis + 별도 레지스트리로 조립하면 5개 시스템이 됩니다. 일관성·백업·권한·SQL 인터페이스를 다 따로 관리해야 합니다.

pg_aidb는 이 vertical 묶음을 단일 배포 패키지로 제공합니다. 후속 글에서 dual-mode API와 메모리 레이어 구현을 다룹니다.

마무리

다섯 시스템은 process-per-connection × AI I/O 제약을 서로 다른 위치에서 다룹니다. Oracle과 EDB는 SQL 인터페이스를 유지하면서 부분적인 비동기화를, Timescale은 외부 워커로의 명시적 분리를, PostgresML은 in-process 모델을 시도했습니다. 추상화 경계를 어디에 두느냐가 각 시스템의 운영 특성을 결정합니다.