‘읽기 전용’ Postgres MCP도 데이터를 바꿨다…1.1.7이 끝이 아닌 이유
기술 및 혁신 2
Supabase가 Turso를 품었다…1주일 100만 DB가 인수의 배경
Supabase는 2026년 10월 2일 공식 블로그에서 Turso 인수와 주당 100만 개가 넘는 데이터베이스 생성 규모를 발표했다. AI 에이전트가 작은 작업마다 저장 공간을 만드는 흐름에 대응하려고 Turso의 SQLite 기반 기술을 더하는 거래다. Supabase는 기존 이용자에게 당장 변화가 없고, 자사는 Postgres를, Turso는 SQLite를 계속 개발한다고 밝혔다.
같은 날 SiliconANGLE의 자금 조달 보도에 따르면 Supabase는 GIC가 주도하고 CapitalG, IronArc, SquarePeg이 참여한 투자에서 1억5000만 달러를 확보했다. 인수 가격은 공개되지 않았다. 투자금은 직원에게 유동성을 제공하고 AI 에이전트 관련 기능을 개발하는 데 쓰일 예정이어서, 조달액을 Turso의 인수 대금으로 읽어서는 안 된다.
주간 생성량이 보여준 인수의 이유
Supabase가 주목한 것은 데이터베이스에 쌓이는 데이터의 총량만이 아니다. 에이전트가 시제품, 탐색 작업, 대시보드와 애플리케이션을 만들 때마다 별도의 데이터베이스를 요청하면 작은 저장 공간을 반복해서 생성해야 한다. 개별 작업이 가볍더라도 생성 요청이 많아지면 이를 열고 유지하고 중단하는 방식이 서비스 비용을 좌우한다.
기존의 애플리케이션 개발에서는 개발자가 비교적 오래 운영할 데이터베이스를 계획하고 연결한다. 에이전트가 작업 단위로 데이터베이스를 만드는 환경에서는 생성 시점도, 사용 기간도 더 잘게 나뉜다. 이 차이가 Supabase의 주간 생성량을 단순한 성장 지표보다 인프라 설계에 관한 신호로 만든다.
Turso의 클라우드 구조는 한 서버에서 많은 데이터베이스를 관리하며 필요할 때 불러오고 사용하지 않을 때는 중단하도록 설계됐다. 작은 작업마다 전용 장비를 계속 운영하는 방식과 비교하면, 데이터베이스를 만드는 데 필요한 자원을 작업 수요에 더 가깝게 맞출 수 있다는 구상이다. SQLite를 Rust로 다시 구현한 기술도 이런 경량 작업을 대량으로 다루기 위한 기반으로 제시됐다.
투자 논리 역시 이 운영 방식과 연결된다. 데이터베이스가 자주 만들어지는 시장에서는 개별 데이터베이스의 크기보다 생성과 유지에 드는 단위 비용이 중요해질 수 있다. Supabase가 자금 조달과 Turso 인수를 함께 내놓은 것은 에이전트 수요에 맞는 제품을 개발하면서 경량 데이터베이스를 공급할 기술도 확보하려는 선택으로 읽힌다.
다만 주간 생성량만으로 유료 이용이 얼마나 늘었는지, 새 데이터베이스가 얼마나 오래 쓰이는지는 알 수 없다. 이 수치는 Supabase가 대응하려는 작업의 빈도를 보여준다. 투자 성과를 판단하려면 그 작업들이 지속적인 사용과 매출로 이어지는지도 따로 확인해야 한다.
SQLite와 Postgres의 역할은 어떻게 나뉘나
두 데이터베이스가 맡도록 제시된 작업은 규모와 운영 단계가 다르다. Turso의 SQLite 기반 환경은 에이전트가 짧은 작업을 시작하며 독립된 데이터베이스를 필요로 할 때 적합한 출발점이다. 애플리케이션이 성장해 더 큰 운영 환경이 필요해지면 Supabase의 Postgres 생태계로 이어지는 경로가 인수의 제품 방향이다.
작업마다 저장 공간을 분리하면 에이전트가 만든 상태와 데이터를 해당 작업의 범위 안에서 다룰 수 있다. 동시에 거의 사용하지 않는 데이터베이스까지 계속 활성화할 필요가 줄어들 수 있다. Turso의 기술적 가치는 작은 데이터베이스를 만드는 속도뿐 아니라, 많이 만들어진 뒤에도 이를 운영할 수 있는 구조에 있다.
- 현재의 경량 작업: Turso는 SQLite 기반 데이터베이스를 필요에 따라 생성하고, 에이전트별 작업에 배정하는 방향을 제시한다.
- 성장한 애플리케이션: Supabase는 Postgres 중심 개발을 계속한다. 더 오래 운영할 서비스가 커졌을 때 이 환경이 연결될 대상으로 제시됐다.
- 향후 통합: 두 제품을 잇는 방향은 공개됐지만, 자동 이전 도구나 통합 절차가 이미 제공된다는 발표는 없었다.
이 역할 분담은 기존 Supabase 데이터베이스를 SQLite로 바꾸거나 Turso의 데이터베이스를 즉시 Postgres로 옮긴다는 뜻이 아니다. 개발자가 실제로 두 환경을 오갈 때 필요한 데이터 이전, 인증과 관리 기능의 연결 방식은 별도의 제품 결정이다. 따라서 발표된 것은 성장 단계에 따른 경로이며, 그 경로의 구체적인 사용 경험은 후속 통합에서 드러날 부분이다.
기존 이용자는 당장 무엇이 달라지나
Turso 창업자 글로버 코스타는 Turso의 인수 발표에서 “serve upwards of a billion databases to our customers”라는 목표를 밝혔다. Turso는 기존 데이터베이스와 API, 작업 흐름의 운영을 계속하고 오픈소스 Turso Database 개발도 이어갈 방침이다. 코스타는 Supabase에서 에이전트 서비스 부문을 이끌며, 두 제품의 더 깊은 통합은 향후 몇 달에 걸쳐 추진될 예정이다.
Turso 이용자가 이미 연결해 둔 데이터베이스와 API는 발표 직후 그대로 운영된다는 설명이다. 인수가 발표됐다는 이유만으로 애플리케이션의 저장소를 옮기거나 호출 방식을 바꿔야 하는 상황은 제시되지 않았다. 이 연속성은 에이전트용 새 기능에 관심이 없는 기존 서비스에도 직접적인 정보다.
Supabase 이용자에게도 현재 쓰는 Postgres 중심 서비스가 즉시 다른 엔진으로 대체되는 변화는 없다. Turso의 기술이 합류하더라도 기존 제품의 운영과 앞으로 나올 경량 데이터베이스 기능은 구분해서 볼 필요가 있다. 새 기능의 제공 방식이 정해져야 어느 작업에서 SQLite를 선택할 수 있는지도 분명해진다.
두 회사가 제시한 방향은 작은 작업을 시작하는 단계와 애플리케이션을 오래 운영하는 단계를 연결하는 것이다. 그러나 같은 개발 경험을 제공하겠다는 목표와 데이터베이스를 실제로 이전할 수 있는 기능은 다르다. 현재 이용자에게 확인된 변화는 서비스의 지속 운영이며, 제품 간 이동 방식은 아직 구체화되지 않았다.
다음에 확인할 것은 제품 간 연결 방식
인수의 가치는 SQLite와 Postgres를 함께 보유한다는 사실보다 두 환경을 어떻게 연결하느냐에 달려 있다. 에이전트가 만든 작은 데이터베이스를 지속적인 서비스로 발전시킬 때 데이터와 운영 설정을 옮기는 절차가 필요하다. 이 절차가 제품으로 공개돼야 개발자는 경량 작업에서 운영 단계까지 이어지는 경로를 평가할 수 있다.
자금 조달 발표는 Supabase가 이 방향에 투자할 여력을 확보했다는 사실을 보여준다. 반면 인수 가격이 공개되지 않은 만큼 거래 자체의 재무적 규모나 수익성을 조달액으로 계산할 수는 없다. 현재 확인 가능한 판단 근거는 데이터베이스 생성 수요, Turso의 대량 운영 구조, 그리고 양사가 밝힌 제품 개발 방향이다.
기존 이용자에게 가장 가까운 후속 변화는 발표된 통합이 실제 기능으로 나타나는 순간이다. 그때 작은 SQLite 데이터베이스와 Postgres 애플리케이션 사이의 이동 방식, 기존 API와 작업 흐름의 유지 범위가 구체적으로 확인될 것이다.
함께 읽기:
관련 기사
뉴스레터 구독
최신 Web3, AI, 암호화폐 뉴스를 이메일로 받아보세요.
0