BLOG
INDEPENDENT VS SHARED DATABASE MODELS: THINK IT THROUGH
A Practical Guide to Choosing the Right Facial Recognition Database Architecture
A Practical Guide to Choosing the Right Facial Recognition Database Architecture
When you buy facial recognition, there's a fundamental architecture question most people never ask: where does my data live, and who else can access it? There are two models: independent (your own database) and shared (a communal database managed by the supplier). This choice has huge implications for your operations, your legal exposure, and your ability to control your own data.
The supplier runs one central database. Every customer's face data goes into the same pot. When a face is detected at your venue, it's compared against the shared pool. The pitch is simple: bigger database equals more matches. The reality is more complicated. Your competitor's data improves your results, but yours improves theirs too. You have limited control over retention, deletion or access. If the supplier is breached, everyone's data is exposed. And here's the uncomfortable truth: your customers' biometric data is being compared against unknown third parties' watchlists without their knowledge or consent.
You have your own database. Only faces you've enrolled are in it. Only your team can access it. You set the retention rules, you control deletion, and your data is never mixed with anyone else's. The trade-off: you're responsible for building your own watchlist rather than leaning on a shared pool. But that watchlist is 100% relevant to your operation. A retail store's priority is shoplifters and organized crime groups. A nightclub's priority is violent offenders flagged by other venues and law enforcement. A corporate office's priority is tailgating and unauthorized access. Why would they all share the same database?
People don't think through the real risks. Data breach liability: when the shared pool leaks, who's liable? You, the supplier, or both? GDPR complexity: are you joint controllers of the data? Vendor lock-in: try leaving when your data is mixed with thousands of others. Your contract says they'll delete it, but can you audit the deletion? Reputational risk: if the supplier misuses data or gets hacked, your brand is associated with that failure. And the ethical question: biometric data is being used without individuals' informed consent across multiple unrelated organizations. That's not a technical problem—it's a governance problem.
It's cleaner legally. You're the sole controller of biometric data collected at your venue. It's simpler to audit. You know exactly who has access and what they see. It's easier to explain to regulators. It's straightforward data protection: you collect data, you process it, you retain or delete it according to your policy. And you maintain full control. Yes, you build your own watchlist rather than inheriting someone else's. But that watchlist is more accurate for your specific threats, more defensible legally, and entirely yours.
FaiceTech builds independent database architecture as standard. Every customer gets their own segregated environment. Data never crosses between customers. When a contract ends, data is deleted. This isn't an upsell—it's the default, because it's the right way to handle biometric data. We build this architecture because it's cleaner, safer, and more compliant. If you want to understand how data segregation works in practice, read our data segregation article for a deeper dive. And for compliance details, check our compliance page.
Before signing with any facial recognition supplier, ask these questions: Is my data segregated from other customers? Who else can access it? What happens to it if I leave? Do you have a formal data deletion process I can audit? If you don't like the answers, walk away. The cheapest solution isn't always the safest one.
We've published a detailed guide comparing these models specifically for UK retailers. Download "Independent vs Shared Database Models" from our Documentation page.