Architecture & System DesignDOC-ARCHITECTURE-DATABASE

Database Architecture: Multi-Tenant vs Dedicated

Technical and business considerations for ERP database architecture, including data isolation, performance, compliance implications, and cost trade-offs.

10 min read
2,200 words
Updated 2026-02-24

The Database Architecture Question#

For cloud ERP, database architecture is one of the most significant decisions affecting data isolation, performance, compliance, and cost. Understanding the options is essential for informed vendor evaluation.

Multi-Tenant Architecture#

In multi-tenant architecture, multiple customers share the same database infrastructure. Data is logically separated but physically co-located.

Implementation Approaches#

Shared database, shared schema: All customers share the same database and tables. A tenant identifier column separates data. This is the most cost-efficient but provides the weakest isolation.

Shared database, separate schemas: All customers share the database instance, but each has a separate schema. This provides better isolation while maintaining some cost efficiencies.

Separate databases, shared infrastructure: Each customer has a dedicated database, but databases run on shared server infrastructure. This provides strong isolation with moderate cost.

Advantages#

Cost efficiency: Infrastructure costs are spread across multiple customers.

Simplified maintenance: The vendor applies updates once for all customers.

Resource pooling: Unused capacity from one tenant can serve others.

Disadvantages#

Noisy neighbour problem: Heavy usage by one tenant can affect performance for others.

Limited customisation: Schema changes affect all tenants.

Data isolation concerns: Software bugs could potentially expose data across tenants.

Compliance complexity: Some regulations require physical data separation.

Dedicated (Single-Tenant) Architecture#

In dedicated architecture, each customer has their own database infrastructure, completely isolated from other customers.

Advantages#

Strong isolation: Your data is physically separated from other customers.

Full customisation: You can modify the schema and configuration as needed.

Predictable performance: No noisy neighbour problems.

Compliance simplicity: Easier to demonstrate data residency and isolation.

Disadvantages#

Higher cost: You bear the full infrastructure cost.

Maintenance overhead: Updates must be applied to each instance separately.

Resource inefficiency: Capacity allocated to you cannot be used by others.

NZ/AU Compliance Considerations#

Privacy Act 2020 (NZ)#

The Privacy Act requires reasonable security safeguards for personal information. Multi-tenant architecture is not inherently non-compliant, but organisations must be satisfied that logical separation is adequate.

Privacy Act 1988 (AU)#

Australian Privacy Principle 11 requires reasonable steps to protect personal information. The "reasonable steps" standard may be higher for sensitive data.

Industry-Specific Requirements#

Financial services: APRA (AU) and RBNZ (NZ) may have additional requirements for data isolation.

Healthcare: Health information may require stronger isolation under relevant regulations.

Government: Government agencies may have specific data sovereignty requirements.

Vendor Evaluation Questions#

When evaluating cloud ERP vendors:

  1. What database architecture do you use?
  2. How is data isolation implemented and verified?
  3. What certifications do you hold (SOC 2, ISO 27001)?
  4. Can you provide dedicated infrastructure if required?
  5. How do you handle data extraction if we terminate the contract?

Monday Morning Action Plan#

This week:

  1. Classify Your Data Sensitivity: List all data types in your ERP. Classify as public, internal, confidential, restricted. Multi-tenant may not suit confidential/restricted data.
  1. Review Your Compliance Posture: Check if Privacy Act 2020 (NZ) or Privacy Act 1988 (AU) requirements mandate physical data separation.
  1. Ask Your Vendor the Hard Questions: "Where exactly is my data stored?" "Who else's data is on the same infrastructure?" "What happens if another tenant has a security breach?"
  1. Document Your Customisation Needs: If you need extensive customisation, multi-tenant may constrain you. List your top 10 customisation requirements.
  1. Check Your Contract for Exit Rights: How do you get your data out? What format? Test the vendor's answer with a real scenario.

---

Conclusion: Match Architecture to Requirements#

Multi-tenant architecture is adequate for most organisations and provides cost benefits. However, organisations with sensitive data, specific compliance requirements, or strong customisation needs should evaluate dedicated options.