Synchronizing database content across environments
TYPO3 projects not only involve managing code and configuration across multiple environments but also database content and user data.
This chapter focuses on managing database schema and content, covering strategies for synchronizing schema changes, handling personal data responsibly, and managing content between development, staging, and production systems.
Note
This chapter is focused on database content only. For managing uploaded files, images, and media assets, see Synchronizing user-uploaded files across environments.
Database schema and structural synchronization
TYPO3 manages database schema definitions through:
ext_
files provided by extensions.tables. sql - TCA definitions for records and tables.
You can also use external tools like Doctrine Migrations or custom scripts to automate structural changes if your project requires more control.
Content and handling of personal data
When you copy database content between environments, data privacy and regulatory requirements such as GDPR must be adhered to.
Best practices include:
- Avoid transferring personal or sensitive data to non-production systems.
- Anonymize or pseudonymize user records and personal information.
- Limit content synchronization to necessary data only.
For example:
- Export only specific pages or records.
- Strip sensitive tables like
fe_
,users sys_
, orlog cache_*
. - Replace personal data with dummy values.
Import/Export workflows in TYPO3
TYPO3 provides a built-in Import/Export module,
typo3/cms-impexp
, that allows exporting and importing
database records as .t3d
files.
The module is designed to work with structured data that is stored in the TYPO3 database, such as:
- Pages and their content elements
- Records in system and extension tables
It can include referenced files, such as images or user uploads,
when these files are related to exported records. These files are bundled
alongside the .t3d
export if the option to include files is selected.
Typical use cases include:
- Moving page trees or content elements between systems.
- Providing editors with content snapshots for review or duplication.
- Exporting small sets of records along with their referenced files.
Limitations to consider:
- Exported files may not capture all dependencies or extension-specific data.
- It may not scale well for large datasets or complete site transfers.
- Including large file sets can make exports unwieldy.
You can work with Export Presets to make export settings repeatable and consistent.
You can also use the Command Line Interface to automate exports in your CI/CD pipeline or to avoid PHP runtime limitations.
Reduced database dumps
In many projects, reduced database dumps can be used to create realistic and privacy-compliant datasets for development or staging.
Typical strategies include:
- Dumping only structure and selected content tables.
-
Excluding sensitive tables such as:
fe_
users be_
users sys_
log be_
sessions cache_*
Example mysqldump
commands:
# Export the database structure only
mysqldump --no-data -u user -p database > structure.sql
# Export the data, excluding sensitive or unnecessary tables
mysqldump \
--ignore-table=database.fe_users \
--ignore-table=database.be_users \
--ignore-table=database.sys_log \
--ignore-table=database.be_sessions \
--ignore-table=database.cache_* \
-u user -p database > reduced_dump.sql
Best practices for sharing database content across environment stages
- Separate schema and data handling in your deployment workflow.
- Avoid copying full production data without anonymization.
- Use TYPO3 Import/Export for specific content migration.
- Document your project's data management strategy.
- Ensure compliance with data privacy regulations.