connects_to is a write-only table - drop it, or finish the graph? (and a coupled schema/parser fix)

[RobertSigmundsson]

Hi Toni! 👋

Big news first: we're adopting surreal-memory as the production memory engine of Uruboros - our multi-agent swarm orchestration system. The design you landed on - graph + vector neural memory on SurrealDB - is genuinely what made the call easy: it's the right substrate for shared memory across a swarm, and we'd much rather build on what you've built than reinvent it. The migration only confirmed the instinct - our old neural-memory fork shrank to almost nothing on top of 2.3.2, which says a lot about the shape of your codebase. In our deployment the engine now backs a live multi-agent setup on a shared SurrealDB, semantic recall went from 0/10 → 10/10 on our regression set after the migration, and batch re-embedding runs clean (21/21). So this comes from running it for real, not just reading it.

While migrating we did a close review of main and hit one thing that's genuinely your call to make - plus a couple of related inconsistencies in the synapse area that turn out to be coupled to it. We'd love your steer, and we're happy to do the work either way.

TL;DR

• The connects_to edge table is written and deleted, but never read - every add_synapse pays an extra DB round-trip for a table no query traverses.
• The synapse indexes are on out/in, but the write path fills source_id/target_id - so synapse lookups are unindexed full scans.
• synapse is SCHEMAFULL but doesn't declare source_id/target_id (the fields it writes). It only works because a parser bug means the SCHEMAFULL definition never runs - two bugs cancelling each other out. Fixing either in isolation breaks synapse persistence.
• So this isn't just cleanup - it's a small design decision (A: tidy the document model, or B: make the graph real) that needs to land with a coupled schema+parser fix.

1. connects_to is write-only - RELATE neuron:$src -> connects_to -> neuron:$tgt (store.py:655), cleaned up on delete (store.py:569), schema comment "for graph traversal" (schema.py:71-73). But no ->connects_to-> traversal anywhere in src/ - grep returns zero.

2. Synapse reads unindexed - reads go WHERE source_id/target_id (store.py:690-693), but indexes are on (brain_id, out)/(brain_id, in) (schema.py:68-69) - fields only connects_to populates. Full scans, per-neuron on hot paths.

3. Two bugs cancelling out - synapse is SCHEMAFULL (schema.py:57) but source_id/target_id (store.py:642-643) aren't declared → should be stripped, making DELETE synapse WHERE source_id… (store.py:563) match nothing. It works only because the ensure_schema parser never runs the SCHEMAFULL statement (splits on ;, drops comment-prefixed fragments) → table is effectively SCHEMALESS. Naively fixing the parser would activate the stripping. Hence: one coupled change, not two.

The decision - A or B?

• A - tidy the document model: drop connects_to (4 sites), declare source_id/target_id, fix the two indexes. One fewer write + indexed lookups. We can send this PR.
• B - make the graph real: synapse as TYPE RELATION, traversed ->synapse->. Bigger change. We'd gladly help spec and build it.

Our bias (Uruboros pushes the graph to swarm scale): A now, B as a follow-up. But it's your engine - which way?

Heads-up: a batch of small, independent, backward-compatible bugfix PRs is also coming (SDK pin, tolerant neuron-type parsing, embed_batch N→1 under google-genai ≥2.0, nine literal {{}} DEFAULTs, direction='forward' outside enum, + get_synapses(limit) / GeminiEmbedding base_url). We'll open them individually so they're easy to review. 🙂

Thanks for building this, Toni - it's a pleasure to run. Let us know on A vs B and we'll start sending patches.

[RobertSigmundsson]

Update from the Uruboros side - we made the call and shipped it.

We went with option A (tidy the document model). On our fork:

• connects_to is dropped. Worth flagging: it was not just write-only, it never worked at all. RELATE neuron:$src -> connects_to -> ... does not parse (a parameter in the record-id position) and the call is in a try/except, so every synapse insert silently failed the RELATE. Our live brain has 0 connects_to rows to show for it.
• source_id / target_id are declared on synapse (the fields the store actually reads and writes; 1609 synapses carry them here).
• the two source/target indexes now point at source_id/target_id instead of out/in (out/in are only populated by a RELATION table, so they indexed nothing and every lookup full-scanned).

PR: #25. Backward compatible, tests green.

One thing we found and deliberately left alone: ensure_schema splits the schema on ; and drops fragments starting with --, so every comment-prefixed DEFINE TABLE ... SCHEMAFULL is dropped and tables run SCHEMALESS. That is the other half of the "two bugs cancelling out" - it is why the undeclared source_id/target_id persisted fine. It is broader than synapse (it is every table), so we did not touch the parser in the option-A PR; flipping it would turn on SCHEMAFULL across ~25 tables at once. Declaring source_id/target_id makes synapse safe either way. Glad to open a separate thread on the global SCHEMAFULL activation if you want to tackle it.

So: visibility, not a request. Adopt the PR, change it, or pass - entirely your call. Option B (synapse as TYPE RELATION, real ->synapse-> traversal) we are leaving as a possible future direction; happy to help build it if you ever want to go there.

While in the codebase we also opened a batch of small, independent bugfix PRs (#16 to #24, plus #26 and #27): SDK pin, the neuron_state activation bug, tolerant type parsing, the literal {{}} defaults, the Direction enum, id doubling, the orphan-prune pinned guard, plus get_synapses(limit) and a Gemini base_url override. Each stands alone; review at your leisure.

[acidkill]

Hi Robert — first, this genuinely made my week. Hearing that surreal-memory holds up as the production memory engine for a live multi-agent swarm, and that your neural-memory fork shrank to almost nothing on top of 2.3.2, is exactly the validation I hoped the design could earn. Thank you for running it for real and for the unusually careful write-up.

Decision: let's go with A. Merge-ready as far as I'm concerned — #25 is the right call: drop the write-only connects_to, declare source_id/target_id, and repoint the indexes at the columns the store actually fills. The fact that connects_to never even parsed (and your live brain has 0 rows to prove it) settles any doubt. I'll take #25.

B (synapse as a real TYPE RELATION with ->synapse-> traversal) I want to keep on the table as a deliberate, separate piece of work rather than fold it in now — A gives us correct, indexed lookups today, and B deserves its own design pass. If/when I pick it up I'll very gladly take you up on the offer to help spec it.

On the ensure_schema parser (;-split dropping every ---prefixed DEFINE TABLE ... SCHEMAFULL, so ~25 tables silently run SCHEMALESS): great catch, and you're right to keep it out of the option-A PR. Please do open the separate thread — it's the more consequential of the two and I'd rather reason about flipping SCHEMAFULL across all tables in one focused place, with eyes on what each table actually persists today.

The standalone bugfix batch (#16–#24, #26, #27) is exactly the right shape — independent, backward-compatible, one concern each. I'm working through them now; #16 in particular is a real one (the whole activation→decay→tiering loop was dormant). Thanks again, Robert.