Open-Xchange App Suite database and storage design guide

Why Open-Xchange App Suite database design decides the platform's recovery and growth

The database and storage layer sets the failure domains and the growth path of an OX App Suite v8 platform. When you run the platform in your own infrastructure, you decide where mail metadata, PIM data such as calendars, contacts and tasks, OX Drive files and PIM attachments live. Each placement determines what fails together, what can be restored on its own, and how capacity is added later. Settle these decisions before you finalize Helm values, because the application layers inherit them.

The design is harder than it looks because the database and the distributed file system must be sized together. OX App Suite v8 uses MariaDB with the InnoDB storage engine as its primary data store, and the supported lines are 10.6.x, 10.11.x, 11.4.x and 11.8.x. Galera Cluster is supported, so a multi-node database is an option. Metadata and file volumes grow along different curves, but both follow mailbox counts, so a sizing model has to tie them together before either tier is built.

Persistent data, including OX Drive files and PIM attachments, must sit on a distributed file system. NFS is the expected choice for small to mid-size deployments, while object storage such as AWS S3, Ceph RadosGW or Scality RING fits larger ones. Confirm with Open-Xchange which backends are validated for your target release and how they behave under your failover design. Also ask how files and the database are backed up and restored together, because a database restore without matching files leaves references pointing at nothing.

Several choices are expensive to change after users are onboarded: the database topology, the storage backend, and how the two are kept in step. Moving files between backends, converting a single database node into a Galera cluster, or splitting a shared store all need migration windows, testing and a rollback plan. Before you sign a scope, ask for a sizing worksheet that links mailbox counts to database and file growth, a failure-domain map for each data class, and a written restore procedure. Those items also drive the infrastructure and effort lines in the quote.

Which data components the design must place

Four components hold the state of an OX App Suite v8 platform, and each fails differently. Treat the database, the cache and session store, and the file store as separate design decisions, because losing one does not automatically mean losing the others. The cards below cover what each component holds, what is lost if it fails, and what to confirm before you fix its design.

MariaDB with InnoDB as primary store

MariaDB with the InnoDB storage engine is the primary data store for OX App Suite v8. It holds core records such as user, context and configuration data that the middleware reads throughout a session. If this database is lost without a replica or a tested restore, logins and mailbox access stop until it is recovered. Confirm which supported branch you will run (10.6.x, 10.11.x, 11.4.x or 11.8.x) and check its compatibility with your chosen Helm chart release before you select an image.

Galera Cluster as a supported option

Galera Cluster provides synchronous replication across several MariaDB nodes, so the database can survive the loss of a single node without a manual failover. The decision is whether a single database instance with verified backups meets your recovery goals, or whether node loss must be absorbed automatically. Galera adds write latency and cluster membership to operate, so plan for monitoring and node recovery. Ask Open-Xchange which Galera release is supported with your MariaDB branch and how many nodes it expects.

Redis 7.4.x for cache and sessions

Redis 7.4.x holds cached data and session state for OX App Suite v8. It is a separate decision from the database because it stores different data, with different recovery needs. If Redis is lost, cached data is rebuilt and active sessions end, so users must sign in again, but mailbox and file content is not stored there. Choose between the default littlered operator and a custom or unmanaged Redis setup based on who will patch, monitor and restore it.

Distributed file system for files and attachments

OX Drive files and PIM attachments must sit on a distributed file system, which is the component holding content that users cannot recreate. NFS is listed for small to mid-size deployments, and object storage such as AWS S3, Ceph RadosGW or Scality RING is listed for larger ones. Confirm how the chosen storage replicates data, how snapshots are taken, and how restores are tested outside the cluster. Verify with Open-Xchange that your storage type is supported for both Drive and attachment data.

Which database and storage options fit which deployment

This table compares the database and storage options for OX App Suite v8, using the MariaDB release lines, replication models, file options and hosting models named in the requirements. Read each row for the deployment size it suits and the staff time, backup scope and failure handling it adds. The main takeaway is that replication model, storage type and hosting choice drive most of the operating load, so settle them before sizing the platform.

Option	When it fits	Operational cost and failure handling
MariaDB primary with replica	Small to mid-size deployments where a manual promotion window is acceptable	Staff promote the replica by hand; backups must cover the primary and its binary logs.
MariaDB Galera cluster	Deployments that need writes to continue through a node loss without manual promotion	More nodes to patch and monitor; plan quorum loss recovery and consistent backups across all nodes.
NFS for Drive and attachments	Small to mid-size deployments, as the requirements describe	Simplest to operate; back up the export together with the database so files and metadata match.
Object storage (S3, Ceph RadosGW, Scality RING)	Larger deployments that need the distributed storage the requirements describe	Storage team must run Ceph or RING; S3 use adds lifecycle, replication and access policies to design.
MariaDB 10.6.x or 10.11.x	Environments already running these lines that must stay on a supported release	Confirm current support status with Open-Xchange before committing to either line.
MariaDB 11.4.x or 11.8.x	New builds that will follow the newer supported release lines	Test schema upgrades in staging; plan a major-line upgrade window and a restore test.
Self-run database	Teams with database administration skills and an existing backup and monitoring stack	Your staff own patching, failover, restore testing and capacity growth on every node.
Managed database in client cloud	Teams that want the cloud provider to run patching and backups inside their own account	Cost is the service fee; confirm whether the service offers Galera or replica modes and backup retention.

How to build the database and storage layer in order

This sequence builds the data and storage layer for OX App Suite v8 in dependency order, from version checks through MariaDB and Galera, shared storage for Drive and attachments, credentials and Redis. Each step closes with a check, so the platform is confirmed working before application components depend on it.

Confirm the Kubernetes and Helm baseline
Your platform team checks that the target cluster falls within the Kubernetes versions OX App Suite v8 supports (N-1 and N-2), that Helm 3.17.0 or newer is installed, and that the ingress choice is settled. The choice is either Istio, which requires the latest release plus two prior versions, or the basic ingress-nginx option where Istio cannot be used. The step closes when the deployment host reports Helm 3.17.0 or later and a dry-run render of the chart values completes against the target cluster without errors.
Choose the MariaDB release line
The database team selects one MariaDB line from the supported list: 10.6.x, 10.11.x, 11.4.x or 11.8.x. InnoDB is the storage engine OX App Suite v8 uses as its primary data store, so confirm that the line you choose supports it in your configuration. Select the line against your patching and support policy, then confirm that the container image tag referenced by your chart version belongs to that line. The step closes when the chosen line and image tag are written into the design record and the image pulls successfully into a test namespace.
Decide the Galera cluster topology
Galera Cluster is supported, so decide the node count, how nodes are placed across failure domains such as separate hosts, racks or availability zones, and the storage each node gets. An odd number of nodes lets the cluster keep quorum after a single node loss. Confirm with Open-Xchange which sizing applies to your mailbox count before you commit to hardware or cloud instances. The step closes when a membership test shows every node has joined the cluster and reports a synced state, and a test write on one node appears on all the others.
Define schemas and database users
Create one schema for each OX component that needs relational storage, and a dedicated database account for each component with privileges limited to its own schema. Record the grant model in the design document so an operator can explain which component can read or write which data. Confirm with Open-Xchange which components own which schemas in your release. The step closes when each account logs in from its pod, completes its expected reads and writes, and is refused access to a schema it does not own.
Provision shared file storage for Drive and attachments
Choose the distributed file system by deployment size: NFS for small to mid-size deployments, or object storage such as AWS S3, Ceph RadosGW or Scality RING for larger ones. Lay out mount points or buckets for OX Drive files and PIM attachments, and give every application replica the same access path. The step closes when a test file written from one replica can be read back from every other replica, or, for object storage, when a test object is written and read through the endpoint the application uses.
Store credentials in Kubernetes secrets
Move database passwords, storage keys and Redis credentials into Kubernetes secrets, and reference them from the chart values by name so no plaintext credential sits in values files kept in version control. Decide before go-live who can read and rotate each secret, and document the rotation procedure. The step closes when the application pods start with the secrets mounted or injected, and a test lookup of each secret from inside a pod returns the expected value without writing it to logs.
Connect Redis for caching and sessions
OX App Suite v8 uses Redis 7.4.x for caching and session storage. The default path is the littlered operator, and unmanaged or custom Redis setups are also configurable, so confirm which option your design uses and that the version matches 7.4.x. The step closes when the middleware writes a test cache key and session entry, and a second replica reads both back, which confirms the connection and the shared state work.
Run the first integrity checks
Run the full set of checks together to create a baseline for later changes: Galera membership and sync state, a write and read on shared storage from every replica, an object write and read where object storage is used, and component logins against their own schemas. Save the outputs with timestamps and the chart and image versions, because this record is what you compare against during upgrades and failover tests. The step closes when every check passes and the baseline record is filed with the design document.

How Galera Cluster membership and mailbox growth shape the database tier

The Galera decision is a decision about write cost and failure behavior. Galera Cluster replicates each transaction as a write set and certifies it against the other members before the commit completes, so every node applies changes in the same order. That synchronous certification keeps the data consistent across nodes, and it also means write latency and the rate of conflicting writes matter more than read capacity alone. OX App Suite uses MariaDB with the InnoDB storage engine as its primary data store, and Galera Cluster is a supported option. Before you fix the design, confirm which supported MariaDB branch (10.6.x, 10.11.x, 11.4.x or 11.8.x) and which Galera release your team will operate, because certification and state transfer behavior depend on those builds.

Quorum is the rule that stops the cluster from splitting into two writable halves. A Galera cluster accepts writes only in a partition that holds a majority of its members. An even number of members can leave neither side with a majority after a network split, while an odd number lets one side keep quorum. Use the MariaDB and Galera vendor documentation to confirm the minimum member count, the arbitrator options and the supported topology for your environment, and do not adopt a node count from a template. If the members span two data centers, a split between them can stop writes everywhere unless a third location or arbitrator holds a vote. Ask whether your network design can place a voting member outside both failure domains.

For OX App Suite, the practical question is what users and services experience during a split or a rejoin. Writes in a minority partition are refused, so middleware requests that need the database will fail or stall while that partition is out of quorum. Users may see errors on mail, calendar or contacts actions they attempted during the event, and they may need to retry. When a node rejoins, Galera transfers state to it, and the donor and joiner can slow the cluster while the transfer runs. Redis 7.4.x holds caching and session storage in the OX stack, but confirm with the OX requirements which data paths still need MariaDB during a split. Test these cases in staging: isolate a node, interrupt a donor during state transfer, and record which OX requests fail and how they recover.

Mailbox growth changes the load in two ways. More concurrent PIM activity raises the write rate on the database, and more mailboxes, attachments and OX Drive files raise storage volume. Persistent data such as Drive files and PIM attachments must sit on a distributed file system, either NFS for small to mid-size deployments or object storage such as AWS S3, Ceph RadosGW or Scality RING for larger ones. That storage is sized separately from the database, even though both grow with the same user base. Plan capacity headroom for both tiers, and document the process for adding capacity: who approves it, how a new node joins through state transfer, when storage is expanded, and how the change is rehearsed before production. Confirm sizing against the MariaDB and Galera vendor guidance and a load test that reproduces your own peak mailbox activity.

How the design changes between cloud, on-premises and air-gapped sites

In a public cloud, the team usually points OX App Suite at managed object storage for Drive files and PIM attachments, such as AWS S3, and chooses between a managed MariaDB service and a self-run MariaDB cluster in the same account. The main design questions are who operates the database, which MariaDB versions the service offers from the supported list, and which network path the Kubernetes cluster uses to reach the data tier.

Storage access: object storage is reached over the provider's HTTPS endpoints, so access depends on workload identity or scoped credentials rather than mounted volumes.
Backup target: use the provider's snapshot service for database backups, and keep at least one copy in a separate account or project.
Network path: pods reach the database and object endpoints over private subnets, through private endpoints or peering, with security groups limited to the cluster's node and pod ranges.
Galera support: a managed database may offer only single-primary replication, so confirm whether Galera Cluster is available before choosing a managed service.

Before you commit, confirm with the cloud account owner who holds the encryption keys, how long object versions and database snapshots are retained, and whether the chosen regions meet the residency rules that apply to your mail data.

What drives the database and storage effort, and how to keep it down

This table lists the six factors that most change the size and effort of the MariaDB, Galera and file storage design for OX App Suite, with the effect of each and one practical way to reduce it. Read each row as a question to answer before scoping, because the answers set how much data, backup and access control the design must cover. No figures are given here, so ask for the sizing inputs in writing before a quote is prepared.

Driver	How it raises effort	How to keep it down
Mailbox and user counts	Total users and mailboxes set the row volume in MariaDB InnoDB, the message index and the size of the storage pool, and they decide whether NFS or object storage fits the file layer.	Confirm the peak user count and growth plan in writing at scoping, and size the first phase to that number so later expansion is a planned step.
Drive file use versus mail attachments	Heavy OX Drive file storage and large attachments grow the distributed file or object store far faster than the database, which changes backup windows, capacity planning and restore time.	Ask for expected average and maximum file sizes per user, then set quotas and file size limits early so storage growth is predictable.
Number of sites or availability zones	Each additional site or zone adds Galera nodes, cross-site latency handling, replicated or synchronized object storage and separate failover tests.	Start with one site and a documented path to add a second, and confirm which sites the business actually needs for failover before designing for all of them.
Number of environments (test, staging, production)	Every environment needs its own database, storage buckets or volumes, backups and access rules, so effort repeats for each one and drift between them causes failed upgrades.	Use the same Helm chart and the same database and storage design in every environment, changing only sizing values and secrets per environment.
Compliance and retention rules	Retention periods, legal hold, encryption at rest and backup scope decide what is backed up, how long it is kept, and what must be restored and evidenced, which adds design and testing work.	Agree retention periods, backup scope and encryption requirements in writing before the storage layout is fixed, and confirm evidence needs with your assessor or auditor.
Custom integrations that read the database	Each integration that queries MariaDB directly becomes a dependency on the schema, which must be checked after each upgrade and may need extra accounts, network paths and monitoring.	Limit integrations to supported APIs where possible, give each direct reader its own least-privilege account, and list every reader so upgrade tests cover them.

How to control access to database credentials and file storage keys

The access model for the OX App Suite data tier comes down to one rule: no component should hold more database or storage privilege than its function needs, and no human or backup job should hold standing access to live credentials. Start by separating database accounts. The middleware, the database components that serve different functions, and any maintenance or monitoring tooling should each use their own MariaDB user, with grants limited to the schemas and operations that role performs. A single shared account across the platform is the pattern to avoid, because one leaked secret then exposes every schema and every write path at once.

Grants are where the design is most often loosened without anyone noticing. Keep application accounts to data manipulation on their own schemas, and keep schema changes, user management and replication privileges with the accounts used during upgrades and Helm-driven migrations. Galera cluster administration should not share an account with application traffic. Before go-live, ask Open-Xchange for the exact grant set per account for your release, since the required privileges differ between the middleware, the storage components and the supported MariaDB versions (10.6.x, 10.11.x, 11.4.x and 11.8.x). Record the grants in your configuration repository so that a later upgrade can be reviewed against a known baseline.

Credentials for these accounts are typically delivered to pods as Kubernetes secrets. Treat those secrets as the controlled point: restrict which service accounts and namespaces can read them, avoid placing them in Helm values files committed to version control, and define a rotation procedure before you need one. Rotation touches both the database user and every consumer of the secret, so plan it as a sequenced change: create the new credential, update the secret, roll the affected deployments, then revoke the old credential. Confirm with Open-Xchange which components read which secrets and whether a rolling restart is needed for each. The same approach applies to Redis credentials where you run a custom or unmanaged instance.

File storage keys need the same discipline. For object storage such as AWS S3, Ceph RadosGW or Scality RING, issue separate keys for Drive and for PIM attachments where your storage platform allows it, and scope each key to its bucket or prefix with a bucket policy. Write access should be limited to the components that store files, and read or delete rights should be confirmed against what the product expects. If you use NFS, control access through export restrictions and the UID and GID mapping the platform relies on, and verify these with the storage administrator rather than assuming defaults. Confirm the exact permission model with Open-Xchange documentation for your release before you write policies.

Operators and backup tools form the last boundary. Human administrators should reach the data tier through named, audited roles rather than shared root credentials, with break-glass access documented and logged. Backup jobs need read access to data and the ability to write to the backup target, but should not hold the application credentials or the ability to alter schemas. Test the restore path with its own account, because a backup role that cannot restore is a silent failure. Network-level restrictions on which hosts can connect to the database and storage endpoints are covered in the security hardening topic, so the controls described here assume that path is already restricted.

What to monitor, back up and document after go-live

Once OX App Suite is live, the database and storage design only holds if someone watches it, restores from it and records it. The cards below cover the recurring duties that keep MariaDB, the file or object store and their documentation in step with mailbox growth and the platform's release calendar.

Monitor replication and storage capacity

Track MariaDB replication lag on a primary and replica pair, or Galera node state, cluster size and flow control, for the InnoDB data store. Alongside that, watch free space and growth on the NFS export or object bucket that holds OX Drive files and PIM attachments. Set alerts before either tier reaches a level that would block writes, and review the growth trend against the mailbox count each quarter.

Define the backup scope

Backups must cover two things: database dumps or snapshots of the MariaDB schemas, and the file or bucket data that holds Drive files and attachments. Restoring one without the other leaves metadata pointing at missing content, or content with no owner record. Confirm with the vendors you select whether their backup tooling supports consistent snapshots across both tiers, and document what is excluded.

Schedule restore tests

A backup that has never been restored is an assumption, not a control. Schedule restore tests into a separate environment on a fixed cadence, and record the time taken and any manual steps required. Include a check that a sample of Drive files and attachments opens correctly after the database is restored, since the two tiers can drift apart.

Coordinate database and storage upgrades

MariaDB and storage component upgrades must be planned against the OX App Suite release and support windows, not run on their own calendar. Check the supported MariaDB versions for the App Suite release you run before changing the database engine. The upgrade procedure itself is covered in the upgrades topic, so this card covers the scheduling and the sign-off between the platform and database owners.

Maintain the data design document

Keep a living document that records each schema, bucket or export, its retention period, its owner and its backup schedule. Update it whenever a schema or storage class changes. An auditor or incident responder should be able to trace any stored item to a named owner and a retention rule from this document alone.

Questions buyers ask about Open-Xchange database and storage design

What does database and storage design work for OX App Suite cost?

Cost is driven by how many environments you need, how many mailboxes and file users the design must size for, whether you run Galera Cluster or a single MariaDB instance, and which storage backend you choose. The design work is a scoped engagement: you pay for analysis of your sizing inputs, the database and storage architecture, the configuration and sizing documentation, and the review sessions with your team. Ongoing costs such as storage capacity, database hosting, backup retention and staff time recur after go-live, while the design itself is one-time. DeployOpen does not publish a price list. Ask for a written quote that lists each deliverable, the environments covered, the assumptions about mailbox counts and growth, and any items that are excluded, such as the Kubernetes cluster and the Redis layer. For total platform cost, see the Open-Xchange implementation plan and cost topic.

How long does OX App Suite database and storage design take?

The duration depends mainly on the number of mailboxes and file users you need to size for, the number of environments (for example production, disaster recovery and staging), and how quickly your storage and backup owners can provide capacity figures and decisions. Larger estates with object storage or multi-site replication need more time for design reviews than a single-site NFS deployment. Your team's readiness is often the longest dependency: sign-off on retention periods and access to current storage metrics can take longer than the technical design. A fixed-scope agreement sets the timeline in writing before work starts, with the inputs and review points named so both sides can see what the schedule depends on. Ask any partner to state which inputs they need and when, and to confirm the timeline against those inputs.

What does our team need to provide for the design work?

Plan for four groups of input. Your platform or infrastructure team gives access to the target Kubernetes cluster, network segments and any existing database or storage environment. Your storage administrators provide current capacity, performance characteristics and the options available for NFS or object storage, such as S3-compatible, Ceph RadosGW or Scality RING. Your backup owners describe the current backup tooling, recovery objectives and restore testing practice. Your compliance or data owners sign off on retention periods for mail, attachments and Drive files, including deletion rules. Agree early who makes each decision and how quickly they can respond, because the design cannot close on retention or storage choices without them.

Can our internal team design MariaDB and storage for OX App Suite alone?

A capable internal team with MariaDB, Galera and distributed storage experience can design the layout alone, provided it has time, access to the test environments and someone who owns the sizing decisions. The supported MariaDB versions for OX App Suite v8 are 10.6.x, 10.11.x, 11.4.x and 11.8.x, and Galera Cluster is supported, so the team must check the chosen version against the requirements at design time. The work that most often stalls internal teams is validating the design under realistic load and failure cases, and documenting it for audit and operations. Consider whether a second pair of eyes or a fixed-scope review would reduce risk. Decide this by skills and capacity, not by whether the work is technically possible.

Which storage option should we choose for OX Drive files and attachments?

The OX App Suite requirements state that persistent data such as Drive files and PIM attachments must sit on a distributed file system. NFS is the stated option for small to mid-size deployments, while object storage such as AWS S3, Ceph RadosGW or Scality RING fits larger deployments. The right choice depends on your expected file volume, growth rate, latency and throughput needs, existing skills, and whether you already operate an object storage platform. Object storage often shifts work to your storage team for replication and lifecycle rules, while NFS concentrates operational effort on the file server. Ask the design team to document the options against your sizing inputs and to state the operational tasks each option adds.

How do we ask a partner for a fixed-scope quote for this design?

Send a written request that states your environments, the mailbox and file user counts you need to size for, the expected growth over the planning period, the storage options you are considering, and whether Galera Cluster is in scope. Ask for a fixed-scope proposal listing deliverables, such as the database layout, storage design, sizing model, backup and restore approach, and review sessions. Ask which items depend on your team, with owners and dates, and which are excluded. Confirm how changes are handled if your mailbox counts or storage decisions change during the work. Fixed-scope engagements are agreed in writing before work starts, so the quote should match that document. Compare proposals on scope and assumptions, not on the headline figure alone.

Does the design need to change if we operate in a regulated sector?

Yes, the design often needs extra inputs. Retention, encryption, access control, backup separation and evidence of restore testing are typically set by your internal policies and the obligations that apply to your sector. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. Ask your compliance lead to name the controls the design must support before the design starts, and ask the partner to map each design decision to the evidence it will produce. This keeps the assessment preparation grounded in your actual obligations.

How DeployOpen scopes, builds and hands over the data layer

DeployOpen designs the MariaDB InnoDB data store, the Galera clustering option and the distributed file or object storage for OX Drive files and PIM attachments as one written scope, sized to your mailbox counts and deployed in infrastructure you control. Each step produces documented decisions your own operators can check and run.

How we scope

Confirm the OX App Suite v8 release line and the MariaDB version from the supported list before sizing any database.
Size the data store against expected mailbox counts, Drive usage and attachment volume, recorded in the written scope.
Choose NFS or object storage for files and attachments based on deployment size, and name the storage product in the scope.
Agree the engagement as a fixed scope with written deliverables and timelines, then price it from that scope.

How we build

Deploy MariaDB with InnoDB as the primary data store, with Galera Cluster configured only where the agreed design requires it.
Configure the distributed file system or object storage that holds Drive files and PIM attachments, with access and retention settings.
Test backup and restore of the database and file store against the documented recovery steps before handover.
Document every configuration value, version pin and storage path so changes can be reviewed during Helm chart upgrades.

How we hand over

Deliver a design record covering database topology, storage layout, sizing assumptions and the decisions behind them.
Provide runbooks for routine tasks such as capacity checks, credential rotation, backup verification and restore testing.
Walk your platform and database operators through the build and the runbooks, and confirm who owns each component after go-live.
Record the open items and the release channel your team will follow so the data layer stays inside the support window.

How we support

Offer ongoing support, upgrades and continuous testing for the data layer as a retainer, separate from the initial fixed scope.
Review database and storage capacity against mailbox growth at intervals agreed in the retainer scope.
Re-test backup, restore and failover paths after each platform upgrade that touches MariaDB, Galera or the storage layer.
Confirm exact support terms, response expectations and the retainer fee with DeployOpen in writing before work begins.

Open-Xchange App Suite database and storage design