Databricks Data + AI Summit 2026의 몇 가지 메모: 데이터 계층이 다시 중요해지는 이유
올해 Databricks Data + AI Summit 이후, 저는 어떤 단일 발표보다도 한동안 제 머릿속에 자리 잡고 있던 질문에 대해 더 많이 생각하게 되었습니다:
AI가 실제로 프로덕션으로 들어가면, 데이터 계층은 무엇이 되는가?
제 현재 답은 단순하지만, 그 함의는 그렇지 않습니다: 이번 사이클에서 데이터 계층은 AI 스택 중 가장 느리게 재평가된 부분입니다. 그리고 이제 그것이 바뀌기 시작하고 있습니다.
데이터: 시장이 아직 가격에 반영하지 않은 AI 스택의 일부
알고리즘은 공개적으로 재평가되었습니다. 모델은 빠르게 개선되고, 업계는 거의 매주 그 진전을 확인할 수 있습니다. 컴퓨트는 NVIDIA, 클라우드 제공업체들, 그리고 자본시장에 의해 재평가되었습니다. 모두가 GPU가 중요하다는 것을 이해합니다.
데이터는 더 느리게 움직였습니다. 덜 중요해서가 아닙니다. 그 반대가 사실입니다. 데이터가 재평가되는 데 시간이 걸리는 이유는 이야기하기 어렵고, 고치기는 더 어렵기 때문입니다. 엔터프라이즈 데이터는 지저분하고, 흩어져 있으며, 중복되고, 오래되었고, 아무도 완전히 이해하지 못하는 권한으로 가득합니다. 비즈니스 의미 체계는 시스템 전반에서 깔끔하게 맞아떨어지지 않습니다. 사람들이 “실시간”이라고 부르는 것은 종종 여전히 어젯밤 어느 시점에 실행된 예약 작업입니다.
그 작업은 고통스럽습니다. 또한 그다지 화려하지도 않습니다. 하지만 AI가 데모에서 프로덕션으로 이동하면, 그 고통은 숨길 수 없게 됩니다.
OpenAI와 Anthropic에 있는 사람들을 포함해 모델을 구축하고 훈련하는 사람들과의 대화에서, 논의는 종종 같은 지점으로 돌아옵니다. 모델은 수렴하고 있습니다. 컴퓨트는 적어도 충분한 돈이 있다면 살 수 있습니다. 방어 가능한 계층은 점점 더 데이터가 되고 있습니다: 그 품질, 신선도, 그 주변의 권한, 그리고 그것을 유용한 컨텍스트로 전환할 수 있는 속도입니다.
이것은 애플리케이션 계층만의 문제가 아닙니다. 모델 회사 내부에서도 모델 품질은 여전히 데이터 파이프라인에 크게 의존합니다. 학습 실행은 첫 번째 진지한 실험이 시작되기 전에 며칠간의 준비가 필요할 수 있습니다. 상류 필드가 더럽거나, 배치에 잘못된 라벨이 붙었거나, 필터링 규칙이 잘못되었다면, 손실 곡선이 드리프트했다는 것을 누군가 알아차리기도 전에 며칠 치의 컴퓨트와 기다림이 사라질 수 있습니다.
AI 에이전트는 데이터 문제를 숨길 수 없게 만든다
에이전트는 같은 문제를 더 운영적인 형태로 드러냅니다.
AI 에이전트가 프로덕션에서 실패할 때, 첫 번째 원인은 종종 모델이 무능해서가 아닙니다. 모델이 잘못된 컨텍스트에 기반해 행동하고 있기 때문입니다: 접근할 수 없는 레코드, 6시간 전에 만료된 문서, 밤사이 조용히 변경된 데이터 소스, 또는 충분히 자주 사용하기에는 비용이 너무 비싼 검색 경로입니다. 저는 최근 한 유능한 팀이 오래된 컨텍스트 파이프라인 때문에 거의 일주일을 허비하는 것을 보았습니다. 에이전트는 자신 있게 어제의 질문에 답하고 있었습니다. 모델이 멍청한 것이 아니었습니다. 컨텍스트가 잘못되었고, 시스템에는 오류가 루프의 어디에서 들어왔는지 깔끔하게 증명할 방법이 없었습니다.
그것이 중요한 실패 모드입니다. 다음 인프라 병목은 단순히 더 나은 추론이 아닙니다. 모델이나 에이전트가 결정을 내리는 순간의 신선하고, 신뢰할 수 있으며, 저렴하고, 감사 가능한 컨텍스트입니다.
그래서 저는 데이터 계층이 AI 스택에서 다음으로 재평가될 부분이라고 생각합니다.
Databricks는 올바른 문제를 겨냥하고 있다
저는 스스로를 “AI 데이터 플랫폼”이라고 부르는 많은 제품에 회의적입니다. 너무 자주 시스템보다 스토리가 먼저 도착합니다.
Databricks는 충분히 달라서 진지하게 주목할 가치가 있다고 생각합니다. Summit에서 두 가지가 제 눈에 띄었습니다.
첫 번째는 여전히 엔지니어링 문화입니다. Databricks의 규모라면 회사가 순전히 영업 중심으로 변하는 것은 쉬운 일일 것입니다. 그럼에도 창업자들은 여전히 무대에서 실행 엔진, 트랜잭션, 실시간 분석, 그리고 제품 아래의 파이프에 대해 이야기하고 있습니다. 저는 그것을 존중합니다. 회사의 핵심에 여전히 제품과 엔지니어링 직관이 있는지는 느낄 수 있습니다. 그것은 키노트에 나타나기 훨씬 전, 작은 아키텍처 결정들에서 드러납니다.
두 번째는 고객 기반입니다. Summit에서 제가 대화한 사용자들은 AI를 데모 레이어로 이야기하고 있지 않았습니다. 그들은 AI를 프로덕션 시스템에 밀어 넣으려 하고 있었고, 그들이 설명한 문제들은 훨씬 더 구체적이었습니다. 에이전트는 비즈니스 상태를 읽고 쓸 수 있어야 하고, 실시간 분석은 데이터를 이동시키는 비용을 계속 지불할 수 없으며, 파이프라인은 더 자율적으로 되어야 하고, 에이전트 행동에는 사후뿐 아니라 런타임에서의 거버넌스가 필요합니다.
그렇기 때문에 Lakebase, Lakehouse//RT, 데이터 에이전트, AI 거버넌스와 같은 발표가 중요합니다. 이름보다 중요한 것은 방향입니다. 트랜잭션을 레이크에 더 가깝게 두십시오. 실시간 분석을 동일한 데이터 기반 쪽으로 다시 끌어오십시오. 파이프라인의 더 많은 부분을 자동화하십시오. 거버넌스를 “누가 이 데이터셋을 볼 수 있는가”에서 “이 에이전트가 이 특정 단계에서 무엇을 하도록 허용되는가”로 확장하십시오.
저는 그것을 잘못된 방향 전환으로 보지 않습니다. 저는 그것을 우리 중 많은 이들이 같은 미래를 서로 다른 각도에서 바라보고 있다는 증거로 봅니다.
데이터베이스는 확장되고 있습니다. 더 이상 데이터를 저장하고 쿼리하는 장소에 그치지 않습니다. 사실, 상태, 의미론, 거버넌스, 행동의 기반이 되고 있습니다.
지도는 좋습니다. 하지만 아직 완성되지 않았습니다.
Databricks는 방향이 맞습니다. 그렇다고 해서 아키텍처가 최종 형태에 도달했다는 뜻은 아닙니다.
사진: The Known Data Realm · Databricks Data + AI Summit 2026
저는 지도가 아직 불완전한 세 가지 영역을 봅니다.
Lakebase 자체.
Postgres로 시작하는 것은 영리한 진입점입니다. 개발자들은 그것을 알고 있습니다. 생태계는 거대합니다. 호환성은 도입 마찰을 낮춥니다. 그것은 중요합니다.
하지만 사람들을 문 안으로 들어오게 하는 아키텍처가 항상 최종 워크로드에서 승리하는 아키텍처는 아닙니다.
AI 시대의 운영 시스템에는 트랜잭션, 메모리, 벡터, 멀티모달 데이터, 트레이스, 브랜칭, 롤백, 그리고 매우 세밀한 테넌트 격리가 필요합니다. 전통적인 관계형 코어는 확장 기능과 주변 서비스를 통해 이들 중 일부를 노출할 수 있지만, 그렇다고 해서 그것들이 네이티브가 되는 것은 아닙니다. 클래식 Postgres는 클라우드 네이티브 분산 규모를 위해 설계된 것도 아니고, 수명이 짧은 데이터베이스를 만들고, 상태를 포크하고, 메모리에 쓰고, 트레이스를 생성한 뒤 사라지는 에이전트를 위해 설계된 것도 아닙니다.
Postgres를 객체 스토리지에 더 가깝게 옮긴다고 해서 이러한 질문들이 사라지는 것은 아닙니다. 객체 스토리지는 저렴하고 안정적이지만, 기본적으로 저지연은 아닙니다. 빠르게 느껴지게 하려면 공격적이면서도 정확한 캐시 레이어가 필요합니다. 실제 트랜잭션 부하에서 안정적으로 유지되는 캐시는 데이터베이스에서 가장 어려운 시스템 문제 중 하나입니다. 그래서 Lakebase에 대한 저의 솔직한 질문은 데모가 인상적인지 여부가 아닙니다. 그 시스템이 그 캐시를 새벽 3시에 사람들을 깨우는 존재로 만들지 않으면서 프로덕션 규모에서 실제 OLTP 워크로드를 감당할 수 있는지입니다.
멀티모달 데이터.
Databricks는 OLTP, 웨어하우징, 실시간 분석, 데이터 과학, 거버넌스 전반에 걸쳐 강력한 지도를 그렸습니다. 하지만 AI 애플리케이션은 점점 더 텍스트, 이미지, 오디오, 비디오, 임베딩, 행동 로그, 에이전트 트레이스를 소비합니다. 그것들은 테이블 옆에 놓인 객체에 그치지 않습니다. 그것들은 에이전트가 검색하고, 추론하고, 변환하고, 다시 써 넣는 데이터입니다.
멀티모달 데이터가 핵심 지도 바깥에 남아 있다면, 가장 중요한 AI 데이터 자산은 여전히 주변부에 살게 됩니다.
기본 사용자.
제품 표면의 많은 부분은 여전히 인간 사용자를 가정합니다. 대시보드, 자연어 BI, Excel 스타일 워크플로, 분석가 대상 경험이 그렇습니다. 그것들은 가치가 있습니다. 하지만 에이전트는 데이터베이스를 다르게 사용합니다.
에이전트는 하루에 한 번 대시보드를 열지 않습니다. 루프 안에서 실행됩니다. 컨텍스트를 검색하고, 결정을 내리고, 도구를 호출하고, 상태를 쓰고, 정책을 확인하고, 반복합니다. 모든 단계는 감사가 필요할 수 있습니다. 모든 검색은 다음 행동에 영향을 줄 수 있습니다. 모든 쓰기는 롤백이 필요할 수 있습니다. 모든 권한 확인은 런타임에 이루어져야 할 수 있습니다.
그것은 다른 데이터베이스 워크로드입니다.
사진: Unity AI Gateway · 거버넌스 —— Databricks Data + AI Summit 2026
데이터베이스 사용자가 에이전트일 때
수십 년 동안 데이터베이스는 대체로 하나의 질문에 집중할 수 있었다: 이 쿼리 를 어떻게 정확하고 빠르게 실행할 것인가.
에이전트 시대에는 질문이 더 넓어진다:
에이전트는 결정을 내리는 순간에 어떻게 가장 최신이고, 가장 신뢰할 수 있으며, 비용이 가장 낮고, 가장 감사 가능한 컨텍스트를 얻는가?
이것은 단순한 쿼리 최적화 문제가 아니다. 저장, 인덱싱, 거버넌스, 리니지, 리플레이, 비용 통제, 런타임 정책 집행 전반에 걸친 시스템 문제다.
바로 여기서 이 범주는 변화하기 시작한다. 데이터 시스템은 더 이상 지능 시스템에만 머물 수 없다: 질문을 하면 답을 반환하는 방식이다. 그것은 AI를 위한 운영체제에 더 가까워져야 한다: 에이전트가 컨텍스트를 읽고, 결정을 내리고, 도구를 호출하고, 상태를 기록하며, 인간과 다른 시스템이 검사할 수 있는 흔적을 남기는 장소다.
감사 가능성은 사후에 덧붙일 수 없다. 에이전트가 잘못된 답을 내거나, 잘못된 행동을 하거나, 너무 많은 돈을 쓰면, 첫 번째 질문은 다음과 같을 것이다: 그 순간 그것이 정확히 무엇을 보았는가?
이에 답하려면 시스템은 어떤 문서가 검색되었는지, 어떤 벡터가 매칭되었는지, 어떤 메타데이터 필터가 적용되었는지, 어떤 리랭커가 순서를 바꾸었는지, 어떤 도구가 호출되었는지, 어떤 정책이 집행되었는지, 어떤 상태가 다시 기록되었는지를 알아야 한다. 디버깅과 거버넌스는 같은 워크플로가 된다.
이것이 내가 아직 누구도 완전히 해결하지 못했다고 생각하는 아키텍처다.
“AI-native”가 실제로 의미해야 하는 것
“AI-native”는 거의 무엇이든 의미할 수 있는 표현 중 하나가 되어가고 있다. 아직 명확한 정의가 있다고 생각하지 않는다. 하지만 실제 에이전트 워크로드에서 거꾸로 생각해 보면, AI-native 데이터 시스템은 적어도 몇 가지를 잘 해내야 한다.
멀티모달 데이터는 일급 객체여야 한다
텍스트, 이미지, 오디오, 비디오, 임베딩, 로그, 트레이스가 관계형 테이블, 벡터 컬럼, 객체 버킷, 여러 보조 인덱스에 흩어져 있어서는 안 된다. 그것들은 검색, 필터링, 랭킹, 거버넌스가 함께 일어날 수 있는 하나의 논리적 시스템 안에 있어야 한다.
어려운 부분은 이러한 자산을 저장하는 것이 아니다. 어려운 부분은 아키텍처를 또 다른 파이프라인 문제로 만들지 않으면서 그것들을 함께 쿼리 가능하게 만드는 것이다.
탄력성은 워크로드에서 출발해야 한다
에이전트 트래픽은 폭발적으로 몰린다. 시스템은 한 시간 동안 조용하다가 검색, 메모리, 도구 사용 요청의 홍수를 받을 수 있다. 데이터 레이크나 객체 저장소는 저렴하고, 신뢰할 수 있으며, 컴퓨트와 분리된 내구성 있는 기반이 되어야 한다.
하지만 코퍼스가 존재한다는 이유만으로 컴퓨트가 계속 비싸게 유지되어서는 안 된다. 아무도 검색하지 않는다면 시스템은 아주 적게 지출해야 한다. 워크로드가 깨어나면 컴퓨트는 빠르게 도착해야 한다. 그런 세계에서 자연스러운 과금 단위는 항상 영구 클러스터가 아니다. 그것은 쿼리, 세션, 또는 활성 컴퓨트의 분 단위일 수 있다.
멀티테넌시는 에이전트 수준으로 이동해야 한다
전통적인 멀티테넌트 시스템은 흔히 관리 가능한 수의 대규모 테넌트를 가정한다. 에이전트형 시스템은 수백만 또는 수십억 개의 작고, 짧게 지속되며, 격리된 상태를 만들 수 있다. 각 에이전트는 자체 메모리, 권한, 트레이스, 임시 브랜치, 쓰기 경로를 가질 수 있다.
수천 개의 대규모 테넌트를 위해 구축된 설계는 테넌트가 에이전트 실행 자체가 될 때 어려움을 겪을 것이다.
브랜칭과 롤백은 핵심 데이터베이스 기능이 된다
에이전트는 잘못된 것을 쓸 것이다. 그것은 예외적인 경우가 아니다. 워크로드의 일부다.
유용한 AI 데이터 계층에는 데이터 상태를 위한 Git과 같은 브랜칭과 빠른 롤백이 필요하다. 에이전트 실행은 작업 브랜치를 포크하고, 작업을 테스트하고, 임시 상태를 기록한 뒤, 그것을 폐기하거나 승격할 수 있어야 한다. 잘못된 업데이트가 들어오면 시스템은 알려진 정상 지점으로 빠르게 돌아갈 수 있어야 한다.
버전 관리는 더 이상 분석 편의 기능만이 아니다. 그것은 운영 안전 메커니즘이 된다.
트레이스와 결정적 리플레이는 필수다
에이전트가 실패했을 때, 질문은 단지 “최종 답변이 무엇이었는가?”가 아니다. 그것은 “에이전트가 무엇을 보고, 검색하고, 순위를 매기고, 결정하고, 호출하고, 작성했는가?”이다.
이를 위해서는 모든 의미 있는 단계의 추적이 필요하다. 더 중요한 것은 재현이 필요하다는 점이다. 시스템은 문서가 변경되거나 인덱스가 재구축된 이후의 모습이 아니라, 당시 존재했던 의사결정 맥락을 재구성할 수 있어야 한다.
에이전트에게 감사 가능성과 디버깅 가능성은 같은 요구사항으로 수렴한다.
권한은 행뿐만 아니라 행동을 통제해야 한다
전통적인 권한 부여는 누가 테이블, 열, 또는 행을 읽을 수 있는지를 묻는다. 에이전트형 시스템에는 더 동적인 질문이 필요하다. 이 특정 단계에서 이 에이전트는 무엇을 검색하고, 호출하고, 수정하고, 공개하고, 지출할 수 있는가?
어려운 부분은 읽기 경로에서 행동 경로로 이동한다. 정책 집행은 사람이 대시보드를 열 때뿐만 아니라, 에이전트가 실행되는 동안 이루어져야 한다.
운영은 자율주행화되어야 한다
에이전트 수준의 규모는 사람이 운영하는 인프라를 무너뜨린다. 어떤 팀도 수백만 개의 작고 빠르게 움직이는 워크로드 전반에서 인덱스, 컴팩션, 캐시 워밍, 테넌트 배치, 복구, 리소스 스케줄링을 수동으로 관리할 수 없다.
시스템은 스스로 운영되어야 한다. 그렇지 않으면 아키텍처는 다이어그램에서는 작동할지 몰라도, 유일하게 중요한 곳인 프로덕션에서는 실패할 수 있다.
SQL은 최종 인터페이스로 충분하지 않다
내가 점점 더 많이 생각하게 되는 또 하나의 문제가 있다. 바로 인터페이스 자체다.
SQL은 애널리스트 시대에 올바른 인터페이스였다. 지금도 여전히 필수적이다. 하지만 데이터베이스와 분석을 중심으로 구축된 회사들에게 SQL은 일종의 경로 의존성이 될 수도 있다. 제품 표면, 사용자 모델, 심지어 조직까지도 주 사용자가 쿼리를 작성할 줄 아는 사람이라고 가정하는 경우가 많다.
AI 시대 데이터의 최종 인터페이스는 조금 더 나은 SQL 편집기가 아닐 것이다. 또한 데이터베이스 앞에 붙여 놓은 챗봇도 아닐 것이다.
더 흥미로운 종착점은 헤드리스이고 자연어 네이티브인 데이터 시스템이다. 사람이나 에이전트가 의도를 직접 말하면, 시스템이 모든 내부 단계를 쿼리 작성 연습으로 드러내지 않고도 답하거나, 행동하거나, 올바른 실행 계획을 준비할 수 있는 시스템이다.
하지만 이것은 데이터베이스에 네이티브해야지, 그 앞에 서 있는 별도의 에이전트여서는 안 된다.
자연어가 단지 애플리케이션 계층일 뿐이라면, 시스템은 제거하려는 바로 그 이음새들을 다시 도입하게 된다. 또 하나의 번역 단계, 또 하나의 오래된 컨텍스트 창, 또 하나의 거버넌스 공백 말이다. 데이터베이스 자체가 질문, 데이터, 정책, 실행 경로를 이해해야 한다.
그것은 친근한 인터페이스를 만드는 것보다 훨씬 더 어렵다. 이는 데이터베이스가 의미론을 소유해야 한다는 뜻이다.
여전히 중요한 해자
나에게 완벽하게 깔끔한 결론은 없다. 어쩌면 그게 적절한지도 모른다. 시장은 너무 빠르게 움직이고 있고, 너무 많은 오래된 가정들이 예상보다 더 빨리 빠져나가고 있다.
독점적인 쿼리 방언은 더 이상 예전과 같은 해자가 아니다. 에이전트가 통합 코드를 다시 작성할 수 있을 때 마이그레이션 비용은 약해진다. 다음 사용자가 인간이 아닐 수도 있을 때 익숙한 UI의 중요성은 줄어든다. 데이터를 단순히 소유하고 있다는 조용한 이점조차도 오픈 테이블 포맷, 자연어 인터페이스, 도구를 사용하는 에이전트가 이동을 더 쉽게 만들 때 약해진다.
내가 여전히 믿는 해자는 덜 화려하다. 오랜 기간에 걸쳐, 인내심 있게 반복적으로, 진짜 사용자 가치를 만들어내는 능력이다.
그래서 나는 Summit을 다녀온 뒤 Databricks를 진지하게 받아들이게 되었다. 나는 Databricks가 데이터 분야의 다음 1조 달러 기업이 될 실제 가능성이 있다고 생각한다. 모든 제품 발표가 최종 답변이기 때문은 아니다. 그중 일부는 바뀔 것이다. 일부는 아마 틀릴 것이다. 그것은 정상이다. 중요한 것은 회사가 계속해서 올바른 문제를 향해 되돌아가고 있다는 점이다.
그리고 올바른 문제는 더 이상 단지 분석, 웨어하우징, 또는 트랜잭션 스토리지가 아니다. 그것은 행동하는 AI 시스템을 위한 데이터 기반이다.
Zilliz 측에서도 우리는 다른 방향에서 비슷한 결론에 도달해 왔습니다. 벡터 데이터베이스는 사라지고 있지 않습니다. 비정형 및 멀티모달 데이터를 위한 더 넓은 아키텍처 안에서 서빙 엔진이 되고 있습니다. 그래서 우리는 Vector Lakebase라는 관점에서 생각합니다. 벡터 데이터베이스를 대체하는 것이 아니라, AI 워크로드가 더 지속적이고, 탄력적이며, 에이전트화됨에 따라 그들을 중심으로 구축되는 다음 아키텍처입니다.
지도는 아직 완성되지 않았습니다. 그것이 가장 좋은 부분입니다.
저렴한 것이 비싼 것을 이깁니다. 신뢰할 수 있는 것이 신뢰할 수 없는 것을 이깁니다. 신중한 것이 부주의한 것을 이깁니다. 인내심 있는 것이 성급한 것을 이깁니다.
AI-native 데이터베이스는 아직 그려지고 있습니다. 이 분야에서 구축하는 모든 이에게, 그것은 매우 좋은 소식입니다.
한 가지 더: Zilliz Vector Lakebase가 공개 프리뷰로 제공됩니다
우리는 Zilliz Vector Lakebase의 공개 프리뷰를 출시했습니다 — 순수 벡터 데이터베이스였던 Zilliz Cloud가 AI를 위한 레이크 네이티브 데이터 기반으로 크게 진화한 것으로, 저지연 벡터 서빙과 데이터 레이크의 개방성, 확장성, 경제성을 결합합니다.
Zilliz Vector Lakebase 핵심 기능:
- 다양한 실시간 성능-비용 트레이드오프에 최적화된 계층형 서빙
- 상시 구동 컴퓨팅 없이 대규모 또는 탐색형 워크로드를 위한 온디맨드 검색
- 외부 데이터 레이크 검색 — 기존 레이크 데이터 위에서 직접 인덱싱하고 검색
- 하이브리드 검색 및 재랭킹을 통해 벡터, 텍스트, JSON, 지리공간 데이터 전반을 아우르는 풀 스펙트럼 검색
- Lance 또는 Parquet보다 더 빠르고 저렴한 랜덤 읽기를 제공하는 개방형 포맷 Vortex 기반의 통합 레이크 네이티브 스토리지
현재 스택이 서빙과 디스커버리를 별도 시스템으로 나누고 있다면, Vector Lakebase를 살펴볼 가치가 있을 수 있습니다. Zilliz Cloud에서 사용해 보세요 — 새 업무용 이메일 가입자는 $100 무료 크레딧을 받습니다 — 또는 귀하의 사용 사례에 대해 문의하세요.
계속 읽기
Vector Lakebase: End the AI Data Silo
Learn how Vector Lakebase unifies vector search, data lakes, and AI data operations so teams can serve RAG and agents without copy-and-sync pipelines.
Notion's Vector Search Is Excellent. Their Next Problem Is Harder.
Notion solved vector search scaling in two years. The next bottleneck — offline context engineering, unified data, and the real-time/offline gap — is harder.
Zilliz Cloud Update: Smarter Autoscaling for Cost Savings, Stronger Compliance with Audit Logs, and More
What's new in Zilliz Cloud? Smarter autoscaling with scale-down, audit logs GA, enhanced SSO, and Milvus 2.6 in Private Preview.