A lot of infrastructure ideas sound better at the boundary than they do in the runtime.
"Bring your own database" was one of those ideas for us.
At first glance, it looked like the right answer for security-conscious customers: let the customer host Postgres and Neo4j, connect our workers to their environment, and tell a clean data-residency story.
But once we traced the actual execution path of the product, BYODB stopped looking like a compliance feature and started looking like a claim we could not make honestly.
The attractive version of BYODB
The pitch writes itself:
- your data stays in your environment
- you keep control of the database
- we operate only the application logic
- compliance review gets easier
For buyers, that sounds like a strong isolation model.
For a memory system powered by LLM extraction and adjudication, it is not.
The honesty problem
The core issue is simple: the database is not the only boundary that matters.
Our workers still have to read customer data, construct prompts, and send content to an LLM provider in order to do useful work.
flowchart LR
DB[(Customer-hosted Postgres / Neo4j)] --> W[Accord Book worker]
W --> P[LLM provider]
P --> W
W --> DB
That means a claim like "your data never leaves your boundary" stops being true the moment extraction, retrieval enrichment, or conflict adjudication runs.
The more honest statement is narrower:
| Claim | Can we make it? | Why |
|---|---|---|
| "Your primary data store is under your control" | sometimes | true in a BYODB setup |
| "Your data never leaves your boundary" | no | worker-to-provider traffic breaks it |
| "We do not retain your content outside the managed environment" | yes, with the right design | this is operationally enforceable |
| "You can leave with your data" | yes | exportability is implementable |
That distinction matters. Senior buyers eventually notice when a compliance posture depends on a boundary that the runtime itself crosses every day.
The operational burden was worse than the benefit
Even if we ignored the honesty problem, BYODB was still a bad fit for the stage of the product.
Supporting arbitrary customer-owned database environments means inheriting all of this variability:
- different Postgres versions and extension policies
- different Neo4j tuning and memory profiles
- private networking and firewall edge cases
- backup policies we do not control
- schema migration risk across unknown environments
- latency and throughput variance between worker and database
In other words, the product surface becomes partially standardized while the operational surface becomes unbounded.
That is survivable for a very large platform team. It is not a good trade for a small company still trying to validate the product.
The hidden trap: you do the hard part anyway
BYODB often sounds like it reduces provider responsibility.
In practice, for a system like this, the most failure-prone components are still ours:
- extraction pipelines
- queue orchestration
- graph synchronization
- retrieval tuning
- conflict-detection logic
- prompt shaping and evaluation
So the customer hosts the databases, but we still own the behavior everyone cares about when the system breaks.
That combination is awkward: we inherit support complexity without actually reducing accountability.
The alternative we chose
We moved from isolation language to portability language.
That changed the product posture in three ways.
1. Managed environment, customer-controlled provider accounts
The active model is:
- customer data at rest in our managed deployment
- encryption and backup discipline on that deployment
- LLM and embedding calls made with the customer's provider credentials
- no need to promise a boundary the runtime does not preserve
That is a more constrained claim, but it is a more defensible one.
2. Real offboarding instead of symbolic isolation
Instead of BYODB, we committed to a serious export path.
A useful export is not just a SQL dump. It needs enough structure to preserve continuity:
| Artifact | Why it matters |
|---|---|
| scoped Postgres dump | canonical project data |
| Neo4j export or subgraph package | relationship layer when graph is enabled |
| uploaded blobs | source documents are part of the evidence chain |
manifest.json |
lets the export describe version and contents |
That is a portability feature customers can actually use.
3. Dedicated deployments for the customers who really need separation
Some customers genuinely do need stronger operational isolation.
For that case, the better answer is not BYODB. It is a dedicated stack we still operate.
That avoids the worst support explosion while still giving the customer a much stronger residency and segregation story than a shared environment.
Why portability is a better engineering contract
There is a broader lesson here.
A good platform contract should line up with the actual runtime path of data.
BYODB optimized for where bytes are stored. The product's real risk envelope included where bytes are processed, how jobs are executed, where prompts are sent, who operates migrations, and how support happens under failure.
Once you include those parts, portability is the cleaner contract:
- it is honest about provider calls
- it is compatible with BYOK models
- it gives the customer an exit path
- it keeps operations inside a system we can actually standardize
A useful test for future architecture claims
When a deployment model sounds attractive, ask two questions:
- What exact sentence does this let us say to customers?
- Is that sentence still true when the asynchronous jobs run?
BYODB failed the second test.
That does not make it universally wrong. It just made it wrong for this product, at this stage, with this runtime.
And in infrastructure decisions, that is usually the level that matters.