Milvus: read this before you install it

Milvus is powerful, but the standalone setup is already a small stack: Milvus, etcd, and MinIO. I would not treat it like a single binary database. I would test service health, storage, ports, and WebUI before inserting real vectors.

This is a stack, not one container

I would not call Milvus a simple one-command install. The official standalone path is Docker Compose, and it brings up multiple services. That is fine, but it means the first check is component health, not just a port opening.

If the reader is on a small laptop or VM, I would check memory before starting. Vector databases make bad first impressions on machines that are already starving.

When Milvus is worth the weight

Milvus fits when vector search is not just a toy feature: larger collections, operational tooling, indexes, and a path toward scale matter.

I would not choose it for a 100-document prototype unless I specifically wanted to learn Milvus. Smaller stores are easier for first experiments.

Milvus, etcd, MinIO, proxy, collections

Standalone Milvus still depends on supporting services. etcd holds metadata, MinIO handles object storage, and Milvus serves vector operations through its components.

That means failure can live outside the Milvus process. If MinIO or etcd is unhealthy, the vector DB will not behave like a healthy database.

The checks before creating collections

I download the official compose file, start it, and check containers before writing Python. I also open the WebUI if available because it gives a quick sanity check.

Then I create one collection with a known dimension and insert a handful of vectors. I do not load a large embedding set until the collection lifecycle works.

My Milvus command path

Use prep for Docker, Compose, RAM, disk, and compose file. Use verify for container health and one client connection. Use debug at the component level.

Do not delete volumes as a first debugging move unless you have accepted data loss.

When Proxy is not ready yet

Proxy-not-ready errors are often startup or dependency symptoms. I wait briefly, then read standalone, etcd, and MinIO logs.

If data disappears, I inspect the `volumes` directory. If connection fails, I check port 19530 and firewall before changing client code.

The first collection I would keep

The first collection I would keep has three vectors, payload fields, and one search query that returns a predictable result.

After that, I test restart. Persistence is not optional for a database.

Field commands I would keep beside this note

# Milvus prep

docker version
docker compose version
free -h
df -h

# official docs provide a standalone compose file
wget https://github.com/milvus-io/milvus/releases/download/v2.5.27/milvus-standalone-docker-compose.yml -O docker-compose.yml

# Milvus verify

docker compose up -d
docker compose ps

# ports commonly used by standalone setup
# 19530: Milvus service
# 9091: WebUI in current standalone docs

# then connect with PyMilvus or WebUI before real data

# Milvus debug

proxy not ready -> wait, then inspect logs
docker compose logs --tail=120 milvus-standalone
docker compose logs --tail=120 milvus-etcd
docker compose logs --tail=120 milvus-minio

lost data -> inspect ./volumes
connection fail -> check port 19530 and firewall