Module 4.3 – Data Storage & Retrieval

This module explains how and where data should be stored in Drupal, using a very simple mental model, real Drupal code, and Acquia exam scenarios.

If you understand this module, you will avoid one of the most common certification failures: choosing the wrong storage system.

Not all data is the same, so it should not be stored the same way.

Drupal gives you three main storage systems:

1. Entity API
2. Configuration API
3. Database API

Choosing the correct one is what Acquia tests.

Big-picture decision table (exam-critical)

If you remember only this table, you will pass many questions.

1. Entity API (Primary and Preferred)

What Entity API is

The Entity API is Drupal’s official system for storing structured content.

Examples of entities:

• Node (content)
• User
• Taxonomy term
• Media
• Custom entities

Simple explanation

An entity is like:

• A form
• A database row
• Rules (validation + access)

All bundled together.

Why Acquia loves Entity API

• Built-in access control
• Built-in caching
• Language support
• Revision support
• Works across environments

Real Drupal example: Load an entity

$node = \Drupal::entityTypeManager()
  ->getStorage('node')
  ->load(1);

What happens:

• Drupal checks permissions
• Drupal uses cache
• Drupal loads data safely

Create and save an entity

use Drupal\node\Entity\Node;

$node = Node::create([
  'type' => 'article',
  'title' => 'My Article',
]);
$node->save();

Real scenario (exam-style)

Scenario: You need to store blog posts that editors can translate and revise.

Correct answer: Entity API

Wrong answers:

• Custom database table
• Configuration API

2. Configuration API (Settings, not content)

What Configuration API is

Configuration API stores site settings, not user content.

Examples:

• API keys
• Feature toggles
• Module settings
• Default values

Simple explanation

Config is like settings in your phone, not photos or messages.

Why Config API exists

• Exportable (YAML)
• Environment-safe (dev → prod)
• Immutable or editable

Real Drupal example: Read config

$config = \Drupal::config('my_module.settings');
$api_key = $config->get('api_key');

Write config (editable)

$config = \Drupal::service('config.factory')
  ->getEditable('my_module.settings');
$config->set('enabled', TRUE)->save();

Real scenario (exam-style)

Scenario: Store a module setting that enables or disables a feature.

Correct answer: Configuration API

Wrong answers:

• Entity
• Database table

3. Database API (Last resort)

What Database API is

Drupal’s abstraction layer for custom tables.

Use only when:

• Data is not content
• Data is not configuration
• Data is technical or temporary

Simple explanation

Database API is for logs, queues, mappings, not content.

Real Drupal example: Select query

$results = \Drupal::database()
  ->select('my_table', 'm')
  ->fields('m')
  ->execute();

Why Database API is dangerous if misused

• No automatic access checks
• No translations
• No revisions
• No caching metadata

Real scenario (exam-style)

Scenario: Store temporary sync logs from an external API.

Correct answer: Database API

Wrong answers:

• Entity
• Config

Comparing all three (easy memory trick)

Security considerations (Acquia focus)

• Entity API enforces access checks
• Config API avoids hardcoding secrets
• Database API must be sanitized manually

Exam trap: Writing raw SQL for content data

Performance considerations

• Entity API uses caching
• Config API is lightweight
• Database API can be slow if misused

Correct optimization:

• Cache entity loads
• Avoid repeated queries

Common Acquia exam traps (Module 4.3)

• Using Config API for content
• Using Entity API for settings
• Using raw SQL instead of APIs
• Creating custom tables unnecessarily

Final takeaway (one sentence)

Content goes into entities, settings go into config, technical data goes into the database.

If you follow this rule, you will almost never choose the wrong answer.