# AliSQL - Alibaba의 오픈소스 MySQL 포크, 벡터 및 DuckDB 엔진 통합 > Clean Markdown view of GeekNews topic #26414. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=26414](https://news.hada.io/topic?id=26414) - GeekNews Markdown: [https://news.hada.io/topic/26414.md](https://news.hada.io/topic/26414.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2026-02-05T12:11:26+09:00 - Updated: 2026-02-05T12:11:26+09:00 - Original source: [github.com/alibaba](https://github.com/alibaba/AliSQL) - Points: 10 - Comments: 1 ## Summary **AliSQL**은 Alibaba가 개발한 **MySQL 포크형 데이터베이스**로, 트랜잭션 처리(OLTP)와 분석(OLAP)을 하나의 엔진에 통합합니다. 내장된 **DuckDB 컬럼형 엔진**이 대규모 분석 쿼리를 수백 배 빠르게 처리하며, **HNSW 기반 벡터 인덱스**를 통해 AI 임베딩 검색까지 지원합니다. 기존 MySQL 도구와 완전 호환되어 별도 학습 없이 사용할 수 있어, 손쉽게 **AI·분석 워크로드를 통합 관리**할 수 있습니다. ## Topic Body - Alibaba Group이 개발한 **MySQL 기반 오픈소스 브랜치**로, OLTP와 OLAP 기능을 통합한 데이터베이스 엔진 - **DuckDB 컬럼형 엔진**을 내장해 분석 쿼리에서 **최대 200배 빠른 성능**을 제공 - **HNSW 기반 벡터 검색**을 지원하며, 최대 **16,383차원**의 AI·ML 임베딩 처리를 수행 - 기존 **MySQL 도구·드라이버와 100% 호환**, 추가 학습 없이 바로 사용 가능 - Alibaba Cloud의 대규모 프로덕션 환경에서 검증된 기술로, **AI·분석 워크로드 통합형 데이터베이스**로 주목 --- ### AliSQL 개요 - **AliSQL**은 Alibaba Group이 개발한 **MySQL의 엔터프라이즈급 브랜치**로, **DuckDB OLAP 엔진**과 **네이티브 벡터 검색 기능**을 통합 - Alibaba의 프로덕션 환경에서 수백만 개의 데이터베이스를 운영하며 검증된 시스템 - MySQL의 **InnoDB OLTP 안정성**과 DuckDB의 **고속 분석 성능**을 결합 - 모든 기능은 **기존 MySQL 인터페이스**를 통해 접근 가능 ### 주요 성능 및 특징 - **DuckDB Storage Engine**은 컬럼형 OLAP 엔진으로, 자동 압축을 지원하며 분석 워크로드에 최적화 - InnoDB 대비 **최대 200배 빠른 분석 쿼리 처리 속도** 제공 - **Vector Index (VIDX)** 는 **HNSW 알고리듬** 기반의 벡터 저장 및 근사 최근접 탐색(ANN)을 지원 - **COSINE** 및 **EUCLIDEAN 거리 계산**을 지원하며, 최대 **16,383차원 벡터** 처리 가능 - **MySQL 100% 호환성**을 유지해 기존 SQL, 드라이버, 도구를 그대로 사용 가능 ### 향후 개발 로드맵 - 2025년 4분기까지 **DuckDB 엔진**, **Vector Index**, **오픈소스 공개** 완료 - 2026년 이후 계획된 기능 - **DDL 최적화**: 인스턴트 DDL, 병렬 B+트리 생성, 논블로킹 락 - **RTO 최적화**: 빠른 크래시 복구, 최소 RTO - **Replication Boost**: 병렬 Binlog Flush, Binlog in Redo, 대용량 트랜잭션 최적화 ### 사용 예시 - **DuckDB 분석 테이블 생성 및 쿼리** - DuckDB 엔진으로 테이블 생성 후 월별 매출 집계 쿼리 수행 시 InnoDB 대비 200배 빠른 처리 - **AI 응용을 위한 벡터 검색** - 768차원 벡터 컬럼을 포함한 테이블 생성 후, **HNSW 인덱스**를 통해 **코사인 거리 기반 유사도 검색** 수행 ### 오픈소스 및 커뮤니티 - **2025년 12월 오픈소스 공개**, Alibaba Cloud Database 팀이 중심적으로 개발 및 관리하며 유지보수 - **GPL-2.0 라이선스**로 배포, MySQL과 동일한 라이선스 체계 - **GitHub Issues**를 통한 버그 리포트 및 기능 제안 가능 - Alibaba Cloud RDS에서 **DuckDB 기반 분석 인스턴스**로 상용 서비스 제공 ## Comments ### Comment 50655 - Author: neo - Created: 2026-02-05T12:11:26+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46875228) - DuckDB를 **스토리지 엔진**으로 사용하는 접근이 흥미로움 기존 MySQL 연결, 툴링, 복제 구조를 그대로 유지하면서 분석 쿼리만 컬럼 기반 엔진으로 라우팅할 수 있음 별도의 분석 DB를 세우고 동기화 파이프라인을 만드는 것보다 운영적으로 훨씬 간단함 다만 InnoDB와 DuckDB 간 **데이터 일관성**을 어떻게 유지하는지가 핵심 포인트임 - MySQL의 **binlog 메커니즘**을 활용해 읽기 전용 Columnar Store(DuckDB) 노드를 구현하는 방법을 소개함 자세한 내용은 [AliSQL DuckDB 문서](https://github.com/alibaba/AliSQL/blob/master/wiki/duckdb/duckdb-en.md)에 정리되어 있음 binlog 배치 전송, 쓰기 연산 등에서 다양한 최적화를 수행했음 - 데이터 일관성 문제를 해결하기 위해 **GTID 기반 복제**를 활용함 log_bin이 꺼져 있을 때는 DuckDB 트랜잭션을 GTID 기록 전에 커밋하고, 장애 복구 시 idempotent 방식으로 재적용함 log_bin이 켜져 있을 때는 Binlog를 직접 사용하며, DuckDB에 **유효 Binlog 위치**를 기록해 실패 시 해당 위치까지 롤백함 결과적으로 replica의 gtid_executed가 primary와 일치하면 DuckDB 데이터도 일관됨 - 앞으로 10년간 SQL 데이터베이스의 진화 방향을 세 단계로 봄 1) 기존 OLTP 엔진에 **OLAP 엔진을 통합**하고 쿼리를 포워딩함 2) 두 엔진이 **공통 스토리지 레이어**를 사용하도록 재설계함 3) 결국 엔진을 완전히 병합해, 오래된 레코드를 자동으로 압축·보관하고 필요 시 원격 스토리지에서 불러오는 구조로 발전함 오래된 데이터 조회만 약간 느려질 뿐, 나머지는 완전히 통합된 쿼리 경험을 제공함 - **pg_duckdb**와 비교했을 때 어떤 차이가 있을지 궁금함 Postgres의 확장 메커니즘 덕분에 pg_duckdb는 꽤 깔끔하게 보임 - (삭제된 댓글) - 이 시스템이 **SAP HANA**처럼 트랜잭션 워크로드 데이터를 실시간으로 DuckDB에 공급하는지 궁금함 그렇다면 Kafka나 Debezium으로 데이터 웨어하우스를 동기화하던 복잡한 작업이 크게 줄어들 것임 apavlo의 의견도 들어보고 싶음 - HTAP 시대가 본격적으로 온 것 같음 이런 **하이브리드 데이터베이스**가 점점 채택되는 게 흥미로움 특히 [AliSQL DuckDB 문서](https://github.com/alibaba/AliSQL/blob/master/wiki/duckdb/duckdb-en.md)에 설명된 트랜잭션 처리 개선이 인상적임 기본 테이블과 분석 테이블 간 동기화를 빠르고 **트랜잭션 단위로** 보장하는 점이 멋짐 - 하지만 이건 진정한 HTAP이라기보다는 두 DB를 하나의 인터페이스로 **묶은 형태**에 가까움 Materialize 같은 시스템과 일관성 보장은 크게 다르지 않음 사실 이런 시도는 예전부터 있었고, MySQL/Postgres에도 OLAP 스토리지 엔진을 붙이는 사례가 많았음 - 전통적인 DB에 **임베디드 컬럼형 엔진**을 붙이는 건 생산성과 운영 단순성 면에서 큰 이점임 현재는 PG + Tiger Data 조합을 쓰고 있는데, MySQL 쪽에는 이런 대안이 없었음 이번 시도가 그 공백을 메워줄 수 있을 듯함 - MariaDB에도 이미 [ColumnStore 엔진](https://mariadb.com/docs/analytics/mariadb-columnstore/columnstore-quickstart-guides/mariadb-columnstore-guide)이 있음 최근에는 **vector storage type**도 추가되어 Alibaba의 구현과 성능 비교가 흥미로움 Postgres가 자주 언급되지만 MariaDB도 꽤 다재다능함 - ClickHouse는 MySQL 프로토콜을 **네이티브 지원**하며, MySQL 테이블을 래핑하거나 가져올 수도 있음 연결이 두 개 필요하긴 하지만 꽤 잘 작동함 - Tiger Data를 단순한 컬럼 스토어로 쓸 수 있는지 궁금함 ClickHouse처럼 빠른 count만 필요한데, 전체 동기화 과정을 거쳐야 하는 게 번거로움 TimeSeries는 특정 용도에 최적화되어 있어서 일반적인 사용에는 어려움이 있음 - TiDB도 하나의 옵션임 **Row 기반과 Column 기반 데이터**를 모두 지원하지만, MySQL 호환일 뿐 코드 기반은 다름 그래서 완전한 MySQL 확장은 아님 - MariaDB는 이미 [컬럼형 테이블](https://mariadb.com/resources/blog/see-columnar-storage-for-analytics-in-action-and-get-an-overview-of-mariadb-community-server-10-5/)을 지원하고 있음 - 이 기능을 [MySQL Operator](https://github.com/mysql/mysql-operator)와 결합해 배포하기 얼마나 쉬울지 궁금함 - 아직 시도해본 적은 없지만, 나중에 **mysql-operator와 통합**을 테스트해볼 계획임 - 얼핏 보면 PSQL의 FDW를 DuckDB와 Vector Storage로 더 **긴밀히 통합한 버전**처럼 보임 Vespa와도 유사한 느낌인데, 왜 FDW 방식 대신 MySQL 확장을 택했는지 흥미로움 - 아마도 이미 **수백만 줄의 MySQL 코드**를 사용 중이었기 때문일 것임 - 커밋 히스토리가 이상함 2022년에 2건, 2024~2026년에 몇 건뿐인데, 첫 커밋이 “First commit, Support DuckDB Engine”임 - 아마 **내부 비공개 개발**로 진행되다가 공개용으로 최소한의 커밋만 정리했을 가능성이 높음 내부 버전은 Jira 참조, 제품 정보, 중국어 주석 등으로 복잡했을 수 있음 그래서 깔끔한 공개용 git 히스토리를 새로 만든 듯함 - TiDB가 ClickHouse 대신 DuckDB를 썼다면 어땠을지 궁금함 - DuckDB가 2020년쯤 **안정화된 오픈소스**로 존재했다면, TiDB는 분명 ClickHouse 대신 DuckDB를 선택했을 것이라 확신함