본문으로 건너뛰기

3.1 회사 관계와 기술 계보

제품 비교표를 만들기 전에 이름이 가리키는 대상을 확인해야 합니다. Neon과 Lakebase를 같은 제품의 옛 이름과 새 이름으로 적으면 혼동이 생깁니다. TimescaleDB를 Tiger Data로 대체해도 회사의 변화와 엔진의 변화가 섞입니다. 그러면 출시 연혁뿐 아니라 호환성, 지원 범위, 자체 운영 가능성까지 잘못 연결하게 됩니다. 이 장은 회사, 엔진, 관리형 서비스를 구분합니다. 각 관계에는 근거가 설명하는 범위를 함께 적습니다.

관계의 기준일은 2026-09-30입니다. 인수 발표와 거래 완료는 다른 사건으로 기록합니다. 공개 preview와 GA도 따로 적습니다. 회사가 같은 기술을 활용하더라도 서비스의 API, 복제 범위, 과금 방식은 별도로 확인합니다. 뒤의 기능 비교에서는 여기서 구분한 이름에 생성 모드와 제공 단계를 추가합니다.

관계도의 표기 기준​

아래 그림에서 굵은 화살표는 인수, 점선은 회사명 변경을 표시합니다. 실선은 기술 기반이나 서비스 제공 관계를 표시합니다. 실선의 의미는 라벨로 다시 구분합니다. 특히 MySQL에서 Vitess로 이어지는 선은 엔진 소스의 fork를 의미하지 않습니다. SQLite에서 libSQL로 이어지는 파생 관계에는 별도 라벨을 사용합니다. SQLite를 Rust로 재작성한 Turso Database의 관계도 다른 라벨로 구분합니다.

이 그림은 소유권과 기술 사용 관계를 함께 읽기 위한 요약입니다. 코드 전체의 상속 관계나 회사의 법적 조직도를 재현하지 않습니다. 예를 들어 Noms와 Dolt를 연결하는 근거는 초기 저장 구조의 계보입니다. 현재 두 엔진의 저장 형식이 동일하거나 상호 교환되는지는 별도 검증이 필요합니다. 제품명을 식별하는 단계와 실제 호환성을 검증하는 단계를 분리합니다.

문서를 작성할 때는 사건의 주체와 대상을 한 문장에 적는 편이 정확합니다. 회사가 다른 회사를 인수한 사건은 소유 관계로 기록합니다. 특정 엔진으로 서비스를 제공한 사실은 구현 관계로 기록합니다. 명칭이 바뀐 경우에는 회사명인지 제품명인지 함께 적습니다. 이렇게 작성하면 과거 발표의 제품명과 현재 기능 문서의 이름이 달라도 중복 집계를 피할 수 있습니다.

Neon과 Databricks Lakebase​

Neon은 2021년에 시작했고 2022년 6월 technical preview를 거쳤습니다. 같은 해 12월에는 open access와 database branching을 제공했습니다. 2024년 4월에는 GA를 발표했습니다. 이 연혁은 창업, 초기 공개, branch 기능 제공, 정식 제공을 구분합니다. 2026년 9월의 backend GA는 DB 외 구성 요소에 관한 발표입니다. 이를 Neon 데이터베이스 자체의 첫 GA로 기록하지 않습니다.

Databricks의 Neon 인수 발표는 2025년 5월 14일입니다. 당시 창업자 글은 거래 종결 후 합류할 예정이라고 설명합니다. 기준일의 회사 소개에서는 Databricks 소속임을 확인합니다. 다만 정확한 법적 거래 종결일은 확보된 근거에서 미확인입니다. 따라서 관계도에는 인수 발표 월을 쓰고, 완료 날짜는 미확인으로 남깁니다. 이는 회사 소속이 불명확하다는 뜻과 구별합니다.

Lakebase의 공개 preview 발표는 2025년 6월 11일입니다. Databricks는 Neon 기술을 기반으로 한 제품으로 소개했습니다. 이 발표로 확인하는 범위는 기술 기반과 제품 제공 관계입니다. Neon의 모든 기능을 Lakebase에서 같은 방식으로 제공한다는 근거로 사용하지 않습니다. 예를 들어 어느 서비스에서 branch를 생성했는지 비교 기록에 남겨야 합니다. 어느 API와 문서 버전을 따르는지도 함께 적어야 합니다.

Neon의 데이터 포함 branch와 저장 구조는 다음 장에서 비교에 필요한 정도로 요약합니다. Compute, Safekeeper, Pageserver의 역할은 Neon 아키텍처에 연결합니다. timeline 읽기 경로도 해당 문서에서 설명합니다. 이 장에서 저장 계층의 구현까지 설명하면 인수 사실과 기술 동작의 근거가 섞입니다. 따라서 문서별 설명 범위를 나누어 유지합니다.

Delphix와 Tiger Data의 회사 변화​

Delphix는 2008년에 창업했습니다. 2010년 9월에는 Delphix Server를 공개 출시했습니다. 최초 발표는 데이터베이스 가상화와 셀프서비스 사본 제공을 설명합니다. 2015년 5월에는 Axis Technology Software를 인수해 마스킹 역량을 결합했습니다. 2024년 3월 25일에는 Perforce가 Delphix 인수 완료를 발표했습니다. 창업, 제품 공개, 기술 역량 결합, 소유권 변경을 각각 다른 사건으로 읽습니다.

마스킹 기업 인수 사실은 인수 당시의 역량 결합으로 기록합니다. 이를 첫 제품의 기능으로 소급하지 않습니다. 같은 이유로 2010년의 셀프서비스 설명은 당시 제공 범위로 한정합니다. 후대의 특정 Self-Service 제품명이나 현재의 모든 자동화 기능과는 구분합니다. 현재 VDB의 복제 범위와 정리 규칙은 현행 기능 문서로 확인해야 합니다. 회사 연혁은 해당 기능이 어느 제품 세대에서 논의되는지 찾는 데 사용합니다.

Timescale은 2025년 6월 17일 회사명을 Tiger Data로 변경했습니다. 이는 기업 인수와 구별되는 명칭 변경입니다. TimescaleDB 확장과 Tiger Cloud 서비스는 별도 이름으로 남겨야 합니다. 회사명 변경만으로 TimescaleDB 엔진의 폐지나 모든 서비스의 저장 계층 변경을 뜻하지는 않습니다.

이 구분은 fork 기능 비교에도 직접 연결됩니다. Tiger Cloud의 Fluid Storage 기반 CoW와 backup 복원 경로는 같은 서비스 이름 아래에 존재합니다. 따라서 회사의 새 이름을 확인한 뒤에도 대상 서비스의 fork 모드를 다시 확인해야 합니다. PostgreSQL 분기 제품에서는 두 경로를 별도 행으로 비교합니다. 여기서는 명칭 변경이 기능 통합의 근거가 되지 않는다는 한계를 유지합니다.

Noms와 Dolt 및 Turso의 엔진 계보​

Noms의 첫 commit은 2015년 6월이며 공개는 2016년 8월입니다. Dolt 개발사의 전신 Liquidata는 2018년 2월에 설립되었습니다. Dolt는 2019년 8월 6일 공개 출시되었습니다. 공식 연혁에 따르면 Dolt는 Noms를 기반으로 출발했습니다. 이후 저장 구조와 Git 형태의 인터페이스를 발전시킨 과정을 설명합니다. Noms 개발사 Attic Labs의 Salesforce 인수는 Dolt 인수와 구분해 기록합니다.

Dolt 1.0의 출시 시점은 2023년 5월입니다. PostgreSQL 호환 계열인 Doltgres 1.0은 2026년 8월 6일에 발표되었습니다. 두 제품의 버전 숫자가 같더라도 각각 별도의 출시 사건으로 기록합니다. Doltgres의 PostgreSQL 호환성은 PostgreSQL 원본 엔진과의 동일성을 뜻하지 않습니다. 호환성이 필요한 조직은 사용하는 SQL과 extension의 범위를 별도로 확인해야 합니다.

기존 Dolt와 Doltgres 실습에는 branch와 diff, 머지의 실행 예가 있습니다. 이 Part에서는 명령 반복을 생략하고 제품 계보와 현재 제공 상태를 정리합니다. 특히 이전 자료의 beta 표현이나 특정 성능 배수를 현재 상태로 옮기지 않습니다. 버전 관리 기능과 SQL 실행 특성은 개발 환경과 데이터 버전 제품에서 나누어 설명합니다.

SQLite와 Turso의 관계는 두 갈래입니다. 공식 저장소는 libSQL을 SQLite의 fork로 설명합니다. 새 Turso Database는 SQLite를 Rust로 재작성하는 별도 엔진 계열입니다. libSQL의 단순한 이름 변경으로 표시하면 기존 서비스와 새 엔진의 기능 상태를 혼동하게 됩니다. 이 파생 관계는 사실 대장의 세대 구분에 공식 libSQL 저장소의 설명을 보완한 것입니다.

기존 libSQL 기반 Turso Cloud는 2023년 9월 branching과 PITR를 발표했습니다. 새 Rust 엔진 기반 Cloud는 2026년 4월 private beta를 발표했습니다. 이 발표에는 branching과 PITR가 포함되었습니다. 따라서 기존 발표는 기존 엔진의 연혁으로 기록합니다. 새 엔진의 기능 유무는 새 엔진에 관한 발표를 기준으로 판단합니다. 비교 기록에는 엔진 세대, Cloud의 제공 단계, 확인한 문서 날짜를 함께 적습니다.

MySQL과 Vitess 및 PlanetScale의 제품 구분​

MySQL과 Vitess의 연결은 SQLite와 libSQL의 소스 파생 관계와 다릅니다. 공식 설명에 따르면 Vitess는 MySQL을 기반으로 구성하는 분산 데이터베이스 시스템입니다. sharding과 인스턴스 운영 관리 기능을 제공합니다. PlanetScale은 Vitess를 서비스의 기반으로 사용합니다. 이 관계는 엔진 fork, 회사 인수, 브랜드 변경 중 하나로 요약하기 어렵습니다. 따라서 그림에 클러스터 관리와 서비스 기반이라는 라벨을 붙였습니다.

PlanetScale의 개발자 플랫폼 발표는 2021년 5월입니다. 같은 달 branching과 deploy request의 공식 설명이 나왔습니다. 이 기능 계보는 MySQL/Vitess 제품에 해당합니다. 이후 PlanetScale Postgres는 2025년 7월 private preview를 거쳤습니다. 9월에는 GA를 거쳤습니다. 회사 이름이 같다는 이유로 Vitess의 deploy request를 Postgres의 기능으로 옮겨 쓰지 않습니다.

실제 비교에서는 서비스명을 한 칸 더 구체화합니다. PlanetScale Vitess의 schema 변경 흐름은 별도 행으로 비교합니다. PlanetScale Postgres의 빈 branch 및 backup 복원 branch도 각각 다른 행이 필요합니다. PostgreSQL이라는 엔진 이름만 보고 데이터 포함 여부를 추정하는 것도 피합니다. 회사 관계는 문서를 찾는 출발점으로 사용합니다. 생성 모드의 문서는 실제로 준비되는 환경을 판정하는 근거로 사용합니다.

새 자료를 반영할 때는 기존 연혁의 날짜를 유지하고 후속 사건을 추가합니다. 예를 들어 preview의 존재와 GA의 확인 여부를 별도로 기록합니다. 이전 자료에 없는 기능은 후속 기능 문서의 근거를 붙입니다. 다음 장부터는 이 식별 방법을 유지하면서 데이터 준비, 운영 책임, 원본 의존성을 비교합니다.

참고​