Migrate or Connect Existing

Goal: take an application that already uses Milvus and move it onto a VBase database with the smallest possible change. Because VBase runs Milvus 2.6 and is Milvus-SDK-compatible, your collections, indexes, and search code are unchanged — only the connection coordinates change.

For the full SDK reference, see the Milvus documentation .

What changes: just three values

Whatever Milvus endpoint your app connects to today, you swap in three values from your allocated VBase database:

Value	Where it comes from
`uri`	The `endpoint` + `port` from `GetServiceAccess` (or `dodil vbase db use`), as `https://<endpoint>:443`.
`token`	Your Dodil IAM service-account bearer token — this is your Milvus token.
`db_name`	The `db_name` returned for the allocated database.

Everything downstream — create_collection, create_index, insert, search, hybrid_search, load_collection — stays exactly as it is. See Connecting with the Milvus SDK and Auth and Access for how those values are issued.

Before and after

A typical existing connection to a self-managed Milvus, with its own user and password:


# Before — self-managed Milvus
from pymilvus import MilvusClient
 
client = MilvusClient(
    uri="http://milvus.internal:19530",
    token="root:Milvus",            # Milvus username:password
    db_name="default",
)

The same app on VBase — same SDK, same calls, new coordinates:


# After — VBase
from pymilvus import MilvusClient
 
client = MilvusClient(
    uri="https://<endpoint>:443",   # endpoint + port from GetServiceAccess / `dodil vbase db use`
    token="<IAM access token>",      # your IAM service-account token IS your Milvus token
    db_name="<db_name>",             # the allocated database
)

The only differences:

TLS by default. VBase endpoints are HTTPS on port 443, not plaintext 19530.
IAM, not Milvus credentials. Pass your IAM bearer token as token. You do not create Milvus users, roles, or run any create_user / grant_role admin commands — VBase owns the underlying Milvus users and RBAC, and access is governed by your IAM scopes and organization.
A managed db_name. Use the database name VBase allocated, not default.

Moving existing data

There is no special migration API — you move data with the standard Milvus SDK by reading from the source and inserting into VBase. Recreate the schema and index on the VBase side, then stream the rows in batches (see Bulk Ingest & Index for the batching pattern):


from pymilvus import MilvusClient
 
src = MilvusClient(uri="http://milvus.internal:19530", token="root:Milvus", db_name="default")
dst = MilvusClient(uri="https://<endpoint>:443", token="<IAM access token>", db_name="<db_name>")
 
# Recreate the collection + index on `dst` to match the source schema first
# (see the Semantic Search and Bulk Ingest recipes), then copy in batches:
offset, BATCH = 0, 2_000
while True:
    rows = src.query(
        collection_name="documents",
        filter="",                  # all rows
        output_fields=["id", "embedding", "text", "category"],
        limit=BATCH,
        offset=offset,
    )
    if not rows:
        break
    dst.insert(collection_name="documents", data=rows)
    offset += BATCH

Recreate indexes on the destination and load_collection before serving search traffic. For very large datasets, Milvus also offers file-based bulk import — see the Milvus documentation .

VBase directly vs. through K3 Vector

There are two ways to use Dodil’s vector capabilities, and this recipe is about the direct path.

Use VBase directly (these recipes) when you want the full native Milvus 2.6 surface — every index type, hybrid + BM25 search, partitions, custom schemas — and you want to own your database lifecycle (allocate, connect, drop) and talk to it with the standard Milvus SDK from your own code.
Use K3 Vector when you want a higher-level, opinionated vector experience. K3 Vector is built on VBase, so it runs on the same foundation, but it abstracts the Milvus details behind its own interface. Go direct to VBase when that abstraction gets in the way of the native Milvus features you need.

If your app already speaks the Milvus SDK, the direct VBase path is almost always the smaller change — you keep your existing code and only repoint the connection.

Notes

Metering. During a migration, the reads from VBase (query/search) are metered as VectorRead and the inserts as VectorWrite, with stored vectors counting toward VectorStorage. Reading from a self-managed source is not metered by VBase. All VBase usage is scoped to your organization’s quota.
What VBase manages. The Milvus service, its users, and RBAC — which is why you drop the Milvus username/password and authenticate with IAM instead.
Reference. Connection options, data migration, and the full SDK surface are in the Milvus documentation .