SpacetimeDB 2.0 벤치마크, 인프로세스 실행을 분산 DB와 비교했다는 비판

초기 계약자로 3개월 일했는데, 내가 있던 때 구조는 CoW 트리였고 리듀서는 별도 스레드 트랜잭션에서 실행됐음. 전역 락을 잡은 채 WASM 리듀서를 돌린다는 글의 주장은 소스를 확인해야 한다고 봤는데, 나중에 AI로 소스를 확인해 보니 실제로 그렇게 동작하는 듯함. 다만 글의 해시 테이블, WAL, 데이터베이스 자격 표현은 일부러 경멸적으로 썼고 기술적으로도 거친 부분이 있음.

데이터베이스 벤치마크는 원래 어렵고, 하드웨어와 설정을 조금만 바꿔도 결과가 달라짐. QuestDB 글과 'Fair Benchmarking Considered Difficult' 논문이 이런 함정을 잘 설명함.

결국 벤치마크가 DB를 팔아주진 않는다고 봄. 신뢰성, 검증 가능한 정확성, 통합 편의성이 더 중요하고, PostgreSQL도 느린 설정이 많지만 사람들이 신뢰해서 씀.

출시 영상을 보고 구현 설명이 전혀 없어서 독점 기술인 줄 알았는데 오픈소스라 더 의아했음. 결국 뮤텍스 위에서 돌아가는 Rust판 2015년 React Flux에 가까워 보임.

발표에서 나온 수치는 인상적이지만, 그 성능은 그들이 택한 트레이드오프의 당연한 결과임. 대부분의 애플리케이션은 그 트레이드오프를 못 받아들이니 같은 수치를 기대할 수 없고, 영상들의 벤치마크도 엄밀하지 않았음.

애플리케이션 코드를 DB 서버 안에서 돌리면 개발자가 준비된 언어를 써야 하고, 무한 루프나 크래시도 믿고 맡겨야 함. 개발자가 자기 언어 선택을 포기하게 만들기 쉽지 않음.

그래서 코드를 WebAssembly로 컴파일해 VM 안에서 돌리는 거임. 언어 선택권을 주면서 반신뢰 코드로 취급하고 워치독을 둘 수 있으니, 그 부분은 말이 됨.

특수한 용도에서 n계층 구조를 깨는 건 괜찮지만, 오래된 설계 원칙을 다시 발견한 걸 과장된 홍보로 감추면 안 됨.

글에서 '부작용이나 stall 부재를 타입 시스템으로 강제할 수 없다'고 한 부분은 조금 다르게 봄. 장시간 블로킹 함수 호출은 promise 같은 방식으로 타입에 표시하기 쉬우며, HTTP를 할 수 있는 함수라는 표식이 없고 베타 API에서 블로킹 호출까지 허용한다면 전역 락 구조는 정말 큰 문제임.

글은 불을 붙이기보다 DB 개발자가 선택해야 할 트레이드오프로 논점을 되돌려서 좋았음.

예전에 MMORPG를 겨냥하던 시절을 봤는데, ECS 같은 로직을 저장 프로시저로 넣는 방식은 일부 트랜잭션 문제만 해결함. 롤백, 물리, 충돌 같은 멀티플레이어 게임의 어려운 문제에는 별 도움이 안 되고 오히려 어렵게 만들 수 있음.