Skip to main content
Gravix Memory is a lightweight, serverless memory layer built on top of Gravix’s vector index backend. It provides a small, durable store for short application state that benefits from semantic search.

​
Purpose

Provide fast, semantic persistence for short-lived application state such as user preferences, conversation context, and extracted facts. Use cases include:
  • Personalization: retrieve preferences to tailor responses.
  • Conversational context: preserve chat snippets so LLMs maintain continuity.
  • RAG (retrieval-augmented generation): augment prompts with relevant facts from memory.

​
How it works

Memories are compact data items (text, messages, or small JSON objects with metadata). The system:
  • computes embeddings for each memory using an embedding model,
  • stores embeddings in a vector index for semantic search, and
  • exposes simple per-operation APIs: add, search, list, update, delete. Callers may override index, model, or cloud settings per request.

​
Default vs Custom Configuration

Default Configuration (Recommended for most users):
  • Embedding Model: baai/bge-large-en-v1.5 - Best accuracy for English
  • Index: gravixlayer_memories - General purpose storage
  • Cloud Provider: AWS (us-east-1) - Fastest setup
  • Usage: Just create Memory(client) and start using it
Custom Configuration (When you need specific features):
  • Different embedding model - For multilingual support or faster processing
  • Custom index name - To organize memories by purpose (e.g., “user_preferences”, “chat_history”)
  • Inference Model - AI that extracts memories from conversations
  • Specific cloud provider/region - For compliance or performance reasons
  • Usage: Specify parameters when creating Memory instance
Example supported embedding models: baai/bge-large-en-v1.5, microsoft/multilingual-e5-large, nomic-ai/nomic-embed-text-v1.5.

​
Best practices

  • Keep memories short and focused (a few sentences). Store large objects externally and reference them via metadata.
  • Use metadata (timestamps, user_id, tags) to scope and filter searches.
  • Monitor index size and embedding costs; for high scale consider sharding, per-user indexes, or tiered retention.

​
Quickstart

  • Python - Gravix SDK
  • JavaScript - Gravix SDK
from gravixlayer import GravixLayer

client = GravixLayer()
memory = client.memory

# Add a memory
result = memory.add("I love pizza", user_id="alice")
print(f"Added: {result['results'][0]['memory']}")

# Search for it
results = memory.search("food", user_id="alice")
print(f"Found: {results['results'][0]['memory']}")

# Get all memories
all_memories = memory.get_all(user_id="alice")
print(f"Total: {len(all_memories['results'])}")

​
Notes

  • Use environment variables for production API keys (do not commit keys).
  • Keep memories short; store large objects externally and reference via metadata.
What you’ll find in this section If you want, I can add a single runnable example (small script) to the overview that demonstrates add → search and prints results.
⌘I