본문으로 건너뛰기
피드

펜타시스템·EDB, 국내 오픈소스 DBMS 전환 시장 공략

backend 약 5분
vote
0
댓글
북마크

펜타시스템이 EDB와 파트너십을 맺고 엔터프라이즈 오픈소스 데이터 플랫폼 시장에 본격적으로 들어간다. 핵심은 PostgreSQL 기반 대안 DBMS로 공공·금융·제조 영역의 비용 절감, 고가용성, 백업·복구 수요를 잡겠다는 전략이다.

  • 1

    EDB PostgreSQL을 앞세워 기업용 오픈소스 데이터 플랫폼 시장을 공략

  • 2

    고성능, 고가용성, 복제, 백업·복구, 보안 기능을 엔터프라이즈 요구사항으로 제시

  • 3

    공공·금융·제조, ERP, DW, 빅데이터, 클라우드, AI 분석 환경을 주요 적용 분야로 언급

  • 4

    기존 상용 DBMS에서 전환할 때 호환성으로 비용과 리스크를 줄이는 게 핵심 메시지

  • 펜타시스템테크놀러지가 EDB와 손잡고 국내 엔터프라이즈 오픈소스 데이터 플랫폼 시장을 공략함

    • 펜타시스템은 기업용 솔루션 공급과 IT 서비스 컨설팅을 해온 회사고, EDB는 PostgreSQL 기반 엔터프라이즈 데이터 플랫폼을 밀고 있는 업체임
    • 이번 계약은 단순 리셀링이라기보다, 오픈소스 기반 통합 데이터 플랫폼 사업으로 영역을 넓히겠다는 신호에 가까움
  • 핵심 제품은 EDB PostgreSQL임. 그냥 “오픈소스 DB 써보자” 수준이 아니라 기업 운영 요구사항을 전면에 내세움

    • 고성능, 고가용성, 복제, 백업·복구, 보안 기능을 지원한다고 강조함
    • 클라우드, AI, 빅데이터 환경에서 유연하게 대응할 수 있는 데이터 인프라를 만들겠다는 포지션임
    • 특히 기존 DBMS와의 호환성을 내세워 전환 비용과 리스크를 줄일 수 있다고 봄

중요

> 이 뉴스의 포인트는 PostgreSQL 자체보다 “상용 DBMS 비용 부담을 줄이면서도 엔터프라이즈 운영 요건을 맞출 수 있느냐”임.

  • 적용 대상으로는 꽤 현실적인 시장을 찍고 있음

    • 금융권 차세대 시스템, 공공기관 정보시스템, 제조·유통 ERP, 데이터웨어하우스(DW), 빅데이터 플랫폼, 클라우드 기반 서비스, AI 데이터 분석 환경이 언급됨
    • 한국 SI·엔터프라이즈 시장에서 DBMS 전환 수요가 실제로 많은 영역들이라 그냥 홍보 문구로만 보긴 어려움
  • 펜타시스템은 “대안 DBMS” 시장을 집중 공략하겠다는 입장임

    • 기업들이 비용 효율성과 안정성을 동시에 원한다는 전제를 깔고 있음
    • 레퍼런스를 확보한 뒤 클라우드, AI, DW 연계 사업까지 넓히겠다는 계획임
    • 장기적으로는 고가용성, 백업·복구까지 포함하는 통합 데이터 플랫폼 사업으로 확장하려는 그림임
  • EDB 쪽 메시지는 “오픈소스 전환”과 “데이터 주권”임

    • 국내 기업이 엔터프라이즈급 오픈소스로 넘어가는 과정을 지원하겠다고 밝힘
    • 공공·금융·제조처럼 규제와 운영 안정성이 중요한 시장에서 데이터 주권이라는 키워드는 꽤 잘 먹히는 카드임

기술 맥락

  • 여기서 중요한 선택은 PostgreSQL 계열을 엔터프라이즈 DBMS 대안으로 쓰겠다는 거예요. 기존 상용 DBMS는 안정적이지만 라이선스와 유지보수 비용이 커질 수 있어서, 비용을 줄이면서도 운영 안정성을 포기하지 않는 선택지가 필요하거든요.

  • EDB PostgreSQL이 기사에서 계속 강조되는 이유는 “오픈소스라서 싸다”가 아니에요. 기업 환경에서는 복제, 백업·복구, 고가용성, 보안 같은 운영 기능이 없으면 실제 업무 시스템에 넣기 어렵거든요.

  • 펜타시스템이 노리는 곳도 그래서 금융, 공공, 제조예요. 이쪽은 레거시 시스템과 기존 DBMS 의존도가 높아서 전환 난도가 크지만, 한 번 레퍼런스가 생기면 비슷한 프로젝트로 확장하기 쉬운 시장이에요.

  • 개발자 입장에서는 “PostgreSQL 전환”이라는 말만 보고 끝내기보다, 애플리케이션 호환성, 장애 복구 목표, 백업 정책, DW·AI 분석 연계까지 같이 봐야 해요. DBMS 교체는 데이터 저장소 하나 바꾸는 일이 아니라 서비스 운영 체계 전체를 건드리는 일이거든요.

국내 기업 입장에서는 단순히 PostgreSQL을 쓰느냐가 아니라, 상용 DBMS를 대체할 때 운영·복구·보안까지 누가 책임질 수 있느냐가 포인트다. 비용 압박이 커지는 공공·금융 쪽에서 이런 파트너십 뉴스가 계속 나오는 이유도 거기에 있음.

댓글

댓글

댓글을 불러오는 중...

backend

SIMD는 고수 전용 흑마법이 아니라, 모든 개발자가 알아야 할 반복문 최적화임

미첼 하시모토가 SIMD를 ‘복잡한 고성능 영역’으로만 볼 필요가 없다고 설명한 글이다. Ghostty의 실제 Zig 코드를 예로 들며, 큰 배열이나 문자열을 훑는 뜨거운 반복문은 벡터 너비만큼 한 번에 처리하는 5단계 패턴으로 생각할 수 있다고 풀어낸다.

backend

스타트업이 Postgres로 버티려면 알아야 할 생존 팁

Hatchet이 2년 동안 프로덕션 Postgres를 굴리며 겪은 문제를 스키마, 쿼리, 마이그레이션, 커넥션, 쿼리 플래너, autovacuum, 파티셔닝까지 한 번에 정리한 글이다. 핵심은 “인덱스만 붙이면 끝”이 아니라, 락·통계·배치·부풀어 오른 테이블까지 운영 관점에서 같이 봐야 한다는 점이다.

backend

Julia Evans가 Django로 ‘2010년식 웹사이트’를 만들며 좋았던 것들

Julia Evans가 프론트엔드 중심의 작은 앱 대신, SQL 데이터베이스와 서버 렌더링 HTML을 쓰는 Django 방식으로 웹사이트를 만들며 느낀 장점과 불편함을 정리했다. QuerySet, 템플릿 필터, 자동 마이그레이션은 생산성을 높였고, 클래스 기반 뷰와 성능 설정은 여전히 고민거리로 남았다. 특히 템플릿 캐시 설정 하나로 처리량이 초당 2-3 요청에서 약 12 요청으로 오른 대목이 실전적이다.

backend

클릭하우스가 PgBouncer 처리량을 4배로 끌어올린 방법

ClickHouse Managed Postgres 팀은 단일 스레드인 PgBouncer를 여러 프로세스로 띄우고 `so_reuseport`와 피어링(peering)을 조합해 16 vCPU 머신을 제대로 쓰게 만들었다. 동일한 AWS 환경에서 단일 프로세스는 약 8.7만 TPS 근처에서 막혔지만, 16개 프로세스 구성은 약 33.6만 TPS까지 올라갔다.

backend

SQLite 쓸 거면 STRICT 테이블을 기본값으로 보자는 주장

SQLite의 STRICT 테이블은 INTEGER 컬럼에 문자열이 들어가는 식의 타입 실수를 막아주는 기능이다. 글쓴이는 SQLite 특유의 유연한 타입 시스템보다, 실수는 빨리 터뜨리는 쪽이 실무에서 낫다고 주장한다. 다만 기존 테이블을 바로 STRICT로 바꾸기 어렵고, SQLite 3.37.0 이상에서만 쓸 수 있다는 제약도 있다.