Optimizing a containerized database initialization and startup

Question

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.

Answer 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.