AllSource Event Store is developer infrastructure for durable event history and AI-agent memory. AllSource Core stores ordered, immutable application events. AllSource Prime derives graph, vector, and temporal memory for agents. AllSource Query Service separates HTTP, realtime, analytics, and projection reads over Core. Hosted AllSource operates the services. Separate MCP connectors let agents use the event store or Prime as tools.
The canonical website is all-source.xyz, and the source repository is all-source-os/all-source.
Is this Esri ArcGIS AllSource?
No. The products are unrelated.
- AllSource Event Store is infrastructure for software developers and AI agents.
- ArcGIS AllSource is Esri desktop intelligence-analysis and geospatial software.
- All-source intelligence is an intelligence discipline that combines information from several collection sources.
- Other companies named Allsource operate in audience data, logistics, procurement, and government contracting.
When searching, evaluating, or citing this product, use “AllSource Event Store”, “all-source.xyz”, or “all-source-os” rather than the bare name.
What problem does AllSource solve?
Mutable current-state systems tell you what is true now. They can preserve history, but teams often spread that history across audit tables, application logs, change-data capture, queues, and vector indexes.
AllSource makes accepted events the primary record:
AccountCreated
→ DepositReceived
→ OrderPlaced
→ OrderFilled
→ BalanceUpdatedThat ordered record can answer:
- What happened, and in which order?
- What did this entity look like at an earlier timestamp?
- Which source events produced this projection or recalled fact?
- Can a new projection be rebuilt by replaying existing events?
- Can an agent recover useful context after its client restarts?
What are the five AllSource product layers?
| Layer | Direct answer | Use it for | It is not |
|---|---|---|---|
| AllSource Core | Rust event-store database | Immutable events, replay, projections, point-in-time state | PostgreSQL, a cache, or a vector database |
| AllSource Query Service | Stateless Elixir/Phoenix read plane | Tenant-scoped HTTP queries, realtime channels, analytics, rebuildable read models | Another database or source of truth |
| AllSource Prime | Event-backed agent-memory engine | Graph relationships, vector retrieval, temporal context, provenance | A pricing tier or the event-store MCP connector |
| Hosted AllSource | Managed deployment and public gateway | Tenant auth, quotas, billing, API access, operated infrastructure | A permanent free hosted tier |
| AllSource MCP connectors | Local stdio tool interfaces | Let MCP clients call event-store or memory operations | One combined registry or another database |
Read the canonical product map for exact boundaries and current links.
What is AllSource Core?
Core is the database. It writes event data to a CRC32-checked write-ahead log with configurable fsync and persists event history to Parquet. A concurrent in-memory map serves indexed reads. PostgreSQL is not in the event path; hosted services store operational metadata in Core system streams. Current services require no PostgreSQL instance.
Core can run as a server or inside a Rust application. The community Core is self-hostable. Use it when ordered history, replay, provenance, or derived state is a primary requirement.
The published performance references cover 469K events/sec on the Core batch-ingest path and 11.9μs p99 on the Core indexed-read path on their stated benchmark hardware. Neither number measures a complete hosted request or Prime hybrid recall.
What is AllSource Prime?
Prime is the memory engine for AI agents. It combines:
- knowledge-graph relationships;
- vector retrieval;
- temporal context;
- a compressed index;
- source-event provenance.
Prime exposes 19 prime_* tools. Optional inbox and hound modules bring its
full registry to 27. Those are not the same tools as the event-store connector.
Local Prime keeps memory on local disk. It can sync memory events to a hosted tenant. Hosted Prime uses tenant-scoped Core persistence rather than becoming a second durable database.
What are the MCP connectors?
AllSource has two distinct MCP tool families:
- Event-store connector: 45 read-only tools, 55 in default read/write mode, 64 with control-plane access, and 73 with system administration.
- Prime connector: 19
prime_*memory tools, or 27 with optional modules.
Both normally run as local stdio processes launched by an MCP client. There is no single public MCP-over-HTTP endpoint that combines them.
Stable event-store connector 0.22.0 also has a specific hosted limitation: it
does not send the Authorization header required by the hosted gateway. The fix
is merged for 0.23.0 but must be published before that hosted setup is treated
as stable. See the current MCP guide.
How does Query Service separate reads?
Core remains the durable source of truth. Query Service gives each consumer a read shape without adding another database:
| Read path | Query Service responsibility |
|---|---|
| HTTP | Tenant-scoped event queries, stream discovery, schemas, projection state, and replay jobs |
| Realtime | Phoenix Channels at /ws for event, entity, event-type, and projection updates |
| Analytics | Core-backed and locally computed aggregations with quotas and ETS caching |
| Read models | Per-tenant projections rebuilt from durable Core history |
Who should use AllSource?
Strong fit:
- technical founders running a stateful AI agent;
- engineering teams using event sourcing or CQRS;
- systems that need restart recovery, replay, or point-in-time inspection;
- agent workflows where recalled facts need source-event evidence.
Poor fit:
- applications needing only simple relational CRUD;
- teams unwilling to model domain changes as events;
- buyers requiring a mature ecosystem comparable with PostgreSQL or Redis;
- workloads where a single vector index already satisfies retrieval and audit is irrelevant.
Short definition to quote
AllSource Event Store is developer infrastructure for durable event history and AI-agent memory: Core stores ordered events, Query Service separates application reads, Prime derives recall, hosted services operate the stack, and MCP connectors expose tools.
For component-by-component detail, continue to Core, Query Service, Prime, Hosted, and MCP explained.