OpenArt Powers Multimodal Search for 8M+ AI Video Creators with Zilliz Cloud
25 s → 300 ms
P99 search latency, ES → Zilliz
~85% lower
Compute cost after migration
Native multi-vector search
Image and text vectors queried together
456M
Vectors migrated with no re-embedding
"Creators don't make one image and leave. They build a character, a world, a story, and everything they've ever generated becomes material for the next scene. Zilliz Cloud lets us treat that whole library as one creative memory."
John Qiao
About OpenArt
OpenArt is one of the world's most widely used AI image and video generation platforms, with more than 8 million creators on it — hobbyists, marketers, and working entertainment professionals. It puts 100+ models from Google, OpenAI, Seedance, and others into a single canvas, but the models are the commodity part. What OpenArt builds on top of them is continuity: a Character Builder that holds a character across scenes, One-Click Story for multi-scene narratives, and a storyboard suite creators use to make trailers, ads, and social video. The ambition behind all of it is to put AI-native IP within reach of any creator — characters and worlds that persist and grow, rather than images that don't.
Continuity is the hard part, and not only at generation time. The challenge in AI video isn't producing fifteen good seconds — it's producing the next fifteen and having them belong to the same story. It also has a consequence downstream: creators return to a world for months, and everything they have ever generated becomes reference material for the next scene. A creator's own back catalog has to be findable by meaning rather than by filename or date, and that’s where OpenArt leverages Zilliz Cloud.
The Challenge
OpenArt's creator search ran on Elasticsearch's vector search. It held up while the library was small. By the time the generation history passed a few hundred million vectors, four things had broken.
- P99 search latency reached 25 seconds. Elasticsearch's index lifecycle management is built for log data, so it rolled OpenArt's indices from hot to warm to cold to frozen roughly every 90 days, and most of the corpus ended up frozen — but vector search has the opposite access pattern, because ranking a top K means scoring everything. Every search reached into the frozen tier and pulled data back across the network to answer it.
- Index count grew exponentially. Elasticsearch created at least one new index every 90 days and never merged them, so the number of indices a query had to fan out across kept multiplying. On a library that only gets bigger, the team projected search degrading sharply within about two years.
- OpenArt was paying for a whole search platform to use one narrow feature of it. On top of that, the cluster was over-provisioned because the team sized it before measuring the workload's actual needs.
- Multi-vector retrieval had to be hand-built. Elasticsearch had no native way to query an image vector and a text vector together, so OpenArt had to write its own dual-kNN algorithm and wire in third-party components to run both searches, fuse the results, and filter them — a permanent maintenance item on a capability that isn't OpenArt's differentiator.
Why Zilliz Cloud
The OpenArt engineering team evaluated Pinecone and Qdrant, and neither was the right fit. The team had also run Milvus itself in the company's early days and liked it; what ruled it out at the time was the operational load of self-hosting. Zilliz Cloud removed that objection: it is built by the same team behind open-source Milvus and is 100% compatible with the Milvus APIs, so the team's existing knowledge and client code carried over.
Benchmarks against OpenArt's own data confirmed the performance, and the evaluation stopped there. Four things make Zilliz Cloud stand out:
An architecture built for how vector search reads data. Zilliz Cloud manages data tiers itself based on data temperature: it promotes data into cache when it is frequently retrieved or demotes it to cold storage when it is not needed, with no lifecycle policy for the application to reason about, and segment-level auto-compaction merges data in the background as it grows. Those two capabilities address exactly the failure modes OpenArt had been living with — frozen-tier traversal and unbounded index proliferation — so OpenArt's search doesn't get slower as the library grows.
Native multi-vector search. A single Zilliz Cloud collection holds multiple vector fields and queries them together in one request, fusing the results by a configurable weighting. That is precisely the capability OpenArt had been hand-building on top of Elasticsearch, and getting it natively is what let the team delete its own code.
Pricing tied to compute on-demand, not to stored data. One of the alternatives billed on data volume — the wrong axis for a creative archive, where the corpus grows forever but only a fraction is queried at any moment. Zilliz Cloud's on-demand compute-based model lets OpenArt size for the performance it needs and resize as the workload changes, instead of paying a tax on history.
Operable without an infrastructure specialist. A managed service still has to be usable day-to-day by the people who have it. OpenArt found the console clear enough to navigate by intuition, without reading documentation — a sharp contrast to a general-purpose search platform carrying a decade of accumulated features they would never use.
"We serve millions of creators, so every piece of infrastructure has to be fast, predictable, and need nobody watching it. Zilliz Cloud is one of the few that cleared that bar on the first try." — Danny Xiong, Software Engineer, OpenArt
The Solution: How Zilliz Cloud Powers OpenArt
OpenArt uses Zilliz Cloud to run vector search behind the search box over a creator's own generation history, available to subscribers on qualifying plans. A creator who has made thousands of images and clips over months types a phrase — a character name, a mood, a scene — and gets back their own past work, ranked by meaning rather than by filename or date.
That job is harder than it sounds, because a generation arrives with no metadata. There is no title, no tag, no folder. Only two artifacts describe it: the asset itself, and the prompt that produced it. OpenArt indexes both, because each carries something the other doesn't — the prompt holds what the creator asked for, in names and intent and style words, and the asset holds what the model actually produced, which is frequently not the same thing. Searching either one alone loses half the library.
OpenArt splits the work across three services.
- Its application and primary database run on Google Cloud.
- Its embedding service runs on Modal — a Jina CLIP model the team hosts itself on a serverless GPU function.
- Vector storage and retrieval go to Zilliz Cloud. The team keeps the model layer under its own control and hands off the layer that has to scale.
AI image and video generation is created continuously and searched for much later, so OpenArt built the system as two independent halves that run at completely different times and rates.
- The write path turns every new generation into vectors and lands them in Zilliz Cloud. It runs constantly in the background, triggered by creation events, and nobody is waiting on it.
- The read path runs only when a creator types in the search box. It has to return in a few hundred milliseconds, because someone is watching a spinner.
The write side never sits on the query path — the only place they meet is the collection itself. That separation is why continuous ingestion never shows up as query latency.
The write path: how OpenArt turns a generation into two vectors
- A creator on an eligible plan generates an image or a clip, and OpenArt writes a snapshot of it to its primary database on Google Cloud.
- A Google Cloud Function fires on that event and calls OpenArt's embedding service on Modal. Because Jina CLIP maps images and text into the same vector space, a single model provides the team with both vectors it needs.
- OpenArt writes those two vectors to Zilliz Cloud — one for the generated asset, one for the prompt behind it — together with the generation ID and the scalar fields the read path will filter on: user ID and project ID.
OpenArt handles video through the same route, capturing a snapshot frame from each generated clip and embedding it as an image, so clips are retrievable alongside stills without a second pipeline.
In addition, search is a paid feature, so an eligible creator's entire back catalog has to become searchable, not just whatever they make from that day forward. A scheduled backfill job runs continuously in the background, sweeping creators on eligible plans and paging each one's history through the same embed-and-write route. It doubles as the pipeline's safety net: anything the realtime path fails to write, the backfill picks up on a later pass.
The read path: how OpenArt answers a search
- A creator types a query, and OpenArt sends it to the same Modal-hosted model to be turned into a query vector.
- OpenArt issues a single multi-vector search to Zilliz Cloud across both vector fields, with configured weights between them, and the user and project filters attached.
- Zilliz Cloud fuses the two result sets, evaluates the filters inside the search rather than after it, and returns the top K. OpenArt runs a final match and filter against its own database on Google Cloud before rendering.
OpenArt asks for more than a thousand results per query — an unusually large top K for semantic search, driven by the workload rather than the interface: for a heavy creator, a single project's assets already exceed a thousand, and a broad query like "man" legitimately matches several times that.
The same query on the old stack looked nothing like this. It fanned out across every index the lifecycle policy had ever created, most of them frozen, and pulled data back across the network until it could rank a top K. On Zilliz Cloud, OpenArt makes one call to one collection and has an answer in roughly 300 milliseconds.
How OpenArt collapsed two searches into one
Combining the image and prompt results is exactly what OpenArt had hand-built the dual-kNN fusion layer for on Elasticsearch. Because Zilliz Cloud natively queries multiple vector fields, the team removed that code and re-expressed the retrieval as a single request — then wrapped the weighting between the two fields in a feature flag. Relevance became something OpenArt tunes in production rather than something it re-implements.
How OpenArt migrated
OpenArt moved a legacy set of roughly 456 million vectors and used the cutover to run data hygiene on it: dropping records the product no longer needed and fixing bugs that the old ingestion path had been quietly introducing. One scoping decision kept the project bounded: the team kept its existing embedding model. Re-embedding hundreds of millions of assets would have turned a migration into a rebuild. Because Zilliz Cloud stores vectors from whatever model a customer chooses, OpenArt moved storage and retrieval without touching the model layer.
Results & Benefits
- Search latency fell from 25 seconds using Elasticsearch to roughly 300 milliseconds at P99 — about 80× faster, and the difference between a search box creators avoid and one they use.
- Compute cost cut by roughly 85% — the same workload, on an engine built for it.
- OpenArt removed the hand-built fusion algorithm from the production pipeline. With multi-vector search native in Zilliz Cloud, the dual-kNN code and its third-party glue are gone, and tuning relevance is a config change rather than an engineering project.
- 456 million vectors were moved to Zilliz Cloud without re-running a single embedding because Zilliz Cloud is model-agnostic — keeping the migration a migration rather than a rebuild.
The strategic payoff is the one OpenArt feels most: search stopped being an infrastructure project. The engineering capacity that had gone into keeping retrieval alive went back to the product — specifically, to the agent layer OpenArt is now building its whole experience around.
OpenArt's advice for teams choosing a vector database
Having done this twice — off self-hosted Milvus early, then off Elasticsearch — OpenArt's team distills the decision to a short list.
- Check that the pricing model matches your workload's shape. Ask what you're billed on, then ask which of your numbers grows fastest. If those are the same number, you have a problem that scales with your success.
- Check that the architecture matches your access pattern. Read the storage design, not the feature list. A policy that ages data out of reach is fine for logs and wrong for vector search.
- Know your own performance requirements before you provision. OpenArt's biggest cost mistake was over-provisioning hardware for a workload it hadn't profiled. Measure first.
- Treat a migration as a chance to throw things away. Everything you carry across, you pay for and search through forever.
What's next
OpenArt uses Zilliz Cloud for search across a creator's own generation history today, and plans to extend it in three directions:
- The shared asset and template library, where the team's labeling work and recommendation templates both need semantic search.
- Scalar filtering, deferred during the migration and now moving back up the list.
- Agent memory, which is what the team is most interested in. As OpenArt shifts from discrete tools to an agent that orchestrates them — stretching a 15-second generation into a one-minute or three-minute film — the agent has to remember across sessions which project a creator is in and which brand they're making ads for. That is a vector-search problem, and it's where OpenArt expects its use of Zilliz Cloud to grow next.
"OpenArt is defining what AI-native creation looks like: millions of creators building characters and stories that hold together across scenes. We're proud Zilliz Cloud is the retrieval foundation behind that, and excited to keep building with them as their agents start to remember." — James Luan, CTO, Zilliz
Try Zilliz Cloud for Free
Zilliz Cloud is a fully managed Vector Database and Vector Lakebase for enterprise AI, compatible with Milvus APIs. It delivers high-performance vector search at massive scale with enterprise-grade security and zero-maintenance operations, extended with the openness, scalability, and economics of multimodal data lakes — a single platform to search, analyze, and govern unstructured data for production AI.
Whether you're building multimodal search, RAG, or agent memory, Zilliz Cloud provides the same retrieval foundation that powers OpenArt. Get started with Zilliz Cloud for free, or talk to our team.
"Our old search took 25 seconds at P99. That was unacceptable. Zilliz Cloud put it back under a third of a second and let us delete the retrieval code we'd been maintaining ourselves."
Danny Xiong