You asked the architecture question. Here is the follow-up.
Part 1 was about a question worth asking your vendor: where does one customer's data end and another's begin? If you have asked it and the answer came back "each customer gets their own database," this post is about what to do with that answer.
Because it is a good answer. It is also not the end of the conversation, and the gap between those two things is where buyers get caught.
I have watched this play out on both sides of the table. A vendor gives a genuinely strong architectural answer, the evaluation team marks the isolation question closed, and nobody returns to it — until a supplier audit asks how backups are scoped and the room goes quiet. The architecture was never the weak part. The operations around it were, and nobody had asked.
What separation buys you
Start with the failure it removes, because it is a real one.
In a shared database, every query that touches customer data has to say which customer it is for. Thousands of queries, written over years by people who have since left. Miss the filter on one of them and that query returns rows belonging to someone else. It is not exotic — it is the most common way tenant boundaries fail, and it fails silently, because a query with too many rows looks exactly like a query with the right rows unless someone is counting.
Give each tenant its own database and that class of mistake stops being possible. Not "unlikely" — the rows are not there to return. The connection is scoped before the query runs.
For a quality team, that is worth understanding in plain terms: you are removing a category of error that depends on every developer getting every query right, forever. Architecture that removes a failure mode is stronger than process that catches it.
| Shared database, filtered by application | Database per tenant | |
|---|---|---|
| A query missing its tenant filter | Can return another tenant's rows | Cannot — those rows are elsewhere |
| Proving separation to an auditor | Requires code review of every access path | Shown at the connection, not the query |
| Restoring one customer's data | Surgical extract from a shared store | Restore that tenant's own database |
| What still needs a procedure | Everything below | Everything below |
That last row is the point of this post.
The three things it does not fix
Separation at the database is a boundary. Every operation that has to cross that boundary is where the risk moved to, and there are three that always do.
Backups. Your records get backed up. The question is what the unit of backup is. If a tenant can be restored on their own, the boundary held. If the restore path pulls from a store that spans customers, the boundary you were shown in the architecture diagram is not the boundary that operates at three in the morning when something has gone wrong.
This one has a second edge that buyers miss. A restore is not only a technical event — it is a change to regulated records, and your quality system has to account for it. If a vendor restores you to a point two hours earlier, what happened to the audit trail entries written in those two hours? Were they restored with the records, lost, or kept? Each answer has a different consequence for a data-integrity review, and "we have backups" does not tell you which one you are buying.
Support access. Someone at the vendor can read your records — that is how support works. Database-per-tenant does not change that, it only changes which connection they open. What matters is who is allowed, what approval it needs, and whether that access is itself recorded somewhere you can see.
Be specific when you ask. "Access is restricted" is not an answer; "access requires a named approver, is time-limited, and writes an entry we can show you" is. The difference matters because supplier audits increasingly ask about it, and because an access path nobody records is indistinguishable from an access path nobody controls.
Exports and reporting. Data leaves the database to become a report, a dashboard, a file you asked for. Each of those is a copy, and copies land somewhere. Ask where.
None of these are arguments against database-per-tenant. They are the reason it is a starting point rather than a conclusion.
Where the audit trail sits in all this
Here is the part that catches people, and it is worth asking as its own question rather than assuming it follows.
Your records being separated does not automatically mean the trail of those records is separated. Systems commonly keep customer data carefully partitioned and then write events, logs and analytics somewhere central, because that is convenient for the people operating the system. If your audit trail is one of those things, then the trail describing your regulated records is living somewhere other than your records.
So ask directly: where is the audit trail written, does it sit inside our own database, and what happens to it when data is exported or a system is restored?
The reason this matters more than it sounds is what the trail is for. Under Part 11 and under every data-integrity expectation that followed it, the trail is what lets someone reconstruct who did what and when. If the trail is somewhere the record is not, then producing it on request becomes an operational exercise, and operational exercises fail under pressure.
There is a second question behind it, and it is the one I would push hardest on: what protects the trail from being changed? Separation answers who can reach it. It does not answer whether an entry, once written, can be edited or removed by someone with sufficient privilege inside the system. Those are different guarantees, and a vendor can have the first without the second.
Ask how that protection is implemented — in the application, or at the database. It is a fair question and the answer is checkable. A control that lives in application code is only as durable as the next change to that code; a constraint enforced by the database holds regardless of what the application asks it to do.
Part 11 does not have an opinion about your vendor's architecture
This is the reframe I would want a quality lead to leave with.
Part 11 was finalised in 1997. It does not mention tenants, databases or cloud hosting, and no amount of architecture gets you compliance on its own. What it asks is narrower and harder: that electronic records are attributable, that the trail is retained and available for review, and that signatures mean what they say they mean.
Database-per-tenant helps you meet that — it makes a whole class of contamination structurally impossible, which makes everything downstream easier to defend. But an inspector will not ask for your vendor's schema. They will ask you to produce the trail for a specific record, and then they will read it.
So the question to take into a vendor conversation is not "which architecture do you use?" It is "show me what happens to my audit trail when you back it up, restore it, export it, and when your support team opens a ticket."
Where this lands in your own quality system
One thing worth saying plainly, because it is the part buyers most often leave until after signature: whatever your vendor's architecture is, the obligation stays with you.
Supplier qualification is where this gets recorded. The architecture answer belongs in your assessment of the vendor, the operational answers belong in the agreement, and the periodic review is where you check that what was true at purchase is still true two years later. Vendors re-platform. Hosting moves. The company that sold you a single-tenant database can be acquired by one that consolidates.
So treat the answers as dated evidence rather than settled fact. Write down what you were told, by whom, and when — and put a review date on it. If a later change makes one of those answers false, you want that to surface in your own periodic review rather than in an inspector's question.
That is also the honest reason to ask for procedures rather than diagrams: a procedure can be re-verified. A diagram tends to get filed and forgotten.
What to ask before you sign
Four questions, and all four have answers you can put in a contract.
- What is the unit of backup and restore? Specifically: can one customer be restored without touching another, and has that been tested rather than designed?
- Where is the audit trail written? In the tenant's own database, or somewhere central? What leaves that store, and when?
- Who at the vendor can read our records, and is that access recorded? Not whether it is possible — it is. Whether it is controlled and visible.
- What do we get if we ask for our full audit trail? A file, a report, an extract? In what format, in what timeframe, and has anyone done it before?
Ask them in writing and keep the answers. A vendor who has thought about this will answer quickly; a vendor who has not will send you an architecture diagram.
If you want those four questions sitting inside a larger frame, our 21 CFR Part 11 RFP scorecard is the version we hand buyers: sixteen control areas, each with the question to put to the vendor, the artifact to demand as proof, and Pass / Partial / Fail columns so three vendors can be compared on the same page. Part 1 pointed at it for the isolation questions. Use the same sheet here for the operational ones — the value is that the answers end up written down, next to each other, before anyone signs anything.
How Complere draws the tenant boundary
Each tenant has their own database. Your records live in a database provisioned for you, not in a shared store filtered by application code.
The audit trail is immutable — database-enforced. Audit records cannot be modified or deleted, enforced by database-level constraints rather than by application rules that a future change could weaken.
The questions above are ones we expect to be asked. Backup scope, support access, what an export contains — those are procedural answers, and we would rather give them in writing during an evaluation than have them discovered afterwards.
Your team owns the judgement about whether an architecture suits your risk profile. What the software owes you is a record that holds still, and a straight answer about what happens to it.
