What is an Evolutionary Neural Memory?

An Evolutionary Neural Memory (ENM) is a specific type of Actor in Pod-OS. It is a share-nothing, bidirectional graph database with some important properties that set it apart from traditional databases.

All Types in One Place

Your advanced solutions, AIs, and next-generation data ecosystems need three types of data in one place:

mathematical description, for example such as vectors, tensors, etc.
facts and relationships
temporal information at up to microsecond level to build context

ENM as an Actor

Because an ENM is an Actor, it follows all the rules of the Actor Model:

It has its own private state (your data)
It communicates exclusively through messages (queries and mutations)
It processes one message at a time (no read/write conflicts)
It can live anywhere in the network (location transparency)

You interact with an ENM the same way you interact with any Actor — by sending it messages and receiving responses. There is no special database driver, no connection pool, no SQL dialect. Messages in, messages out.

Bidirectional Graph

At its core, an ENM stores data as a bidirectional graph. This means:

Data is represented as nodes and edges
Every edge is bidirectional — if A connects to B, then B automatically connects back to A; each direction can have different weights.
You can traverse the graph in any direction with equal efficiency

This bidirectionality is not just syntactic sugar. In a traditional graph database, you might create an edge from A to B and then separately create a reverse edge from B to A to enable traversal in both directions. In ENM, bidirectionality is intrinsic. When you create a relationship, both directions are immediately available.

Why Bidirectionality Matters

Consider a knowledge graph where "Alice" works-at "Acme Corp." In a traditional system, querying "who works at Acme Corp?" requires either:

An explicit reverse index
A full scan looking for edges pointing to Acme Corp
A separate reverse edge created by application code

In ENM, the reverse traversal — from Acme Corp back to Alice — is automatic and costs the same as the forward traversal. This makes exploratory queries, recommendations, and impact analysis natural operations rather than expensive afterthoughts.

Share-Nothing

Each ENM instance owns its data exclusively. There is no shared storage layer, no distributed lock manager, no consensus protocol for reads. This gives you:

Predictable performance — no contention from other databases or actors
Strong isolation — a problem in one ENM cannot corrupt another
Simple operations — backup, restore, and migration operate on a single self-contained unit

When you need data from multiple ENMs, you use the actor network to send messages between them, exactly as you would coordinate any other Actors.

Evolutionary

The "Evolutionary" in Evolutionary Neural Memory refers to how the database handles schema and structure changes:

No rigid schema — you do not define tables or columns up front
Additive by nature — new node types, edge types, and properties can be introduced at any time without migrations
Tags automatically version — updates to Tags always, and efficiently, retain previous values retrievable by time
Structure emerges from data — the shape of your graph evolves as you add information
Backward compatible — old data remains valid and queryable even as the graph structure grows

This is particularly powerful for applications where requirements change frequently, where data comes from multiple sources with different structures, where you are exploring a domain and do not yet know the final shape of your data, or where the shape of your data needs to continuously evolve.

Key Properties Summary

Property	What It Means
Actor	Isolated, message-driven, location-transparent
Bidirectional graph	Every relationship traversable in both directions, automatically
Share-nothing	Each ENM owns its data; no shared state
Evolutionary	Schema-free, additive, backward compatible
Neural	Connective structure supports associative queries and pattern traversal
Computational Search	Execute programmable searches in ENM without needing client-side processing
2 GB Payload per Event	Each Event Object holds any object up to 2GB (versioning is a future feature).
Marginal reducing storage volume	The more you store, the less space each next storage needs.
No Deletion	A key behavior, required for contextual understanding, is that no Event Object is ever deleted so that the full history is always retrievable. Events, can be 'forgotten' so that they are clearly marked while still retrievable. Natural concerns of continuously growing storage space is managed with the point above in combination with sharding and replication strategies.

When to Use an ENM

ENMs are very flexible; some example use cases:

Knowledge graphs — dense entities and their relationships for enterprise search
User profiles and social graphs — people, preferences, and connections
IoT data fabrics — devices, readings, and relationships between sensors
Content and catalog systems — products, categories, attributes, and recommendations
Sciences & Finance — tracking what happened, when, and why, with full traceability
AI training and inference — AIs perform dramatically better with dense contextual memories

If your AI systems are limited by poor-quality, flat data — particularly data with meaningful relationships and entities that evolve over time — an ENM is likely the right choice.

Next: How do I deploy an ENM? — walk through deploying your first Evolutionary Neural Memory through the Pod-OS dashboard.