Database Best Practices for Drupal

In addition to the issues we’ve explained in our general Database Best Practices guidance, Drupal has its own set of database patterns that can cause trouble at scale. The watchdog table is the most common offender, but there are others to watch.

The watchdog Table

Drupal’s database logging module (dblog) writes log entries to the watchdog table. On a busy site, this table can grow to millions of rows surprisingly fast.

Why It Gets Out of Control

By default, Drupal logs notices, warnings, and errors—sometimes even debug messages depending on your configuration. Every PHP notice, every 404, every form validation error gets a row in the database.

Unlike syslog, which rotates and expires old entries automatically, the watchdog table just keeps growing. There’s no built-in cleanup unless you configure it explicitly.

The Performance Impact

A bloated watchdog table causes problems in several ways:

• Admin pages slow down: The logging reports page has to query a massive table, often timing out entirely.
• Write contention: On high-traffic sites, constant inserts to watchdog compete with other database operations.
• Backup size and time: A watchdog table with millions of rows significantly increases backup duration and storage costs.
• Overall database performance: Large tables with frequent writes can affect query planning and index performance across the entire database.

What to Do

A few options to keep watchdog under control:

• Reduce the log level: In production, you rarely need notices or debug messages. Configure Drupal to only log warnings and errors.
• Set a row limit: Drupal can automatically trim the watchdog table to a maximum number of entries. Configure this under “Logging and errors” in the admin interface.
• Switch to syslog: For high-traffic sites, consider using the syslog module instead of dblog. This writes logs to the server’s syslog facility, which handles rotation and retention automatically.
• Clean up manually: If the table has already grown too large, truncate it or run batched deletes as described in the Table Purging section of our general Database Best Practices guidance.

Other Drupal Tables to Watch

Beyond watchdog, keep an eye on these:

• sessions: Drupal creates session records for anonymous users by default. On high-traffic public sites, this table can grow rapidly. Consider whether you actually need anonymous sessions, or configure more aggressive session garbage collection.
• flood: This table tracks rate limiting for login attempts and other protected actions. It should be cleaned up by cron, but can grow if cron isn’t running reliably.
• cache_* tables: Drupal uses multiple cache tables. If cron isn’t running regularly, expired cache entries accumulate. Make sure cron is scheduled and completing successfully.