AllSource vs stoolap
stoolap is an embedded relational SQL database in pure Rust — mutable tables, JOINs, an optimizer, all in your process. AllSource is an immutable, replayable event store and agent-memory service you run over the network or host. They overlap on AI features (vectors, embeddings, time-travel, an MCP server) but solve different problems — pick by data model and deployment, not by a benchmark.
First, the honest part: these are different categories
stoolap is an embedded relational SQL DBMS (SQLite/DuckDB-class) you compile into one app: CREATE TABLE, INSERT, SELECT, mutable rows, JOINs, a cost-based optimizer — with no server mode. AllSource is an append-only event store plus an agent-memory engine (Prime) and a hosted multi-tenant SaaS, served over the network or self-hosted. Both are pure Rust, Apache-2.0, and both ship vectors + HNSW, built-in embeddings, time-travel, and an MCP server — so this is not a feature-checkbox contest. The decision is the data model (mutable SQL tables vs an immutable, replayable log) and the deployment (a zero-ops embedded library vs a shared network service with multi-tenancy and per-call billing).
| Capability | AllSource | stoolap |
|---|---|---|
Category AllSource is an append-only event store, the Prime memory engine, and a hosted SaaS. stoolap is a SQLite/DuckDB-class relational database you compile into one app. | Event store + agent memory | Embedded SQL DBMS |
Core data model The decision that drives everything else: keep an append-only, replayable history and project state from it (AllSource), or run SQL and UPDATE/DELETE rows in place (stoolap). | Immutable event log | Mutable SQL tables |
Query language stoolap is a SQL DBMS front-and-center with a cost-based optimizer. If you want SQL ergonomics over your data, stoolap wins outright. | HTTP/MCP + EventQL (SQL analytics) | Full SQL (JOINs, CTEs, windows) |
Written in Rust Both are pure Rust. stoolap is 99.8% Rust (it migrated from an early Go prototype); AllSource Core is Rust with Go/Elixir services around it. | ||
Embeddable in-process AllSource can embed via `allsource-core` but is built to run as a server. stoolap is embedded-only — there is no standalone server or daemon. | yes (its only mode) | |
Network service / shared backbone You cannot point a fleet of clients at a stoolap instance over the network; it lives in one process. AllSource is designed to be a shared service. | yes (Rust server :3900) | |
Durable (survives restart) Both are durable. stoolap pairs an in-memory MVCC hot buffer + WAL with immutable cold columnar files; AllSource is WAL (CRC32, fsync) + Parquet (Snappy). | WAL + Parquet | WAL + columnar files |
In-memory ingestion (single-thread, 100k) Measured on the same M2 Max laptop, --release. A near-wash — same order of magnitude, ranges overlap with background load. Nobody is 10× faster. (events/sec ≠ rows/sec, but comparable per-record cost.) | ~200K–506K events/sec | ~291K–448K rows/sec |
In-memory point reads Different metrics (p99 vs avg) on different harnesses — do NOT read this as a 20× win. Honest statement: both do point reads in the single-digit-microsecond-or-better range in memory. | 11.9μs p99 (published) | ~0.5–0.9μs avg (measured) |
Durable single-row ingest (fsync) Neither headline number is a pure synchronous-durable single-row rate. The only durable single-row figure measured is stoolap's, with fsync on the WAL. | not isolated here | ~79K–97K rows/sec |
Vector / HNSW search Both ship native vector search with an HNSW index. This is NOT an AllSource-exclusive axis against stoolap. | yes (fastembed + HNSW) | yes (VECTOR(N), HNSW) |
Built-in embeddings (no external API) Both compute embeddings locally with no Python and no external embedding service. | yes (local fastembed) | yes (built-in EMBED()) |
Temporal / time-travel Both offer time-travel. The difference is what it reads: AllSource replays a permanent immutable log; stoolap reads retained MVCC versions (a concurrency mechanism, garbage-collected — not a permanent audit ledger). | as_of projections (replay log) | AS OF TIMESTAMP/TRANSACTION (MVCC) |
Full event provenance / replay AllSource keeps the full immutable history by design; every change is a replayable event. stoolap's MVCC versions are not an audit trail. | yes (first-class) | |
MCP server for AI agents Both ship a first-party MCP server. stoolap's 30 tools are a SQL surface (query, execute, transactions, schema, vacuum); AllSource's are event-store/agent-memory verbs (ingest, recall, projections, anomaly detection). | 43 event/memory tools | 30 SQL tools |
Agent-memory product AllSource ships a dedicated memory engine with its own MCP tools. stoolap gives you a SQL + vector store; assembling agent memory on top is your job. | Prime (graph + vector + recall) | |
Multi-tenancy / RBAC / billing Tenants, RBAC, LemonSqueezy billing, and x402 are built in for AllSource. For a library like stoolap, tenancy and billing are your app's job. | yes (Control Plane) | |
x402 per-call agent payments AllSource ships native x402 micropayments so agents pay per call. stoolap has nothing to price — there is no hosted offering. | ||
License (OSS core) Both are permissive OSS you can self-host for free. stoolap is fully Apache-2.0 with no commercial strings; AllSource's enterprise features are BSL 1.1 (converting to Apache-2.0 in 2029). | Apache-2.0 (enterprise BSL 1.1) | Apache-2.0 |
Maturity stoolap is a young single-author project (latest v0.4.0); an independent review notes it is 'still in its early days.' Both are pre-1.0. | v0.22, org-maintained | v0.4.0, ~1.2k★, 1 author |
Both are Rust and Apache-2.0 (AllSource's enterprise tier is BSL 1.1). stoolap genuinely ships an MCP server (30 SQL tools), native VECTOR/HNSW search, a built-in EMBED() with no external API, and AS OF time-travel — none of those are AllSource-exclusive here. On the only fair head-to-head (single-row in-memory ingest + point reads) the two land in the same order of magnitude; reproduce it with `cargo run --release -p allsource-performance`. stoolap multipliers like 191×/1213× are vendor-reported; an independent Better Stack test measured stoolap's real OLAP edge over SQLite at ~4–6×.
Pick AllSource if…
- You need an immutable, replayable store of record — full event provenance and any past state by replay, as an audit ledger (not a garbage-collected MVCC version)
- The store must be a shared network service for many clients/agents — a Rust server on :3900 with leader-follower replication — not a library trapped in one process
- You want a hosted, multi-tenant SaaS with RBAC, billing, and x402 per-call agent payments out of the box
- You want a purpose-built agent-memory engine (Prime: knowledge graph + vector + recall) rather than assembling memory yourself over SQL
Pick stoolap if…
- You want real SQL — JOINs, CTEs, window functions, a cost-based optimizer — over mutable tables, with no projections to fold
- You want a database embedded in one app with zero ops: no server, no Docker, no network hop — `cargo add stoolap` (or npm/pip) and ship
- You want fast local OLAP (GROUP BY, DISTINCT, aggregations) without standing up DuckDB
- You want vector search + built-in embeddings inside SQL (VECTOR(N), HNSW, EMBED()), broad language reach, and fully-permissive Apache-2.0 with no BSL strings on any feature
AllSource vs stoolap: FAQ
Build on a durable event store
Start on the hosted Indie plan for $19/mo, or self-host the whole stack for free under MIT. Either way you keep full event provenance and microsecond recall.