Memory types
Four ways to run a Chordian memory, what each one buys you, and how to choose.
The same memory runs in four postures. The application code is identical in all four — only the connection bundle it is handed differs — so a feature that ships to the hosted service is available to a customer running a box in their own data centre in the same release.
What changes between them is where your knowledge physically sits, and that is usually the question a security review actually cares about.
Gold marks the machine you own. Scanning the four diagrams below, the distinction is visible before you read a word.
1. Shared memory
LiveThe SaaS tier. Many organisations share one set of engines, separated by a scope applied to every single query.
Runs onChordian infrastructureOne managed stack, shared across tenants.
IsolationlogicalA tenant scope on every read and write, produced by fail-closed helpers and verified in CI on every pull request.
Your contenton ChordianStored in the shared engines, scoped to you.
Time to runninginstantAlready provisioned when you sign up.
Why organisations choose it
Nothing to operate. No cluster, no upgrade window, no capacity planning. Chordian runs it and you consume an API.
Lowest cost per unit of knowledge. Shared infrastructure means shared cost. For most teams this is the difference between "we can put everything in" and "we'll be selective", and selective memories answer badly.
Zero migration risk later. The integration surface is identical across all four types. Starting shared does not lock you out of anything — moving later is an infrastructure decision, not a rewrite.
The honest trade-off
Isolation here is logical, not physical. It is enforced on every query and proven in CI, but it is enforced in software. If your threat model requires that no vendor bug could ever expose your data, that is a real reason to choose one of the types below — and a better reason than a general unease about SaaS.
2. Dedicated memory
LiveYour own engines, in your own namespace, still operated by Chordian.
Runs onChordian infrastructureA namespace of your own, with its own vector, graph, cache and object stores.
IsolationphysicalSeparate engines, with network policy preventing traffic from anywhere else.
Your contenton ChordianIn your engines, on our infrastructure.
Time to runningminutesProvisioned on request, with live progress.
Why organisations choose it
Physical separation without operational burden. The isolation argument becomes structural — different databases, not different rows — while Chordian still handles upgrades, monitoring and backups of the platform.
Predictable performance. No noisy neighbour. A large ingest by another customer cannot affect your query latency, which matters once a memory is behind a user-facing feature.
An easier security review. "Our data is in a dedicated database with network policy around it" ends a conversation that "we share infrastructure with strong scoping" often does not — even when both are true.
The honest trade-off
Your content is still on Chordian's infrastructure. If the requirement is that the vendor cannot read it, dedicated does not deliver that; it reduces blast radius, not vendor access. The next two types are the ones that change that answer.
3. Own server (BYOI)
ValidatedThe memory engine runs on a Linux server you own. Chordian orchestrates it and never stores your knowledge.
Runs onyour serverOn-premise or your own data centre.
Isolationphysical, off-premisesNot merely a separate database — a machine outside Chordian's estate.
Your contenton your boxDocuments, embeddings, graph, files and usage. Chordian stores none of it.
TransportWireGuard + mutual TLSEncrypted tunnel, plus certificates proving both ends on every request.
Time to runninga guided installThirteen resumable steps over SSH, with live progress. Air-gap capable.
Why organisations choose it
"Where does our data live?" gets a physical answer. Not a region setting or a contractual promise — a machine you can point at. Data residency stops being configuration and becomes geography.
A vendor breach exposes nothing. Chordian holds no content, no SSH keys and no box encryption key. Install credentials are held only for the install window and purged on success; the box's own key is generated on the box and never transmitted. There is nothing on our side to steal that unlocks your memory.
A subpoena to the vendor produces nothing. We cannot hand over content we do not have.
Compliance becomes structural rather than procedural. Residency, data minimisation and processor scope follow from the shape of the deployment instead of from a policy document someone has to maintain.
It still feels like SaaS. You get managed orchestration, updates and monitoring without operating the stack yourself — the combination that neither "private SaaS" nor self-hosted open source offers.
The honest trade-off
Backup is currently your responsibility. A built-in backup and restore flow is not shipped. If you run a box, plan for this explicitly — it is the single most important thing to know before choosing this type.
Connector credentials stay platform-side. OAuth redirects inherently complete on the platform, so connector tokens are held there, envelope-encrypted with a key we manage separately. Everything you actually put into memory is on your box. Moving these to the box is planned, not done.
4. Own cloud (BYOI)
AWS · DO GCP · AzureThe same sovereignty, provisioned into your own cloud account.
Runs onyour cloud accountAWS, DigitalOcean, GCP or Azure — billed to you, inside your organisation.
Isolationphysical, your accountYour VPC, your cluster, your storage.
Your contenton your infrastructureSame guarantee as own-server.
Transportpeering, else tunnelNative VPC peering where co-located with Chordian, otherwise WireGuard — both with mutual TLS on top.
Why organisations choose it
Sovereignty without a data centre. Everything own-server gives you, with no hardware to buy, rack or replace.
It lands inside your existing cloud governance. The cluster appears in your account, under your tagging, your budgets, your security tooling and your existing cloud agreement. For an organisation with a mature cloud practice this is often less work to approve than a new SaaS vendor.
Your region, your choice. Residency follows the region you provision into.
Lower per-operation cost. Because you already pay your own cloud bill, own-infrastructure memories carry a rate multiplier below 1.0 — every metered operation costs fewer credits than the same operation on Chordian infrastructure. Charging the hosted rate on top would be charging twice for the same compute.
The honest trade-off
AWS and DigitalOcean are real and live-validated. GCP and Azure run behind a validated seam and are pending their first sandbox provision — available on request, not yet self-serve-proven. The same backup and connector-credential caveats as own-server apply.
Choosing
| Shared | Dedicated | Own server | Own cloud | |
|---|---|---|---|---|
| Content on Chordian | Yes | Yes | No | No |
| Isolation | Logical | Physical | Physical, off-premises | Physical, your account |
| You operate infrastructure | No | No | The host | The account |
| Vendor can read content | Yes | Yes | No | No |
| Survives a vendor breach | ✗ | ✗ | ✓ | ✓ |
| Residency guarantee | Region | Region | Physical | Your region |
| Per-operation cost | Standard | Standard | Reduced | Reduced |
| Backup included | Yes | Yes | Not yet | Not yet |
A short decision path:
Start shared unless something forces otherwise
It costs least, needs no decisions, and the integration surface is identical to every other type. You are not painting yourself into a corner.
Move to dedicated for noisy-neighbour or blast-radius concerns
Separate engines, still operated by us.
Move to own-infrastructure when the answer to "where does our data live" must be "here"
Own server if you have a data centre and a preference for on-premise; own cloud if you would rather it sat in an account you already govern.
Where the reasoning happens
Storage sovereignty and processing sovereignty are different guarantees, and conflating them is the most common way this conversation goes wrong.
| Mode | Where inference runs | Does content leave the box? |
|---|---|---|
| Chordian proxy (default) | Chordian's proxy, over the tunnel only | Yes — it transits Chordian to reach the model vendor |
| Bring your own | Your own endpoint or key | No — only to the provider you already trust |
| In-box model Roadmap | Inside the box | Never leaves |
A sovereign box with no egress configured fails loud. It refuses to process rather than quietly falling back to a public API — the failure mode that would otherwise turn a sovereignty guarantee into a sovereignty claim.