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.

Database schema and structural synchronization

TYPO3 manages database schema definitions through:

  • ext_tables.sql files provided by extensions.
  • 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_log, or 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
Copied!

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.