Confluence Storing
Confluence storing uses a relational database for text and a separate file system for attachments. You set up these two storage layers to hold all your team pages and files. Teams often give wide database roles to admins who maintain this storage backend. Broad roles create risk because one mistake can drop tables or expose private text. How confluence storing works in your setup The platform splits data into two distinct places to keep page loads fast. A core relational database holds page t
Storing: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
Confluence storing uses a relational database for text and a separate file system for attachments. You set up these two storage layers to hold all your team pages and files. Teams often give wide database roles to admins who maintain this storage backend. Broad roles create risk because one mistake can drop tables or expose private text.
How confluence storing works in your setup
The platform splits data into two distinct places to keep page loads fast. A core relational database holds page text, comments, user permissions, and space rules. Every time a user edits a page, the app writes a new database row. This database also tracks page history so teams can restore old versions when needed.
Large files like images, PDFs, and spreadsheets do not sit in the main database. Instead, the app writes these binary files to a local disk or object storage. The database only stores a small pointer that links the page to the file. This split design stops huge file uploads from making text searches slow.
Search indexes live on the local server disk to speed up daily user queries. When a user looks for a topic, the app reads the index first. Admins must back up both the database and the file folders at the same time. If these two backups do not match, pages will load with broken file links.
What native storage roles solve and what they miss
Native space permissions let admins control who can read or edit pages in the app. You can lock down a space so only the finance team sees budget notes. Database roles also let you limit which servers can log in to the data store. These controls work well to block outside users from reading your wiki pages.
Still, app permissions do not govern engineers who log in to the backend database. Support staff often need direct database access to fix broken page locks or run upgrades. Once an engineer logs in with a database role, space rules no longer apply. That user can read any table or run a bad update across all spaces.
Storing: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Native database roles only check who logs in at the start of a session. They do not check what individual queries or commands do while the session runs. A single query can return emails, phone numbers, card numbers, or national IDs in clear text. Data masking rewrites matched fields in results so support staff still fix issues safely.
Best practices for database and file maintenance
Teams should separate regular app traffic from admin maintenance tasks at the database level. Give the wiki app its own service account with rights to read and write data. Never share that service account key with engineers who run manual fixes or checks. Each engineer should log in with a personal identity so logs show who ran what.
Keep your database size small by clearing out old trash and unused file versions. High version counts make backups slow and add cost to your storage disks. Run regular checks during off hours to find and remove orphaned files on disk. Always test your restore steps on a staging server before a real outage happens.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Where does the platform store uploaded page attachments?
The app stores attachments on a local file system or in cloud object storage. The relational database only holds metadata and file paths that point to those files.
Can database admins read private wiki spaces during maintenance?
Yes, raw database tables store page text in plain form without app space checks. Anyone who queries the backend tables can read private pages unless field masking rewrites results.
Why must teams back up the database and files together?
Database rows point to exact files stored on your disk or object storage. If the two backups come from different times, pages will miss recent files or fail.