Load Data

The gRPC examples require the downloadable API definitions and SHRIKEDB_API_DIR setup. ShrikeDB can load data through direct gRPC calls, transactions, or application code. For a first integration, start with the small gRPC examples below and use a generated client for sustained ingestion. These examples require Bash, grpcurl, jq, and base64, plus a disposable database. Create schema ID 1 using the CreateSchema pattern in Your first multimodal dataset before running the writes.

For a guided dataset-plus-ontology workflow over REST, MCP, and CLI, see Onboard A Dataset And Ontology.

Loading Strategy

small demo
  -> grpcurl commands

application integration
  -> generated gRPC client

mixed graph/vector/KV write
  -> transaction APIs

larger imports
  -> batch API client or reviewed file-import mapping

Load KV Records

Use KV for the document body or record payload.

VALUE_B64="$(printf '{"name":"Alice","kind":"User"}' | base64 -w0)"

grpcurl -plaintext \
  -import-path "$SHRIKEDB_API_DIR" -proto shrikedb.v2.proto \
  -d "{
    \"subjectId\": {\"id\":0},
    \"schemaId\": 1,
    \"key\": {\"id\":1001},
    \"value\": \"${VALUE_B64}\"
  }" \
  127.0.0.1:50251 shrikedb.v2.ShrikeDbService/PutKeyValue

Batch KV writes use BulkPutKeyValue.

Load Vectors

grpcurl -plaintext \
  -import-path "$SHRIKEDB_API_DIR" -proto shrikedb.v2.proto \
  -d '{
    "indexName": "users_behavior_vec",
    "schemaId": 1,
    "vectors": [
      {"entityId":{"id":1001},"vector":[0.1,0.2,0.3]},
      {"entityId":{"id":1002},"vector":[0.2,0.1,0.4]}
    ]
  }' \
  127.0.0.1:50251 shrikedb.v2.ShrikeDbService/BulkInsertVectors

Keep all vectors in one index at the same dimensionality. Use different index names for different embedding spaces.

Load Graph Edges

For user-friendly graph edge writes, use transactions:

TXN_ID="$(
  grpcurl -plaintext \
  -import-path "$SHRIKEDB_API_DIR" -proto shrikedb.v2.proto \
    -d '{"subjectId":{"id":0}}' \
    127.0.0.1:50251 shrikedb.v2.ShrikeDbService/BeginTransaction |
  jq -r '.transactionId.id'
)"

grpcurl -plaintext \
  -import-path "$SHRIKEDB_API_DIR" -proto shrikedb.v2.proto \
  -d "{
    \"transactionId\": {\"id\":\"${TXN_ID}\"},
    \"subject\": {\"id\":1001},
    \"predicate\": \"FOLLOWS\",
    \"object\": {\"id\":1002}
  }" \
  127.0.0.1:50251 shrikedb.v2.ShrikeDbService/TransactionInsertGraphEdge

grpcurl -plaintext \
  -import-path "$SHRIKEDB_API_DIR" -proto shrikedb.v2.proto \
  -d "{\"transactionId\":{\"id\":\"${TXN_ID}\"}}" \
  127.0.0.1:50251 shrikedb.v2.ShrikeDbService/CommitTransaction

Bulk graph block APIs exist for high-throughput loaders, but transaction graph edges are easier for first integrations.

Load In One Transaction

Use one transaction when KV, graph, and vector writes must commit together.

BeginTransaction
  -> TransactionInsertKV
  -> TransactionInsertVector
  -> TransactionInsertGraphEdge
  -> CommitTransaction

Check What Loaded

KV namespace report:

curl http://127.0.0.1:8182/api/v1/admin/kv/namespaces

Vector namespace report:

curl http://127.0.0.1:8182/api/v1/admin/vector/namespaces

Graph scan:

grpcurl -plaintext \
  -import-path "$SHRIKEDB_API_DIR" -proto shrikedb.v2.proto \
  -d '{"subject":"uid:1001","predicate":"FOLLOWS","object":"?other","limit":10}' \
  127.0.0.1:50251 shrikedb.v2.ShrikeDbService/GraphScan

Practical Data Modeling Tips

  • Keep one UID per real-world entity.

  • Store large documents in KV, not graph properties.

  • Store embeddings in vector indexes named by embedding model or use case.

  • Use graph edges for relationships, provenance, and explainability.

  • Use batch APIs when writing many records.

  • Use transactions for consistency across modalities.