[Feature]: Native DB creation + seeding support
@ascarter ci sta già lavorando.
Dal 11/8/2026.
Valutazione
Questa issue non è ancora stata valutata.
Descrizione
Use case
Developers spinning up the Azure SQL Database container locally (via docker run or docker-compose) currently get a bare database instance with no database. Teams using ORMs or migration tools expect the container to create an initial database and optionally seed it with schema/data on first boot — the same experience the official Postgres image provides via POSTGRES_DB and /docker-entrypoint-initdb.d. https://www.postgresql.org/docs/current/app-initdb.html
Current workaround
The only option today is to build and maintain a custom wrapper image on top of the official base image — for example, something that reads a DB_NAME-style env var to create a database on first startup, and mounts a host folder to /docker-entrypoint-initdb.d containing init/seed .sql scripts, with custom logic to track what's already been applied. Which is manageable but it isn't official, isn't documented, so it would be great to have an official image with this approach for the Azure SQL container.
Proposed behavior
- An env var (e.g. MSSQL_DATABASE) to auto-create a database on first boot, mirroring POSTGRES_DB
- Native support for mounting /docker-entrypoint-initdb.d, executing .sql (and ideally .sh) scripts on first startup against an empty data volume
- A defined convention for one-time vs. repeatable scripts, since this Azure SQL Database container doesn't have the same "empty data dir = first boot" simplicity Postgres has, and idempotency would need to be handled explicitly
- A container healthcheck that reflects "seeding complete," not just "engine is up"
Who benefits
All developers
Urgency
Nice to have
Additional context
As a developer, I want the Azure SQL Database container to natively create and seed a database on first run, so that I don't need to hand-roll a custom wrapper image.
As a developer setting up local/CI environments with Azure SQL Database in Docker
I want the container to support an env-var-driven database creation and a native init/seed script mechanism (like Postgres' docker-entrypoint-initdb.d)
So that I can get a ready-to-use, seeded database on first container startup without maintaining custom image tooling
Acceptance Criteria:
- Given MSSQL_DATABASE= is set and no volume-persisted data exists, when the container starts, then a database named is created automatically.
- Given a host folder is mounted to /docker-entrypoint-initdb.d, when the container starts for the first time (empty data volume), then all .sql scripts in that folder are executed against the created database, in a deterministic order.
- Given the container has already been initialized (persisted volume, previously run), when restarted, then init scripts are not re-run automatically.
- Given init scripts are applied, when checking container health, then the healthcheck reflects successful completion of seeding, not just engine availability.
- Given a script fails during initialization, when the container starts, then the failure is surfaced clearly in logs and the container does not report healthy.
- Lingua principale
- Shell
- Stelle
- 19
- Fork
- 6
- Merge medio
- 7h 24m
- PR unite (30g)
- 3
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di microsoft/azure-sql-database-container
-
Canonical recipes bind 1433 on all interfaces with the example SA passwordForse già presa @ascarter l’ha presa 20 giorni fa. Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 68/100
microsoft/azure-sql-database-container#163 · 1 commento · 1 assegnatario ·
-
[Bug]: BLOB STORAGE EXTERNAL DATA SOURCE causes A severe error occurred on the current command. The results, if any, should be discarded.Forse già presa @ericjulien l’ha presa 20 giorni fa. Apertabug needs-triage User-filled
Difficoltà 4/5 3-5 giorni Idoneità per principianti 44/100
microsoft/azure-sql-database-container#160 · 2 assegnatari ·
-
[Bug]: container images do not refreshed in almost 30 daysForse di nuovo libera @ericjulien l’ha presa 48 giorni fa e non c’è nessuna pull request aperta. Apertabug User-filled
microsoft/azure-sql-database-container#141 · 1 commento · 2 assegnatari ·
-
[Bug]: An error occurs when importing bacpacForse di nuovo libera @ericjulien l’ha presa 55 giorni fa e non c’è nessuna pull request aperta. Apertabug User-filled
microsoft/azure-sql-database-container#140 · 2 assegnatari ·
-
[Bug]: All the database names in `sys.databases` are set to “master”Forse di nuovo libera @ericjulien l’ha presa 48 giorni fa e non c’è nessuna pull request aperta. Apertabug needs-triage User-filled
microsoft/azure-sql-database-container#139 · 1 assegnatario ·
Tutte le issue di microsoft/azure-sql-database-container
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 67/100
-
bug
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 84/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
sclorg/s2i-ruby-container#660 · 1 commento ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
wazuh/wazuh-docker#2732 ·
I maintainer di solito rispondono entro 1 giorno
-
Route 53 DNS analytics/insights adds an observability signal for the DNS layerForse già presa Una pull request collegata a questa issue è aperta o già unita. Apertadocumentation enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100