Image Database for TYPO3

Beyond 5,000 images, TYPO3’s FAL becomes a bottleneck

TYPO3’s File Abstraction Layer manages files reliably as long as the volume stays manageable. With 500 images, FAL works flawlessly. At 5,000, search gets slow. At 20,000, the file list in the backend is barely usable. Organizations with large image libraries need more than a file system: they need digital asset management. The question is whether to build TYPO3’s FAL out into a DAM or to connect an external system.

Both routes work. Building on FAL extensions costs less and stays within the TYPO3 ecosystem. An external integration (Celum, Canto, Cloudinary, Bynder) offers more features, but it requires licenses, interface maintenance and logic for keeping data consistent across two systems.

Typical use cases

Manufacturers with product photography. A machine builder has 8,000 product photos in different resolutions, plus CAD renderings, application shots and data sheets. Each product exists in 5-10 image variants. Without systematic tagging, editors cannot find the right image, or worse, they use an outdated one. AI auto-tagging analyzes image content and assigns tags automatically. For one client with 12,000 product images, AI-based auto-tagging cut the tagging effort from 3 weeks to 2 days.

Media companies and publishers. News portals, magazines and corporate publishing teams produce new images every day. Their requirements: fast search, rights management (license expiry, usage rights per channel), automatic format conversion and metadata inheritance. An extended FAL with custom fields covers the basics. Rights management and workflow control require an external DAM.

Universities and research institutions. Universities manage campus photos, event pictures, research graphics and staff portraits. The challenge: decentralized contributions from 30+ departments flowing into one central system. TYPO3 FAL with a category-based folder structure and access rights per user group solves this. External DAM systems rarely pay off here.

Technical architecture

TYPO3’s FAL consists of three layers: the storage driver (local file system, S3, Azure), the file index (the sys_file database table with metadata) and the file reference system (the link between files and content elements). An image database in TYPO3 primarily extends the middle layer, the file index.

The simplest extension: custom fields in the sys_file_metadata table. TYPO3 already ships fields such as title, description, alternative and copyright. Via TCA, you can add any further fields you need: photographer, license_type, expiry_date, usage_rights, location, keywords_auto. These fields then appear in the file metadata dialog in the backend.

Out of the box, TYPO3 only offers a file name search in the File List module. Real full-text search across all metadata requires either a Solr integration (via EXT:solrfal) or a custom backend module connected to Elasticsearch. Solr then searches not just file names but all metadata fields, including automatically generated tags.

AI auto-tagging works through a scheduler task that sends new files to an image recognition service (Google Cloud Vision, AWS Rekognition or a self-hosted model) and writes the detected tags into the metadata fields. The process runs asynchronously and puts no load on the backend. For the initial import of a large library, expect roughly 1 second per image for the API analysis.

Common problems and solutions

FAL index and file system drift apart. When files are uploaded via FTP or deleted manually, the FAL index no longer matches the file system. TYPO3 then shows files that do not exist, or does not know about files that do. The fix: run the FAL indexer regularly via the scheduler (we recommend nightly). The indexer reconciles file system and database. For 50,000 files, the reconciliation takes about 10-15 minutes.

Metadata lost during TYPO3 upgrades. Custom fields in sys_file_metadata survive TYPO3 upgrades when they are defined in a dedicated extension. If they are defined directly in the sitepackage’s TCA override file, they can be lost when the structure of the metadata table changes. The fix: always encapsulate image database fields in a small extension of their own, not in the sitepackage.

Backend performance with large folder trees. The File List module becomes sluggish from 1,000 files per folder, because it generates thumbnails for every image. The fix: set up a folder structure with no more than 500 files per directory and switch thumbnail generation in the file list to “on demand”.

Migration and version compatibility

TYPO3’s FAL has been part of the core since version 6.0 (2012) and evolves with every major version. The FAL API is stable: custom fields and indexers work from TYPO3 v10 to v13 without adjustments. The Solr FAL extension (EXT:solrfal) supports TYPO3 v12, and compatibility with v13 has been announced.

Migrating from an external DAM system to TYPO3 FAL means mapping the metadata, because every DAM system has its own data model. The migration itself is a database job: export from the DAM as CSV/JSON, map the fields to sys_file_metadata, import via the TYPO3 DataHandler or direct SQL.

The choice between extending FAL and adopting an external DAM comes down to two factors: library size and workflow complexity. Up to roughly 10,000 assets and without approval workflows, an extended FAL is sufficient. Beyond that, or with requirements such as automated license management and multi-channel distribution, a specialized DAM with a TYPO3 connector pays off. Gosign advises on both options and implements FAL extensions as well as DAM integrations.