What are deployment models for vector-native memory systems?

Choosing managed versus self-hosted answers who operates memory. Deployment models answer how the vector-native substrate is shaped in each environment. Docker suits local evaluation. Kubernetes carries self-managed production. Weaviate Cloud Shared and Dedicated plans host production without you owning nodes. Weaviate Engram adds a managed memory control plane on that family of backends. This chapter maps those models, explains when replication and sharding enter the picture, and shows how application code should stay tied to Engram APIs rather than to a specific topology diagram.

Which Deployment Models Exist for Vector-Native Memory?

Start with the evaluation lane. Docker Compose runs Weaviate quickly on a laptop, optionally with local inference containers. Embedded clients exist for throwaway experiments. Neither is a production posture. They exist so agents can be developed before anyone debates StatefulSets.

Self-managed production means Kubernetes. Weaviate documents Kubernetes as the supported production path for self-hosted clusters, with Helm charts, multi-node gossip settings, and optional zero-downtime upgrades when replication is enabled. Marketplace installs on major clouds follow the same idea with different billing envelopes.

Managed production means Weaviate Cloud. Shared Cloud is fully managed SaaS with consumption pricing and optional high availability. Dedicated Cloud isolates infrastructure for stricter security and more predictable performance. Weaviate Engram projects live in that managed world. You create a project, take an API key, and treat memory as a service while the vector index and pipeline substrate stay Weaviate’s problem.

How Do Replication and Sharding Change the Topology?

Once a model is picked, scale mechanics matter. Replication copies the same shard across nodes. It buys high availability, higher read throughput, and rolling upgrades without user-visible downtime. On Weaviate Cloud, enabling high availability at cluster creation is the console equivalent of a multi-node replica set. On self-hosted clusters, you set a replication factor on collections and run enough nodes to host those replicas.

Sharding splits a collection so each node holds only part of the data. It helps when a single machine cannot hold the HNSW working set. Multi-tenant collections often map one tenant to one shard, which fits Engram-style user isolation patterns at the database layer. Replication and sharding can combine. That combination is how large memory fleets stay both big and resilient.

Replication multiplies storage and RAM cost. The growth monitors from earlier chapters must count replicas, not only logical memories. A factor of three is three times the rent for the same facts.

Which Model Should a Memory-Backed Agent Use at Each Stage?

Match the stage to the risk. Prototyping can use Docker for a companion knowledge base and Engram in a Cloud project for true agent memory. Staging should mirror production topology. If production Engram sits on a highly available Cloud cluster, staging should too. Surprises at cutover usually come from missing HA, missing auth, or missing network policies, not from prompt text.

Production defaults for most teams should be Weaviate Engram on Weaviate Cloud with high availability enabled when the SLA requires it. Move to Dedicated Cloud when shared tenancy, compliance, or throughput demand isolation. Choose self-hosted Kubernetes when air gaps or residency rules forbid managed control planes, and staff the cluster like any other stateful production system.

Avoid hybrid spaghetti without a diagram. One Engram project for personalization and one self-hosted Weaviate for a huge shared corpus can be rational. Five half-configured clusters for the same user_id space is not. Topology should follow clear group and scope boundaries.

How Should Application Code Ignore Topology Details?

Agents must not embed Docker hostnames or Helm release names. They should read an Engram API key from the environment and call the same add and search paths everywhere. Topology changes then become console or Helm work, not a rewrite of every worker.

Health checks still matter. Your dashboards should record which deployment model and HA setting the environment uses so an alert can tell staging Docker noise from production Cloud failures. Annotate deploys when replication factors change. Those annotations save hours when latency shifts overnight.

Here is a reef-lab agent that talks only to managed Engram while operators choose Cloud HA behind the scenes:

import os
from engram import EngramClient, HybridRetrieval

# Topology (Shared vs Dedicated, HA on/off) is configured in Weaviate Cloud.
# The agent only needs the project key for this Engram deployment model.
client = EngramClient(api_key=os.environ["ENGRAM_API_KEY"])

aquarist = "aquarist-devon"
group = "reef_lab"
tank = "tank-reef-12"

DEPLOYMENT_MODEL = os.environ.get("MEMORY_DEPLOYMENT_MODEL", "engram_weaviate_cloud_ha")

run = client.memories.add(
    [
        {
            "role": "user",
            "content": "Tank reef-12: keep alkalinity at 8.2 dKH and do not dose calcium while the reactor is offline tonight.",
        },
        {
            "role": "assistant",
            "content": "Logged alkalinity hold and calcium pause for tank reef-12.",
        },
    ],
    user_id=aquarist,
    group=group,
    properties={
        "tank_id": tank,
        "deployment_model": DEPLOYMENT_MODEL,
        "cost_center": "reef_ops",
    },
)

hits = client.memories.search(
    query="What alkalinity and calcium dosing rules apply for tank reef-12 tonight?",
    user_id=aquarist,
    group=group,
    properties={"tank_id": tank},
    retrieval_config=HybridRetrieval(limit=5),
)

print({
    "deployment_model": DEPLOYMENT_MODEL,
    "run_id": run.run_id,
    "run_status": run.status,
    "hit_count": len(hits),
    "previews": [m.content[:120] for m in hits],
})

The deployment_model property is telemetry for dashboards, not a switch inside Engram. Operators still change HA in the Cloud console. Workers keep the same client shape across Docker-based integration tests that mock Engram and Cloud-based production.

What Failure Modes Belong to Each Deployment Model?

Docker single-node loss means total memory outage for that laptop stack. That is acceptable in development and unacceptable in production. Kubernetes without replication loses any shard whose only node dies. Kubernetes with replication survives node loss if consistency settings and replica counts match your SLO. Cloud Shared without HA is simpler and cheaper, but planned maintenance windows hit harder. Cloud with HA trades cost for continuity.

Engram pipeline failures are orthogonal to node count. A bad extract still fails on a three-replica cluster. Keep run-level debugging and regression gates even when the topology is perfect. Infrastructure high availability does not replace memory quality operations.

Pick a deployment model that matches stage and SLA, enable replication when downtime is unacceptable, and keep Weaviate Engram as the application-facing memory service whenever managed infrastructure fits. The next scaling chapter starts from that topology and asks how to grow it under heavy write and search load.

Our next chapter, How do you scale vector databases for high-volume memory workloads?, takes these topologies into capacity planning, and shows how to scale vector-native memory when traffic and retained memories climb together.