본문으로 건너뛰기
피드

펜타시스템, EDB와 손잡고 엔터프라이즈 오픈소스 데이터 플랫폼 시장 공략

backend 약 5분
vote
0
댓글
북마크

펜타시스템테크놀러지가 EDB와 국내 파트너 계약을 맺고 엔터프라이즈 오픈소스 데이터 플랫폼 사업을 확대한다. 양사는 PostgreSQL 기반 대안 데이터베이스 시장, 클라우드와 인공지능 데이터 분석 환경, 고가용성 및 백업 복구 영역을 함께 공략할 계획이다.

  • 1

    펜타시스템이 EDB와 공식 파트너 계약을 체결

  • 2

    EDB PostgreSQL은 고성능, 고가용성, 복제, 백업 복구, 보안 기능을 강조

  • 3

    금융, 공공, 제조, 유통, 데이터웨어하우스, 클라우드, 인공지능 분석 환경을 주요 적용 분야로 제시

  • 4

    기존 데이터베이스 관리 시스템의 비용 증가를 대안 데이터베이스 시장 공략 포인트로 삼음

  • 펜타시스템테크놀러지가 EDB와 공식 파트너 계약을 맺음

    • EDB 본사 최고매출책임자와 최고고객책임자가 방한한 가운데 체결식이 진행됨
    • 양사는 국내 엔터프라이즈 오픈소스 데이터 플랫폼 시장 공략 로드맵을 구체화했다고 밝힘
  • 핵심 제품은 EDB PostgreSQL임

    • 고성능, 고가용성(HA), 복제, 백업과 복구, 보안 기능을 지원하는 엔터프라이즈급 데이터 플랫폼으로 소개됨
    • 클라우드, 인공지능, 빅데이터 환경까지 대응할 수 있는 차세대 데이터 인프라로 포지셔닝하고 있음
    • 특히 기존 데이터베이스 관리 시스템과의 호환성을 강점으로 내세워 전환 비용과 리스크를 줄인다는 전략임
  • 공략 대상은 꽤 명확함

    • 금융권 차세대 시스템
    • 공공기관 정보시스템
    • 제조와 유통 분야의 전사적 자원 관리 시스템
    • 데이터웨어하우스와 빅데이터 플랫폼
    • 클라우드 기반 서비스 플랫폼
    • 인공지능 데이터 분석 환경

중요

> 이 계약의 포인트는 “PostgreSQL 쓴다”가 아니라 “상용 데이터베이스 비용과 정책 변화에 지친 기업 시장을 PostgreSQL 계열로 가져오겠다”는 쪽에 가까움.

  • 펜타시스템은 이번 계약을 계기로 오픈소스 기반 엔터프라이즈 통합 데이터 플랫폼 사업을 키우려는 계획임

    • 먼저 기존 데이터베이스 관리 시스템의 정책 변화와 비용 증가에 부담을 느끼는 기업을 겨냥함
    • 비용 효율성과 안정성을 동시에 원하는 대안 데이터베이스 시장에서 레퍼런스를 확보하겠다는 전략
    • 이후 클라우드, 인공지능, 데이터웨어하우스 연계 사업까지 확장하려는 그림임
  • EDB와 펜타시스템 양쪽 모두 금융, 공공, 제조 같은 핵심 산업을 강조함

    • 펜타시스템은 국내 시스템 구축 노하우와 EDB의 글로벌 기술력을 결합하겠다고 밝힘
    • EDB 코리아는 국내 기업의 엔터프라이즈급 오픈소스 전환과 데이터 주권 확보를 지원하겠다고 언급함
    • 요즘 데이터베이스 시장에서 “비용 절감”과 “데이터 주권”이 같이 나오는 이유가 여기 있음

기술 맥락

  • 여기서 핵심 선택은 기업용 데이터베이스를 상용 제품 일변도에서 PostgreSQL 기반 플랫폼으로 옮기려는 전략이에요. 기존 데이터베이스 관리 시스템의 라이선스 정책이나 비용이 부담이 되면, 기업들은 호환성과 안정성을 챙기면서 대안을 찾게 되거든요.

  • EDB PostgreSQL이 단순 PostgreSQL이 아니라 엔터프라이즈 플랫폼으로 포장되는 이유는 운영 기능 때문이에요. 금융, 공공, 제조 환경에서는 고가용성, 복제, 백업 복구, 보안이 빠지면 실제 도입이 어렵기 때문에 오픈소스 기반이라도 기업용 기능 묶음이 필요해요.

  • 펜타시스템이 파트너로 들어가는 맥락도 중요해요. 데이터베이스 전환은 제품만 사서 끝나는 일이 아니라 기존 시스템 호환성, 마이그레이션, 장애 대응, 운영 체계까지 같이 봐야 해서 구축 경험이 있는 파트너가 필요하거든요.

  • 클라우드와 인공지능 데이터 분석 환경을 같이 언급한 건 시장 확장 포인트예요. 데이터베이스가 단순 저장소가 아니라 분석, 데이터웨어하우스, 클라우드 서비스의 기반으로 연결되기 때문에 통합 데이터 플랫폼이라는 표현을 쓰는 거예요.

국내 엔터프라이즈 시장에서 PostgreSQL 계열이 단순 오픈소스 데이터베이스가 아니라 상용 데이터베이스 대체재로 포지셔닝되는 흐름이 더 뚜렷해지고 있음. 비용 압박, 데이터 주권, 클라우드 전환이 한꺼번에 걸린 시장이라 꽤 현실적인 움직임임.

댓글

댓글

댓글을 불러오는 중...

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 이상에서만 쓸 수 있다는 제약도 있다.