▲

Databricks가 서버리스 Postgres 전문 기업 Neon을 인수

 (databricks.com)
7P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • Databricks는 개발자 중심의 서버리스 Postgres를 제공하는 Neon을 인수하기로 합의
  • Neon은 스토리지와 컴퓨트 분리 구조를 통해 개발자와 AI 시스템에 최적화된 서버리스 데이터베이스 플랫폼을 제공
  • Neon의 도입으로 AI 에이전트가 생성하는 데이터베이스 비중이 30%에서 80% 이상까지 급성장함
  • Databricks와 Neon은 오픈소스 철학과 인프라 혁신 DNA를 공유함
  • 인수 이후에도 Neon 플랫폼 지원과 미래지향적 로드맵이 Databricks 자원으로 강화될 예정임

인수 발표 및 의의

  • Databricks는 개발자 중심의 서버리스 Postgres를 제공하는 Neon을 인수하기로 합의함
  • Neon 공동 창업진은 저장소-컴퓨트 완전 분리 구조로 Postgres를 설계할 수 있는 세계 소수의 전문가임
  • 이 팀은 AI 시대의 대규모 개발자 지원을 위한 서버리스 Postgres 플랫폼 제공에 집중해 왔음

Postgres 기반 혁신 미션

  • Neon 공동 창업진은 약 4년 전 구시대적인 데이터베이스 구조를 혁신하고자 뜻을 모았음
  • 핵심 목표는 아래와 같음
    • Postgres의 사실상 표준화를 예견하고, 서버리스 플랫폼 비전을 세움
    • 개발자가 몇 초 만에 새 인스턴스를 생성할 수 있도록 속도에 초점을 맞춤
    • 데이터베이스의 자동 확장 및 작업 단순화를 통해 오버·언더 프로비저닝 우려 해소를 도모함
    • 즉각 분기 및 포킹 지원으로, 데이터베이스 테스트 및 실험을 용이하게 함
  • Neon팀은 스토리지와 컴퓨트 독립 확장이 가능한 아키텍처를 만들어 위 목표를 달성함
  • 출시 이후 개발자들은 속도, 단순성, 그리고 Git 방식의 분기/포킹 기능을 호평함

AI 에이전트 시대의 변화

  • Neon의 GA 이후 AI 에이전트가 전체 DB 생성의 30% 를 차지하다가 최근에는 80% 이상으로 증가함
  • AI 에이전트가 개발자와 유사한 요구를 지니게 됨
  • Neon의 강점은 다음과 같음
    • Postgres 오픈소스 생태계: 최신 LLM이 Postgres 데이터로 학습되어, AI 에이전트가 Neon 사용에 능숙함
    • 신속성: 사람보다 빠른 속도가 요구되어, 초고속 인스턴스 프로비저닝이 필수임
    • 유연한 확장과 가격: 분리된 서버리스 구조로 인한 초저가, 다수 AI 에이전트 지원 가능함
    • 분기 및 포킹: AI 에이전트의 변화무쌍한 시도를 위한 실험/검증이 쉬워짐

Databricks와 Neon's 공유 DNA

  • 창업자 Nikita Shamgunov, Heikki Linnakangas, Stas Kelvich는 업계에서 유명한 DB 기술 전문가임
  • SingleStore, Postgres 커미터 등 각기 풍부한 경험과 독창성을 보유함
  • Databricks와 Neon 모두 인프라 계층의 첨단 기술혁신과 오픈소스 가치를 중시함
  • Apache Spark와 Postgres 모두 UC Berkeley에서 시작한 오픈소스 프로젝트라는 연결고리가 있음

향후 비전과 사용자 혜택

  • OLTP 데이터베이스 시장(약 1000억 달러 규모)은 현재 수십 년 전 제품 위주임
  • 이제 개발자와 AI 에이전트가 혁신을 주도할 시점임
  • Databricks와 Neon은 최고로 친개발자적이고 AI-에이전트 친화적인 DB 플랫폼을 목표로 함
  • 기존 Neon 고객과 파트너는 지속적인 지원 및 혁신과 로드맵의 실현을 기대할 수 있음
  • Databricks의 자원을 통해 플랫폼 강화 및 안정적 성장이 보장될 예정임
  • Data + AI Summit(샌프란시스코, 6월 9~12일)에서 향후 비전을 상세히 공유할 예정임
▲
GN⁺ 1일전  [-]
Hacker News 의견
  • 데이터 웨어하우징이 오픈소스 덕분에 빠르게 범용화되고 있다고 생각. 아는 회사가 2페타바이트 이상의 데이터를 Cloudera에 저장했었지만, 클라우드(Databricks)로 옮기지 않고 Iceberg, Trino, Superset으로 자체 분석 플랫폼을 구축해 비용을 5배 절약함. 엔터프라이즈급 k8s 오퍼레이터가 이제 충분히 좋고, 온프레미스 S3도 훌륭함. 128개 CPU와 1TB 메모리를 가진 서버 등 좋은 하드웨어와 네트워킹도 가능함. Trino뿐만 아니라 StarRocks, Clickhouse도 엔터프라이즈급 k8s 헬름 차트/오퍼레이터를 제공함. Databricks의 기업가치 600억 달러는 그들의 부담. 이 가격을 정당화해야 하고, 그들의 핵심 비즈니스 자체도 범용화되고 있음. Neon은 운영(행 지향) DB가 없던 제품군의 빈틈을 채움
    • 엔터프라이즈 입장에서는 범용화가 아님. 이전 직장은 오픈소스 소프트웨어나 10년 후 존재하지 않을 수도 있는 회사, 혹은 데이터를 우리 테넌트 이외의 장소에 두는 기업을 허용하지 않았음. “전화문의” 가격 정책을 오히려 반겼고, 데이터 플랫폼을 더 이상 신경 쓸 필요 없다는 점에서 Databricks 도입이 내 3대 성과 중 하나로 꼽힘. 신규 플랫폼 도입 시 리스크가 너무 커서 (아무 오픈소스 프로젝트) 신뢰 불가. 한 번 스타트업 솔루션을 도입한 적 있는데, MongoDB를 사용해서 운영팀이 역량이 부족하니 학습 대신 Atlas 같은 지원이 완비된 서비스를 계약함. 익숙하지 않은 Azure 방화벽 대신 아는 방화벽만 썼고, 각종 계약도 진행함. 인력 채용 줄이고, 연락 창구도 하나로 고정, 업무 효율 달성. 스타트업 라이선스는 연 5~10K달러인데, 지원은 40K달러 등 훨씬 더 많은 비용이 소모됨. 스타트업과 엔터프라이즈는 완전히 다른 세상
    • 오픈소스 StarRocks를 k8s 오퍼레이터로 사용하며 테라바이트급 데이터 고객 분석 중인데, 내 환경에서는 Databricks가 거의 필요 없다고 느낌
    • ClickHouse를 지난 몇 년간 문제 없이 잘 사용 중. 다양한 기능이 넓고, 신뢰감 있는 데이터베이스. 외부 사전(external dictionary) 기능 덕분에 Postgres, Redis 등 다른 데이터스토어와 연동이 쉬움
    • Kubernetes 오퍼레이터 기반 오픈소스 Cloudera 대안 찾는다면 stackable.tech를 5년째 개발해오고 있음. 온프레미스 오픈소스 S3 쪽은 문제. MinIO는 추천하지 않고, 이외에는 엔터프라이즈 대응 가능한 솔루션이 거의 비어있음
    • 데이터 웨어하우징은 수십 년 전부터 범용화되었음. 가격과 성능 지표의 역사가 긴데, SnowBricks 제품이 여기에 부합하지 못함. 강매냐 소프트세일이냐의 차이일 뿐
    • 왜 Databricks에서 운영 DB를 사야 하는지 모르겠음. 시장가치 유지를 위한 Databricks의 고군분투로밖에 보이지 않음
    • 만약 Databricks가 단순히 row DB가 필요했다면 자체적으로 Postgres를 구축했을 것. Neon에 이렇게 많은 돈을 쓴 건 Neon의 “독립적으로 확장 가능한 스토리지와 컴퓨트” 같은 무언가 특별한 점을 원했다는 신호
    • ETL에 무엇을 사용하는지 궁금함
  • 지난주 neon에 지원했고, 인수 소식이 터지고 오늘 아침 바로 탈락 통보를 받았음. 그 어느 때보다 행복한 탈락 경험. 이번까지 세 번 연속 인수되는 회사에 입사할 뻔한 거라, 이제는 그냥 안정함을 원함. neon 팀 축하. neon을 좋아하고 사용 중인데, 이 인수로 너무 변하지 않길 바람
    • 인수 전에 Kenna Security에 입사했는데 한 달 뒤 Cisco에 인수당했었음. 정말 끔찍한 경험이었고, Kenna 리더십이 있는 회사나 Cisco에서는 다시는 일하지 않을 것
    • 오히려 반대 경험. 인수 시기에 입사하는 것이 가장 흥미로운 때였음. 내 경우 인수 통합 경험 덕분에 종종 스카웃받았음
    • 1년차 엔지니어링 매니저 시절 인수 과정에 있었는데, 두 차례 해고를 견디며 남길 인원 선별, 팀 개편을 도왔음. 사기 저하가 심했고, 조직문화도 전혀 맞지 않았음. 심한 번아웃이 와서 몇 달 휴식, 지금은 다시 IC로 행복하게 근무 중
    • 내 예상에는 neon팀이 Databricks의 Online Tables 기술로 편입될 거라고 생각. 이게 제품적으로도 타당
    • 혹시 neon의 옛날 기업가치 시점에 입사해서 베스팅이 막 끝났다면 갑작스럽게 목돈을 받았을 텐데 어땠을지 궁금함
  • Databricks가 내가 써본 소프트웨어 중 가장 짜증나는 쓰레기. 누가 이걸 자발적으로 쓰는지 신기
    • Databricks는 2013년에 Spark가 별로였을 때 시작했고, Spark를 더 낫고 빠르게 만들었음. 제품은 여전히 Spark 중심이지만, Iceberg와 DuckDB 조합이 95%의 회사에 더 적합하다고 봄. 더 싸고, 빠르며, 다루기 편하고, 우리도 Definite에서 그런 전제 하에 데이터 플랫폼을 만들고 있음(ETL, BI, Data Lake 다 포함)
    • Databricks는 데이터를 다루는 Jira. 아무도 쓰고 싶지 않고, 별로인데 모든 사용자에게 맞추려 한투성이 기능이 오히려 하나같이 어설픔. 이제 훨씬 더 나은 대안이 많아서 Databricks를 내 선택으로 쓸 일 없음
    • 정말 동의하기 어렵다고 생각. Hadoop 출신으로서 Databricks는 유토피아. 안정적이고, 빠르며, 대규모 데이터셋도 훌륭히 확장됨. 단, 가격이 너무 비싸다는 점이 가장 큰 불만
    • 과거 Databricks 플랫폼을 좋아했었음. 2020~2021년에는 AWS, Azure, Snowflake에 비해 합리적 대안이 거의 Databricks뿐이었음. 현재는 기능 남발, 잦은 변화, 인수 등으로 중구난방이고 기능명도 엉망
    • IBM류 소프트웨어(다들 쓰니까 우리도 쓴다)가 아직도 시장이 남아 있었던 셈
    • 솔직히 Databricks는 정말 심심한 제품. 2010년대 후반을 떠올려보면, Spark-as-a-Service가 탁월했고, 기업들이 자체적으로 Spark를 안정적으로 운영하는 데 실패하던 시절. 하이퍼스케일러들도 1차 서비스는 빈약했고, Databricks 노트북 포맷의 Jupyter 호환성 이슈 등 문제도 있었지만, 온프렘 클러스터 불안정이 더 큰 골칫거리라 프리미엄을 기꺼이 감수했음. 그땐 Databricks도 훌륭한 10억 달러 비즈니스였음. 그러나 Spark-aaS만으로 유니콘이 될 수는 없었음. AWS EMR이 경쟁자로 느리게 쫓아오고 있었고, 결국 Databricks도 제품을 마구 부풀리며 성장전략에 올인, 데이터, 레이크, 하우스라는 버즈워드 세례. 2025년 현재 Databricks의 하락세는 엔쉬티피케이션의 쓴 단면. 언젠가 Larry Ellison이 인수해 시장에서 사라질지도 모름. 왜 요즘 신규 프로젝트에 Databricks를 고르는지 이해되지 않지만, 5년 넘게 쓴 엔터프라이즈들은 쉽사리 못 나옴. 앞으로 시장 점유율은 떨어지겠지만, 당분간 돈은 계속 벌 것. 이것이 업계의 순환이며, 결국은 엔트로피가 승리. 너무 미워하지는 않겠음. 꽤 괜찮은 역사를 만든 회사였음
    • Serverless를 너무 강조하지만, 한계와 숨은 함정이 너무 많아서 정말 미치도록 힘듦
    • Spark 호스팅이 정말 혁신적이었는지 의문. 그리고 Spark 자체가 90%의 기성기업 데이터처리에 너무 복잡한 거 아닌지 항상 의구심. 이 회사의 가치가 왜 이렇게 높은지 이해불가
    • 쿠키를 비활성화하면 웹사이트가 완전히 안 뜨는데, 이건 치명적인 레드 플래그. 웹사이트 하나 못 만드는 곳이 좋은 디지털 제품을 만들 거란 생각을 할 수 없음
  • Databricks는 Oracle급으로 별로. Neon도 망치거나 비싸게 만들 거라는 확신. 중장기적으로 Neon 대안을 찾을 예정
    • Databricks의 인수 합병 전략은 인수한 회사를 질식시키는 구조. Iceberg, DuckDB 등 오픈소스의 대격변에 고전하는 상황. 인수를 통한 혁신을 시도하고 있지만, 기업문화 탓에 인수기업들이 무너짐. 빅데이터 업계 출신(전 Snowflake)이라 편향일 수 있으나, 오픈소스가 점점 힘을 얻는 추세가 확실히 보임. 이 변화가 어떻게 될지 매우 궁금
  • 기사 원문 인용: “Neon이 GA로 전환된 작년 30%가 AI 에이전트가 만든 데이터베이스였는데, 최근 다시 보니 이 비율이 80%를 넘었음. AI가 사람보다 4배 더 많은 DB를 만들었다는 뜻.” 이건 여러 알람이 울리는 데이터. Databricks가 Postgres를 AI 솔루션으로 포장하려는 것 같음. 요즘 세상 참 신기
    • 그중 활성 사용 중인 DB가 몇 개인지 궁금
  • Neon 팀에게 축하. 만든 것 매우 맘에 듦. 그런데 Databricks와의 연관이나 시너지를 솔직히 못 느끼겠고, Neon이 별도 제품으로 계속 남아있길 바람. 안 그러면 시장에서 확실한 Postgres 제공자를 하나 잃게 됨
    • Azure 의존이 높아서 당장 사라지진 않을 것 같음. Databricks가 분석 DB뿐 아니라 트랜잭션 DB 영역까지 확장하려는 움직임
    • FAQ에서는 독립적으로 운영된다고 하지만, 실제론 결과가 뻔하다고 생각
  • Neon 팀이 HN에 올렸던 첫 글을 기억함. 그때도 멋진 아이디어라 코멘트했었고, 아직 직접 쓸 필요는 없었지만 언젠가 쓸 거라 생각. 그런데 이런 인수 뉴스를 보면 회의감이 듦. 이제 사용자보다 소유주 입장에 집중하게 될 것 같아 우려. 원론적으로 입장이 같아야겠지만 실제로 맞아떨어지는 경우는 드물었음
    • Neon 첫 포스트를 나 역시 기억. 저장소-컴퓨트 분리가 신선했고, Pageserver에 대해 질문도 했었음. 이후 2년 만에 나 역시 Turso database에서 유사한 분리 스토리지 작업을 하게 됨. Neon 팀에게 다시 축하 보냄
    • 인수 소식에 나 역시 멈칫하게 됨. 인공지능 사용자를 우선하는 것이 개발자와 이익이 일치한다고 믿기 어려움. PostgreSQL 핵심과 관련된 기술은 오픈소스 커뮤니티의 도움이 되길 바람
  • Neon 팀에 축하를 전함. 훌륭한 제품. 물론 VC 지원을 받으면 이런 결과는 불가피하다고 봄. Nikita 등이 Databricks에 동화되지 않고 강인하길 바람
  • 이것은 정말 흥미로운 발전. OLTP와 OLAP의 수렴 방식이 옳은 방향이라고 생각. OP와 함께 SingleStore에서 HTAP 시스템을 만들었던 경험이 있음. OLTP와 OLAP을 단일 데이터베이스(한 번의 복사로 양쪽 지원)로 하려고 했으나 HTAP은 잘 되지 않았음. OLTP는 Postgres로, OLAP은 데이터 웨어하우스/레이크로 따로, 그리고 그 사이의 복제가 효율적으로 설계되어야 함. 동기화 복제는 난이도가 높음. 컬럼나형 저장소가 OLTP 쓰기를 잘 못 받음. Databricks와 Neon이 “최신 Postgres 테이블을 Unity Catalog에서 직접 활용”하는 시나리오를 실현할 수 있을지 기대됨(Debezium, Kafka, Flink, Iceberg 거치지 않고, Spark가 Iceberg 상태 유지 관리)
    • OP란 Neon 창업자인 Nikita Shamgunov(과거 MemSQL/SingleStore 창업자)를 말하는 거냐는 질문
  • Neon 팀 축하. 솔직히 다소 아쉬움. CockroachDB가 비즈니스 소스로 전환하면서 생긴 빈자리를 Neon이 채워줄 거라 기대했었음. Databricks에 인수되면서 Neon이 덜 매력적으로 느껴짐. 대기업이 중요한 인프라를 책임질 거라 믿기 힘듦. “현대적” Postgresql에 대한 수요는 충분하지만, 직접 대안들 중 어떤 것도 뿌리에서 멀어지고 있음(가격, 호환성, 소스 공개 여부 등에서). Postgres 대안을 찾을 때 아래를 비교함
    (1) AWS RDS는 이미 사용 중이었으나 비싸고, 확장성과 운영상 문제 있음
    (2) AWS Aurora는 운영 문제 일부를 해결하지만 다른 단점 동반, 다른 wire 호환 Postgres 대안과 비슷한 한계
    (3) CockroachDB는 매우 흥미로웠으나, 툴 체인 호환과 깊은 호환성 이슈, 당시엔 오픈소스였음
    (4) Neon은 아직 미성숙해보여 도입하지 않았지만 흥미롭고 많은 문제를 해결할 수 있을 것 같았음
    (5) Yugabyte는 역시 흥미로운 기술이나 다양한 호환성 문제가 있었음
    직접 Postgres 호스팅도 고민했지만, 쿠버네티스와 postgres의 자체 운영 부담이 커 고민했음. 자체 복제나 운영 기능은 아직 덜 성숙했고, 업그레이드 시 전체 데이터 언로드/리로드가 매우 번거로웠음. 확장이나 자동화가 쉽지 않았음
    • Yugabyte의 쿼리 엔진이 Postgres 기반 같다며 비교한 것에 대해, Neon 자체는 Postgres임을 상기시킴
    • “가장 좋은 현대적 Postgres 대안은 (5년 뒤의) Postgres 그 자체”라는 자신의 단기 경험을 공유
    • 다른 wire 호환 Postgresql 대안들의 “동일한 단점”이 무엇인지 더 듣고 싶음
답변달기