Supabase가 Turso를 인수, 주당 100만 개 DB를 찍어내는 에이전트 인프라로 통합
- Supabase가 SQLite를 Rust로 다시 쓴 Turso를 인수함. Supabase는 이미 주당 100만 개 이상의 데이터베이스를 만들고 있고, Turso는 서버 한 대로 수백만 개 DB를 관리하며 필요할 때 로드하고 놀 때는 재우는 구조를 갖춤
- 기존 사용자가 체감할 변화는 없음. Supabase는 Postgres, Turso는 SQLite 작업을 그대로 이어가고, 워크로드가 커지면 Turso에서 Supabase 생태계로 넘어가는 경로를 만듦
- Turso의 Glauber Costa와 Pekka Enberg가 팀원들과 Supabase에 합류하고 Glauber가 에이전트 인프라 작업을 맡음. Turso Cloud는 Superhuman, Sauna.ai, CTO.new, Mastra 같은 고객사 자체 클라우드에서도 돌아감
- 목표는 에이전트가 파일 만들듯 데이터베이스를 만들되 비용을 신경 쓰지 않는 그림임. 작은 워크로드는 SQLite, 규모가 커지면 Postgres로 프로토타입부터 운영까지 같은 개발자 경험을 유지하려 함
Hacker News opinions
Supabase 팬이긴 한데 이 조합은 예상 못 했다. 어떻게 굴러갈지 궁금함
난 작은 프로젝트에 Turso 쓰는데 잘 돌아감. 이번 일로 바뀌는 게 없으면 좋겠음
Turso 프로젝트 운명이 회사 성공에 묶여 있는 게 부담돼서 몇 번은 그냥 sqlite 골랐음. 이제는 Turso로 갈 듯
?? 바이브 코딩으로 만든 걸 검증된 sqlite보다 선호한다고?
Turso 고객인데 이런 건 원하지 않음
이메일이나 디스코드로 연락 달라. Supabase의 일원이 된 것 매우 기대하고 있음
Rust 비동기 프로젝트에 Turso 쓰는데 성능 좋음. 앞으로 나올 게 기대됨
이슈 고치는 데 리소스를 더 넣어줬으면 함. ClickBench에 추가하려는 시도가 여러 번 있었는데 매번 새 버그가 나왔고, SQLite보다 몇 배 느리면 안 되는 거 아님
7월 22일엔 데이터 로딩이 일주일째 진행 중인데 속도가 초당 4KB로 떨어져서 몇 년 걸릴 판이었고, 8월 2일엔 1% 정도만 로드됐고, 1년 뒤엔 아예 못 읽었음. fsync를 빼도 안 됐음. LLM이 쓴 코드라지만 실행이 이 정도로 나쁠 수 있나? 데이터셋도 제대로 못 읽는 제품을 Supabase가 왜 사는지 모르겠음
이건 좀 불편함. 작은 앱에서는 SQLite와 Turso 재작성판이 이기길 바랐는데. 코어가 오픈소스라 다행이지만 계속 그럴까? Turso 호스팅 수익이 부족했나 보다
MIT로 무료 공개된 소프트웨어인데 누가 Turso에 돈을 냄? 방금 스스로 답한 거임
수익 문제라기보다 AI가 자기들을 대체하기 전에 창업자들이 엑시트하려는 것 같음. 요즘 기술 업계 분위기가 그럼
우리는 잘 되고 있었음. 전략적 인수이고 Supabase가 Turso를 쓰려는 그림에 반했음. 자세한 건 곧 나옴
오픈소스로는 밥값 못 벌지. 여기 사람들도 오픈소스에 돈 안 냄
우리 클라우드는 밥값 잘 벌고 있음
Glauber 축하한다!
고맙다!
이건 드물게 supabase, turso, 고객 셋 다 이기는 케이스 같음
왜 세계에서 가장 잘 짜이고 테스트된 소프트웨어를 다시 쓰나?
그래야 분야가 앞으로 나감. 좋은 것으로는 충분하지 않음