Database structure and tables

TYPO3 distinguishes between internal and managed tables.

Table of contents

Internal tables

Used internally by TYPO3 and not accessible in the backend (e.g. tables such as be_sessions, sys_registry, cache tables). They are accessed via TYPO3 APIs such as the caching framework. These tables are not editable unless a specific backend module provides access.

Typical categories include:

  • Cache tables: Created automatically when using a database-based cache backend
  • Session tables: fe_sessions, be_sessions

  • System tables:

    • sys_registry: Global configuration
    • sys_log: Viewable via System > Log

Managed tables

Defined in the TCA and, by default, editable in the Web > List module. TYPO3 derives database schemas from the TCA configuration. Required fields such as uid and pid are generated automatically.

Required fields:

  • uid: Primary key (auto-incremented)
  • pid: Page reference (from the pages table)

Typical fields:

  • title: Title displayed in backend lists
  • crdate: Creation timestamp
  • tstamp: Last modification timestamp
  • sorting: Manual sort order
  • deleted: Soft delete flag
  • hidden or disabled: Visibility control

These fields and their behavior are defined in the table properties (ctrl section of TCA).

When records are rendered in the backend using the FormEngine, entries with the soft delete flag set ( deleted) will not be shown.

When querying tables via TypoScript, visibility fields such as hidden, startdate, and enddate are respected.

If you use the DBAL query builder to access the database, the restriction builder automatically filters records based on visibility fields unless explicitly disabled.

When using an Extbase repository, the query settings also apply visibility constraints by default, but can be reconfigured to change this behavior.

The pages table

Defines TYPO3's hierarchical page tree. All managed records reference a pages.uid via their pid.

  • The root page has pid = 0 and does not exist as a row in the table.
  • Only administrators can create records on the root level.
  • Tables must explicitly allow root-level records using -.

Many-to-many (MM) relations

MM tables store relationships between records. Examples include:

  • sys_category_record_mm: Categories and categorized records
  • sys_file_reference: File usage in content and pages

These tables may appear in the backend if configured via inline records.