<p>Creating a Docker image from a pre-populated database container — is not an anti-pattern. In fact, for your use case, it can be an efficient solution, especially when the data is static and read-only.</p>

CC BY-SA 4.0
2024-11-30T03:27:15.857Z
Thank you @qodirov-shohijahon - that is very helpful.  I'll see if I cannot optimize the pipeline this weekend.
Not a machine
CC BY-SA 4.0
2024-11-28T10:40:58.760Z
2024-11-28T10:40:58.760Z
Qodirov Shohijahon
<p>I have a small Docker container running a static (read-only) database which contains data for drop-down menus and web ui content such as counties per state, zip codes, etc.</p>
<p>The image is generated whenever the database content is changed via a commit pipeline. Currently, the database tables are populated when the container first starts using SQL scripts I created in docker-entrypoint-initdb.</p>
<p>So far, this is working well. However, there is a container startup cost associated with running the initdb scripts and I am considering starting the container as part of the pipeline and then creating an image from the container once the database tables are populated.</p>
<p>Is this a container anti-pattern? It feels a little unnatural from a pipeline/container perspective but it would allow containers to spin up faster and be purely stateless.</p>
<p>I strongly prefer not to use a volume for this application as it really isn’t needed and it adds complexity to the deployed application.</p>

<docker>
Optimizing a containerized database initialization and startup
Not a machine
# Optimizing a containerized database initialization and startup

(Asked by: username_0 on 2024-11-27)

I have a small Docker container running a static (read-only) database which contains data for drop-down menus and web ui content such as counties per state, zip codes, etc.

The image is generated whenever the database content is changed via a commit pipeline. Currently, the database tables are populated when the container first starts using SQL scripts I created in docker-entrypoint-initdb.

So far, this is working well. However, there is a container startup cost associated with running the initdb scripts and I am considering starting the container as part of the pipeline and then creating an image from the container once the database tables are populated.

Is this a container anti-pattern? It feels a little unnatural from a pipeline/container perspective but it would allow containers to spin up faster and be purely stateless.

I strongly prefer not to use a volume for this application as it really isn’t needed and it adds complexity to the deployed application.

**Tags:** docker


---

## 1 answers

### Answer by username_1 on 2024-11-28. Score: 1

Creating a Docker image from a pre-populated database container — is not an anti-pattern. In fact, for your use case, it can be an efficient solution, especially when the data is static and read-only.

> **Comments:**
> **username_0**: Thank you @qodirov-shohijahon - that is very helpful.  I'll see if I cannot optimize the pipeline this weekend.  

---

