feat(db): add migrations folder support to load SQL files via .Files.…

[saidtaylan]

This PR adds support for loading database migration files from a migrations/
folder within the chart directory, making it easier to manage large migration
SQL files without embedding them in values.yaml.

Changes:

• Modified templates/db/migration.config.yaml to use .Files.Glob pattern for
  dynamically loading *.sql files from migrations/ directory
• Maintained backward compatibility with existing db.config in values.yaml
• Added migrations/.gitignore to exclude SQL files from version control
• Bumped chart version

Migration files are now automatically loaded alphabetically from the migrations/
folder and mounted into the database init container, executing during initial
database setup alongside the existing init scripts."

[luizfelmach]

Hi @saidtaylan,

I really like the idea, but I have one concern: if in the future we decide to publish and maintain this Helm chart in a registry, wouldn’t this approach become a limitation? As far as I understand, in that case users wouldn’t be able to use it this way. Or am I missing something?

That said, I do like this approach a lot for running and keeping migrations up to date, especially following the pattern used here:
https://github.com/supabase/supabase/tree/master/docker/volumes/db

What do you think?

[saidtaylan]

Good call on pointing this out. I ended up agreeing that loading migrations directly from the chart would become limiting once this is treated as a reusable, registry-published chart.

I’ve pushed a follow-up commit that changes the approach accordingly. The chart no longer carries migration files itself; instead it expects migrations to be provided via an external ConfigMap, and only handles mounting and execution.

In practice, migrations are created by the user from their local SQL directory, for example:

kubectl create configmap supabase-migrations \
  --from-file=./migrations

The chart then just takes a reference like:

migrations:
  enabled: true
  existingConfigMap: supabase-migrations

and mounts it into the init container:

volumes:
  - name: migrations
    configMap:
      name: {{ .Values.migrations.existingConfigMap }}

with a simple runner that executes the SQL files in order.

This keeps the chart registry-friendly and reusable, while still following the same file-based migration pattern you referenced from Supabase — migrations live outside the orchestration layer, the chart just runs them.

Curious if this aligns with what you had in mind.

[luizfelmach]

Hi @saidtaylan.

I’ve reviewed your changes and have a few questions.

I believe mountPath does not need to be configured. This is because any value will not affect the final result, and the user may configure a value that could conflict with existing ones.

The appVersion field had a " character removed in Chart.yaml. Please fix this.

I believe db.migrations.enabled in values.yaml should be by default false.

Just to confirm: do the changes in migration.config.yaml still need to be committed to the repository, or should this file be treated as generated?

The idea of having the files separated makes me very excited about potentially replacing initdb.config.yaml to keep the files split. I believe this could be a change to consider in the future, possibly in a new PR.

[saidtaylan]

@luizfelmach sorry for I am late.
migration.config.yaml file is optional to push to the repo sake of backward compatibility.
I didn't consider replacing with initdb. But this is sensible.

Also migration.config.yaml is optional to push to the repo. Maybe it will be redundant. It can be deleted.

I agree. The PR will be in the future

Thanks