Shared storage architecture

Graph Studio and Graph Lakehouse interact during data ingestion, graph generation, and loading workflows. This guide covers the storage tiering requirements, compares object storage against Network File System (NFS), and provides production-ready configuration specifications for cross-component shared storage.

Storage tiering overview

Production Graph deployments require distinct storage classes and access modes depending on the role of the data. Differentiate application persistence, database persistence, and shared staging storage:

Storage role	Component	Access mode	Recommended backing storage	Lifecycle & persistence
Graph Studio application persistence	Graph Studio pod	ReadWriteOnce (RWO)	High-performance block storage (NVMe/SSD PVC)	Persistent; tied to the Graph Studio instance for server journals, data, and state.
Graph Lakehouse database persistence	Graph Lakehouse pods	ReadWriteOnce (RWO) per node	High-performance local block storage (Fast SSD PVC)	Persistent; database data, system catalogs, and write-ahead logs. Must not be mounted across components.
Shared staging storage	Graph Studio & Graph Lakehouse	Object store API or ReadWriteMany (RWX)	S3 / Azure Blob (preferred) or NFSv4+ filesystem	Operational workspace for datasets, staged load files, Turtle/RDF exports, and file-based exchanges between Studio and Lakehouse.

Separate persistence from staging

Never point Graph Studio application persistence or Graph Lakehouse database system volumes to a shared staging mount. Shared staging storage is strictly intended for staging dataset files, ETL source documents, and bulk-load data.

Storage access comparison: Object storage vs. NFS

When architecting shared file storage between Graph Studio and Graph Lakehouse, evaluate the deployment target and platform capabilities:

Consideration	Cloud object storage (S3 / Azure Blob)	Network File System (NFSv4+)
Recommendation	Preferred for cloud and hybrid deployments.	Required for on-premise environments lacking S3-compatible endpoints, or workflows mandating direct POSIX file paths.
Protocol	REST / HTTP(S) API via cloud endpoints.	POSIX filesystem mount over TCP (port 2049).
Concurrency & scale	Highly scalable; native multi-client reads and writes without file lock contention.	Requires ReadWriteMany (RWX) PV/PVC; subject to NFS locking, network latency, and export sizing limits.
Security & credentials	IAM roles, instance profiles, or service principals. No Kubernetes UID/GID alignment needed.	POSIX UID/GID permissions, fsGroup, and export squash mapping required across pods.
Failure modes	Endpoint connectivity, IAM permission errors, rate throttling.	Stale NFS file handles, mount timeouts, RPC port blocking, file ownership mismatches.

Preferred pattern: Cloud object storage File Connections

In cloud environments (AWS, Azure) or modern private clouds with S3-compatible endpoints (such as Ceph or MinIO), configure shared storage through native File Connections:

• Direct integration: Graph Studio stages RDF source graphs, tabular datasets, or transformed loads directly into the target bucket/container.
• Direct loading: Graph Lakehouse loads files directly from S3 or Azure Blob storage via native load statements and credentials without traversing Kubernetes host mounts.
• Decoupled operations: Eliminates the operational overhead of managing NFS servers, volume locks, and host-level mount failures.

When deploying in cloud environments, provide Graph Lakehouse and Graph Studio pods with appropriate network egress and IAM identities (e.g., AWS IAM Roles for Service Accounts or Azure Workload Identity) granting read/write permissions to the shared bucket.

Validated NFS architecture (POSIX shared storage)

When deploying on-premise or in infrastructure where cloud object storage is unavailable, use Network File System (NFS) to provide a shared POSIX filesystem mount across both Graph Studio and Graph Lakehouse pods.

NFS protocol and network requirements

• Protocol version: NFSv4 or later (NFSv4.1/NFSv4.2 recommended). Avoid NFSv3 due to complex multi-port RPC locking and portmapper requirements.
• Network ports: Ensure TCP port 2049 is accessible from all Kubernetes worker nodes to the NFS storage appliance.
• Export options: Configure the NFS server export with rw,sync,no_subtree_check and appropriate root/user squashing policies matching your infrastructure standards.

Permissions and POSIX ownership

Both Graph Studio and Graph Lakehouse run as non-root container users (Graph Studio runs as UID 1001; Graph Lakehouse runs as user anzograph with UID/GID 10001).

To ensure Graph Lakehouse can read files staged by Graph Studio without permission errors:

1. Shared group ID / fsGroup: Configure the shared export with a common POSIX group, or configure Kubernetes fsGroup (e.g., fsGroup: 10001 or a shared storage group) in the pod security context of both workloads so files written to the volume are accessible by both containers.
2. Directory permissions: Initialize the shared directory with mode 0775 (directory) and 0664 (files) so members of the shared group possess read and write access.
3. Consistent mount target: Mount the shared export to the standard mount point /opt/nfs1 across both workloads.

Coordinated Kubernetes volume configuration

Both the Graph Studio custom resource (Anzo) and the Graph Lakehouse custom resource (AnzoGraph) must mount the shared NFS storage using ReadWriteMany (RWX) access modes.

Graph Studio shared volume specification

In the Graph Studio custom resource (Anzo), define the shared volume under spec.volumes:

volumes:
  - name: shared-nfs
    mountPath: "/opt/nfs1"
    pv:
      capacity:
        storage: 100Gi
      accessModes:
        - ReadWriteMany
      storageClassName: ""
      persistentVolumeReclaimPolicy: Retain
      nfs:
        server: "${NFS_SERVER}"
        path: "${NFS_EXPORT_PATH}"
        readOnly: false
    pvc:
      accessModes:
        - ReadWriteMany
      storageClassName: ""
      resources:
        requests:
          storage: 100Gi

Graph Lakehouse shared volume specification

In the Graph Lakehouse custom resource (AnzoGraph), define the corresponding volume and mount under spec.db.volumes and spec.nodeConfig.spec.template.spec.containers[0].volumeMounts:

spec:
  db:
    volumes:
      - name: shared-nfs
        mountPath: "/opt/nfs1"
        deletePVC: false
        pv:
          capacity:
            storage: 100Gi
          accessModes:
            - ReadWriteMany
          persistentVolumeReclaimPolicy: Retain
          storageClassName: ""
          nfs:
            server: "${NFS_SERVER}"
            path: "${NFS_EXPORT_PATH}"
            readOnly: false
        pvc:
          accessModes:
            - ReadWriteMany
          storageClassName: ""
          resources:
            requests:
              storage: 100Gi
  nodeConfig:
    spec:
      template:
        spec:
          containers:
            - name: anzograph-db
              volumeMounts:
                - name: shared-nfs
                  mountPath: "/opt/nfs1"

Shared Data File Store configuration

Graph Studio utilizes a designated Shared Data File Store as the primary storage location for datasets and staged data intended for Graph Lakehouse processing:

• Path alignment: When using NFS, the configured Shared Data File Store path must reference the local mount directory (e.g., /opt/nfs1/shared-data or /opt/nfs1) accessible at the identical path within the Graph Lakehouse container.
• Object store connection: When using S3 or Azure Blob storage, the Shared Data File Store points to the pre-configured File Connection referencing the bucket or container URL.
• Persistence separation: Ensure the Shared Data File Store path never points to application persistence paths or internal database system directories.