How to Store TwelveLabs Marengo Embeddings in Your Own Vector Store

The Short Answer

Marengo generates multimodal embeddings (video, text, audio, image) through an asynchronous task: the TwelveLabs /embed-v2/tasks endpoint, or Bedrock's StartAsyncInvoke. The current model is Marengo Embed 3.0 (twelvelabs.marengo-embed-3-0-v1:0), and the number that matters most when you persist it yourself is that 3.0 returns a 512-dimensional vector where 2.7 returned 1024. Embeddings created through the TwelveLabs async endpoint are stored for seven days. For production reuse you must persist them somewhere durable yourself. A bring-your-own-vectors store like Mixpeek MVS does this in three calls: create a namespace whose vector config matches Marengo's dimension, upsert the embeddings with their temporal metadata as payload, and search. Your embeddings live on object storage you control, alongside vectors from any other model.

Marengo 3.0 is native in Amazon Bedrock Knowledge Bases: what changes?

Two different things landed and most coverage blurs them. Marengo Embed 3.0 has been callable as a model on Bedrock since its launch date of 29 October 2025, through StartAsyncInvoke on the bedrock-runtime endpoint. What is new is that it became an embedding model inside Amazon Bedrock Knowledge Bases, the managed service, announced by AWS on 10 September 2026. The first is an API you call and then handle the output yourself. The second is a managed pipeline where you connect a video library and search works, with the vectors and the indexing handled for you.

What changes for anyone already running the pattern in this guide:

Bedrock Knowledge Bases

Call the model, keep your own store

Who holds the vectors	The managed service	You
Fuse with embeddings from other models	No	Yes
Storage outside AWS	No	Yes
Work to get first results	Connect a library	Generate, upsert, search
Video stays in your own account	Yes, in your S3	Yes, wherever you put it

The managed path is the right answer for more teams than this guide's audience will want to admit. If your video already sits in S3, your search is only over video, and you have no requirement to mix Marengo vectors with anything else, Bedrock Knowledge Bases removes the work in this guide entirely and keeps the footage inside your AWS account. Use it.

The pattern below earns its keep on the axis the managed path does not cross: one queryable surface across models and modalities. Marengo vectors beside text embeddings from a different model, beside image vectors from a third, filtered by metadata you own, on storage you choose. That is a composition problem rather than a video-search problem, and it is the reason to hold the vectors yourself.

The dimension change is the one thing that bites on upgrade. A store configured for 2.7's 1024 dimensions will reject or silently mismatch 3.0's 512, so re-embedding from 2.7 to 3.0 means a new namespace rather than an in-place write. Halving the vector also halves what the same corpus costs to store, which is the upgrade's quiet benefit.

September 2026: a DAM you may already use is running this

What happened: on 10 September 2026 TwelveLabs announced that Marengo became an embedding model in Amazon Bedrock Managed Knowledge Bases, and named iconik, the media asset management platform from Backlight, as among the first customers using it there. Does it change your architecture? Only if iconik is where your footage lives and video search is all you need, in which case the managed path now covers it. If you are joining video to anything else, the split below is unchanged.

That split is worth stating plainly, because the announcement makes it easy to blur. Marengo produces the embeddings, and you run it yourself through Bedrock in your own AWS account. The boundary is exactly there. What Mixpeek does is store those embeddings, combine them with vectors from other models, and retrieve across the result. TwelveLabs' release is explicit that no video leaves the customer's environment, which is the same substrate position this guide starts from: the media stays where you put it.

Worth knowing if you are on iconik: Mixpeek has its own iconik integration, so the same library can feed either path.

Why persist Marengo embeddings at all?

Two reasons. Cost: embedding is the expensive step, re-running the async task because the seven-day window lapsed is pure waste. Composition: once the vectors live in a store you control, they stop being TwelveLabs-only. You can filter them by your own metadata, fuse them with text or image embeddings from other models, and serve them to agents: none of which is possible while they exist only inside a task response.

Step 1: Generate the embeddings

Use the TwelveLabs SDK or Bedrock. On Bedrock, the async invocation delivers results to S3:

# Bedrock: StartAsyncInvoke with the Marengo model
import boto3

bedrock = boto3.client("bedrock-runtime")
bedrock.start_async_invoke(
    modelId="twelvelabs.marengo-embed-3-0-v1:0",
    modelInput={
        "inputType": "video",
        "mediaSource": {"s3Location": {"uri": "s3://your-bucket/game-footage.mp4"}},
    },
    outputDataConfig={"s3OutputDataConfig": {"s3Uri": "s3://your-bucket/embeddings/"}},
)

The response contains one embedding per segment with startSec/endSec markers and an embeddingOption (such as visual-text). Read the vector dimension off your actual response rather than assuming it: 512 for Marengo 3.0, 1024 for 2.7, and the store's config must match exactly. Bedrock exposes 3.0 in-Region in us-east-1, eu-west-1 and ap-northeast-2, with us. and eu. cross-Region inference ids.

Step 2: Create a matching MVS namespace

from mixpeek import Mixpeek

client = Mixpeek(api_key="YOUR_API_KEY")

client.namespaces.create(
    namespace_id="marengo-video",
    mode="standalone",
    vector_configs=[
        # 512 for Marengo 3.0; use 1024 if you are still on 2.7
        {"name": "marengo_visual", "dimension": 512, "metric": "cosine"},
    ],
)

MVS can also infer the config from the first write, but declaring it pins the dimension and distance metric explicitly.

Step 3: Upsert embeddings with temporal payload

Keep the segment timing and source pointers as payload so search results map back to playable moments:

client.namespaces.documents.upsert(
    namespace_id="marengo-video",
    documents=[
        {
            "id": "game01-seg-004",
            "vectors": {"marengo_visual": segment["embedding"]},
            "payload": {
                "video_uri": "s3://your-bucket/game-footage.mp4",
                "start_sec": segment["startSec"],
                "end_sec": segment["endSec"],
                "embedding_option": segment["embeddingOption"],
            },
        }
        for segment in marengo_segments
    ],
)

Up to 1,000 documents per request; use bulk import for large backfills.

Step 4: Search by embedding a query the same way

Embed the text query with Marengo (text input type), then search: the query and documents must come from the same embedding space:

results = client.search(
    namespace_id="marengo-video",
    queries=[{
        "vector_name": "marengo_visual",
        "vector": query_embedding,
        "top_k": 10,
    }],
)
# each hit returns your payload: video_uri, start_sec, end_sec

From here you can add metadata filters, BM25 over payload text, or hybrid fusion with vectors from entirely different models: the store does not care who produced each embedding.

When does this pattern make sense?

Use Amazon Bedrock Knowledge Bases when the footage is already in S3, the search is only over that video, and nothing else needs to join it: it is managed, the data stays in your AWS account, and it removes every step of this guide. Use TwelveLabs end-to-end when video is your only modality and their hosted index workflow fits: it is the shortest path to high-quality video search, and you skip running a vector store. Add your own store when any of these hold: embeddings must outlive the seven-day task window; content pointers must stay on your object storage; you are fusing Marengo vectors with text, document, or image embeddings from other models; or agents need one queryable surface across everything. The feature-by-feature comparison and alternatives breakdown cover the broader decision; MVS pricing starts at $25/mo on the rate card, and BYO object storage covers running it over your own buckets. For the tool landscape, see best AI video analysis tools.