Where Umbraco Keeps Its Data
Umbraco operates as a content management system built on .NET technologies. It handles various types of data required for websites, including page content, media assets, and user information. Storage occurs across multiple locations to balance performance, persistence, and accessibility. This article examines the primary storage mechanisms based on official documentation and practical implementations.
Core Data Storage Locations
Umbraco distributes data across three main areas: relational databases, the file system, and in-memory structures. Each serves specific purposes in the system's architecture.
Relational Database
The database forms the backbone for structured data in Umbraco. It holds raw content, document definitions, property values, and member records. Microsoft SQL Server serves as the default option, though alternatives exist for different environments.
Key tables manage the content tree and associated data:
- umbracoNode: Tracks all nodes in the content, media, and member trees with hierarchy information.
- cmsContent: Stores core content details like node ID, content type, and version timestamps.
- cmsPropertyData: Contains individual property values for each content node.
- cmsContentXml: Holds pre-rendered XML representations used for caching.
- umbracoUser: Manages backoffice user accounts and permissions.
Document types, media types, and member types define the schema for content entry. These definitions control properties and data organization within the database. Content editors create nodes through the backoffice, which inserts records into relevant tables.
Version history and draft management rely on database entries. Scheduled publishing features mark content for automatic release or unpublishing at set times. Relations between entities use dedicated tables to maintain connections.
Umbraco Forms data integrates directly into the database when configured for relational storage. This includes form definitions, field configurations, and submitted entries.
File System Components
The file system handles non-structured assets and configuration files. Media files represent the largest portion of file-based storage.
Media Storage
By default, uploaded images, videos, PDFs, and other files land in the wwwroot/media directory. Umbraco generates unique paths using identifiers, resulting in structures like /media/abc123/filename.jpg. This approach prevents naming conflicts and supports organization through folders.
Default media types include:
- File: General documents with extension and size properties.
- Image: Supports width, height, and bytes with built-in cropper integration.
- Folder: Organizes media items without storing actual files.
- Video/Audio: Specialized types for multimedia assets.
The system assigns each media item a numeric or alphanumeric ID at upload. The first part of the path (1001, 2abc) comes from this ID, split into chunks to avoid too many files in one folder. This structure is consistent across all Umbraco versions and helps with file system performance on large media libraries.
The media folder lives inside the web root by default, making files directly accessible via URL. For example, https://yoursite.com/media/1001/photo.jpg serves the file without routing through the CMS. This behavior changes when remote storage providers are enabled — then URLs point to cloud locations, but the backoffice interface remains the same.
When the Image Cropper is used, Umbraco creates additional image variants on demand. These files appear alongside the original, using suffixes like -600x400.jpg or -thumb.jpg, depending on crop settings defined in the media type.
Configuration and Cache Files
Application settings reside in configuration files:
- web.config (legacy) or appsettings.json: Connection strings, feature flags, and provider settings.
- umbraco.config: XML cache file in App_Data containing full content tree snapshot.
- App_Data/UmbracoForms: Stores form workflow definitions in older configurations.
The umbraco.config file generates during application startup to speed up content loading. It reduces database queries for frequent operations.
In-Memory Handling
Umbraco loads content into memory for request processing. The XML document from umbraco.config or database builds an in-memory representation accessible to views.
Razor templates retrieve data from this cache during page rendering. Temporary data collection, such as in Umbraco Engage, occurs in memory before periodic database writes based on thresholds.
Memory structures maintain content cache with node relationships, published/unpublished state tracking, and property value collections for current requests.

Experience with Umbraco Data Storage at OSKI Solutions
At OSKI Solutions, we build and maintain Umbraco sites for clients across the US, Canada, the UK, Germany, the Netherlands, Switzerland, the Nordic countries, Israel, and other parts of Europe. That means we live and breathe its storage architecture every day. Understanding exactly where Umbraco stores data-content in tables like umbracoNode, cmsPropertyData, and cmsContentXml, media in the wwwroot/media folder by default, and cache in App_Data-lets us set up rock-solid backups, seamless deployments, and effortless scaling.
For most projects, the default setup works beautifully and stays predictable from local development to production. When traffic spikes or teams grow, we switch media to Azure Blob Storage or AWS S3 without breaking a sweat, simply by configuring remote providers and tweaking file system paths. This keeps everything consistent whether we’re modernizing a legacy .NET system, building a new React-powered web app, or integrating with CRM and payment gateways.
That clear map of database, file system, and cache is our starting point on every project. It powers smooth migrations, faster query optimization, and confident handoffs so client teams can manage updates themselves. No matter the scale-e-commerce platforms, fintech dashboards, or logistics systems-we make Umbraco’s data storage work for the business, not against it.
Content Organization in the Backoffice
The backoffice divides data into three primary sections: Content, Media, and Members. Each corresponds to specific storage locations and management interfaces.
Content Section
Website pages and structured data live here. Document types log define available properties and tabs. Editors create nodes that generate database records.
Tabs group properties for better organization. Generic properties appear in a default tab unless assigned elsewhere. Dictionary items provide translatable text values accessed by key.
Content features support version comparison and rollback, scheduled publish/unpublish actions, relation mapping between nodes, and property editor customization via data types.
Media Section
File uploads occur through this interface. Media types control property exposure for different asset categories. The Image Cropper enables multiple predefined sizes from a single upload.
Media management supports folder-based organization, metadata assignment per item, bulk operations for uploads, and property editing post-upload.
Members Section
User profiles and authentication data reside here. Member types define required fields. Database tables store membership information separately from content nodes.
Member data includes profile properties defined by member types, group assignments for permissions, login credentials and status flags, plus frontend authentication integration.
Advanced Storage Configurations
Standard installations use local storage, but production environments often require alternatives.
Remote Storage Providers
Cloud storage integration addresses scalability limitations of local file systems.
Azure Blob Storage
The Umbraco.StorageProviders.AzureBlob package enables media storage in Azure containers. Files no longer reside on the server file system, reducing local storage demands.
Configuration involves:
- Installing the NuGet package
- Adding connection string to configuration
- Setting storage provider in Umbraco settings
- Migrating existing media items
Amazon S3
Our.Umbraco.StorageProviders.AWSS3 connects to S3 buckets. This provides durability and global distribution options.
S3 integration offers automatic file replication across regions, versioning for media assets, access control via bucket policies, and CDN compatibility for delivery.
Implementation requires package installation and configuration updates. Media paths reference cloud locations while maintaining Umbraco's interface consistency.
Database Alternatives
While SQL Server remains primary, Umbraco supports multiple database backends:
- SQL Server Express/Compact: Lightweight options for smaller installations
- SQLite: Default for development and testing environments
- MySQL: Legacy support requiring specific versions
- SQL Azure: Cloud-hosted SQL Server instances
Database choice affects deployment complexity and performance characteristics. Production environments typically favor full SQL Server for features and reliability.
Conclusion
Umbraco structures its data storage across relational databases, local file systems, and in-memory caches to support both development flexibility and production-scale performance. Content, members, and metadata persist in database tables such as umbracoNode and cmsPropertyData. Media assets default to the wwwroot/media directory with identifier-based paths, while configuration and cache files occupy App_Data. Remote providers like Azure Blob Storage or Amazon S3 replace local media storage when scalability demands it. Understanding these locations enables developers to configure backups, optimize performance, and plan deployments effectively. The combination of SQL Server for structured data and configurable file providers for assets forms the core of Umbraco’s storage architecture.
FAQ
Where are uploaded images stored by default?
Images go to the wwwroot/media directory with unique identifier paths like /media/12345/image.jpg.
What database tables hold content properties?
The cmsPropertyData table stores individual property values, linked to nodes via cmsContent.
Can media files be stored outside the web root?
Yes, through custom file system providers or configuration changes to the media directory path.
How does umbraco.config improve performance?
It caches the entire content tree in XML format, reducing database queries during application startup and content rendering.
What alternatives exist for local media storage?
Azure Blob Storage and Amazon S3 via dedicated packages, plus other cloud providers with custom implementations.
Where does Umbraco store member data?
Member information resides in database tables separate from content nodes, defined by member types.
How are content versions managed?
Database tables track draft and published versions with timestamps, allowing comparison and rollback through the backoffice.