Docker Persistence: When and How to Keep Your Container Data

Farouk BENNACEUR — Sat, 09 Aug 2025 16:14:05 +0000

Containers are designed to be lightweight, fast, and ephemeral by nature. But what happens when your app needs to retain data between restarts or share files with other containers? That’s where Docker persistence comes in.

A container is considered disposed (or removed) when it is explicitly deleted with docker rm, or when it's started with the --rm flag and stops running. In both cases, any data written inside the container that is not stored in a volume will be lost.

🔢 When Should You Persist Container Data?

✅ Persist Data When:

Your application generates data that must survive container restarts (e.g., database data).
You want to share data between containers.
You need to back up or migrate container data.

❌ Do Not Persist When:

The container is stateless (e.g., an API service, a compute worker).
You need temporary cache or test data.
You want to ensure full isolation and reproducibility.

Persisting unnecessarily can lead to data bloat, complexity, and coupling between host and container.

📁 Docker Volume Types and Use Cases

Docker provides several ways to manage persistent data. Here are the main volume types:

1. Named Volumes (Managed Volumes)

Created by Docker and stored in its internal directory (e.g., /var/lib/docker/volumes).
Portable and easy to back up.

Use When:

You want durable data without caring about host path details.
Running databases, persistent app data.

docker volume create my_data
docker run -v my_data:/app/data my_image

2. Bind Mounts

Mount a specific path on the host into the container.
Allows real-time access to host files.

Use When:

You need to edit files from your host (e.g., during development).
Config files need to be versioned on the host.

docker run -v /path/to/config:/app/config my_image

3. tmpfs Mounts

Stored in RAM, lost when the container stops.
No disk I/O, high-speed access.

Use When:

You need fast access to sensitive or temporary data like passwords.

docker run --tmpfs /run/cache:rw my_image

✅ Final Thoughts

Not every container needs persistent storage. But when it does, Docker gives you flexible, powerful tools:

Use named volumes for standard persistent data.
Use bind mounts for full control and local development.
Use tmpfs when speed or security is a priority.

Manage them wisely, and your containers will be both clean and capable.

SQL Execution Order: What Really Happens Under the Hood

Farouk BENNACEUR — Sat, 12 Apr 2025 22:13:24 +0000

If you’ve ever written SQL queries and wondered why sometimes things don’t behave as you expect —or why certain clauses must come before others— you’re not alone. SQL can feel a bit weird at first because the way we write queries isn't the way SQL executes them. Let’s unpack this.

syntactical Order vs Execution Order

When we write SQL, we often write it in this order:

SELECT column1, column2
FROM table
JOIN another_table ON ...
WHERE condition
GROUP BY column1
HAVING condition
ORDER BY column2
LIMIT n

This is the syntactical order. But it’s not the order in which the database actually processes the query.

Here’s the execution order in which SQL evaluates a query:

FROM and JOIN
WHERE
GROUP BY
HAVING
SELECT
DISTINCT
ORDER BY
LIMIT / OFFSET

Each step builds on the result of the previous. So for example, WHERE can only filter rows that exist after the FROM clause has brought them in, but before any grouping or aggregating happens.

Why Execution Order Matters?

Let’s look at a few examples that highlight why this execution order is critical.

Example 1: Alias Not Recognized in `WHERE`

SELECT salary * 1.1 AS increased_salary
FROM employees
WHERE increased_salary > 50000;

❌ This will throw an error!
Why? Because WHERE is evaluated before SELECT. So the alias increased_salary doesn't exist yet when WHERE runs.

✅ Fix:

SELECT salary * 1.1 AS increased_salary
FROM employees
WHERE salary * 1.1 > 50000;

Alternatively, use a subquery or CTE if you really want to reuse the alias:

WITH temp AS (
  SELECT salary * 1.1 AS increased_salary
  FROM employees
)
SELECT *
FROM temp
WHERE increased_salary > 50000;

Example 2: `HAVING` Before `SELECT`

SELECT department, COUNT(*) AS total
FROM employees
GROUP BY department;
HAVING total > 5

❌ Again, this doesn’t work! The total alias doesn't exist at the time the HAVING clause is executed.

✅ Instead, we need to re-write the aggregation:

SELECT department, COUNT(*) AS total
FROM employees
GROUP BY department
HAVING COUNT(*) > 5;

In practice, some modern DBMS (like MySQL and PostgreSQL) allow you to reference aliases from the SELECT clause inside the HAVING clause as a convenience, even though it's not part of the strict syntactical order.
So the above example will work in many databases. However, this is not guaranteed by the SQL standard and not supported by all DBMS (e.g., SQL Server might not allow it). So it’s better to be cautious.

Best Practices Based on Execution Order

To avoid common SQL pitfalls, keep these tips in mind:

1. Don’t reuse SELECT aliases in WHERE or GROUP BY.
Use the full expression or refactor using a subquery or CTE.

2. Use CTEs (WITH clauses) for readability and reuse.
They're evaluated like subqueries and can help avoid aliasing issues.

3. Remember, WHERE filters rows before aggregation.
Use HAVING to filter after aggregation.

4. Use aliases safely in ORDER BY (always) and HAVING (with caution).
While many DBMS allow alias use in HAVING, it’s not standard-compliant. For portability and clarity, prefer reusing the expression or using a subquery/CTE.

5. Think like the engine.
Understanding the execution order helps debug tricky issues and write cleaner, more efficient queries.

Final Thoughts

SQL might look like it reads top to bottom — but under the hood, it’s a well-orchestrated sequence of operations. Understanding the processing order helps you write smarter queries, avoid confusing errors, and better leverage the power of SQL.

What other SQL mysteries have tripped you up? Let’s chat in the comments 👇

DEV Community: Farouk BENNACEUR

Docker Persistence: When and How to Keep Your Container Data

🔢 When Should You Persist Container Data?

✅ Persist Data When:

❌ Do Not Persist When:

📁 Docker Volume Types and Use Cases

1. Named Volumes (Managed Volumes)

2. Bind Mounts

3. tmpfs Mounts

✅ Final Thoughts

SQL Execution Order: What Really Happens Under the Hood

syntactical Order vs Execution Order

Why Execution Order Matters?

Example 1: Alias Not Recognized in WHERE

Example 2: HAVING Before SELECT

Best Practices Based on Execution Order

Final Thoughts

Example 1: Alias Not Recognized in `WHERE`

Example 2: `HAVING` Before `SELECT`