Proposal: database-first scaffolding support for Ecto ecosystem

[Syed Rohaan Alam]

I built a prototype Mix library called `ecto_database_first` that introspects an
existing PostgreSQL database and generates:

- Ecto schemas
- context modules
- optional migration snapshots
- a scaffold report with warnings and guidance

It also normalizes quoted/mixed-case PostgreSQL identifiers into valid Elixir
and Ecto code and supports configuration-driven execution from the consuming
application.

Motivation

There is a common need for teams adopting Ecto on existing databases to get a
clean, idiomatic starting point instead of hand-writing every schema and
association from scratch.

The goal is not just reverse engineering, but generation of maintainable code
that keeps querying inside contexts and surfaces schema issues in a report.

Question

Would the Ecto maintainers consider this kind of feature:

1. appropriate for `ecto`
2. more appropriate for `ecto_sql`
3. or better kept as a standalone Hex package in the Ecto ecosystem

Current scope of the prototype

- PostgreSQL introspection
- Ecto schema generation
- context generation
- association generation
- optional snapshot migrations
- scaffold report with schema guidance
- support for app config plus CLI overrides

Note:

I understand Ecto core is intentionally stable and selective about new
surface area, so I would appreciate guidance on whether this should be proposed
as a smaller integration point instead of a full upstream feature.

[Christopher Keele]

My intuition is that you'll be able to prototype much quicker outside Ecto (and its release cadence/stability support), and commitment to supporting multiple backends (adding to ecto_sql would imply it works for all sql backends).

That is to say, I can see a sufficiently polished and stable implementation maybe being considered for inclusion (if we think it is worth the increase the surface area of what Ecto maintainers must support), but until you develop your prototype to that level of stability, you're going to be happier iterating in a standalone library regardless.

[Syed Rohaan Alam]

Thank you for taking the time to read through my proposal and for the thoughtful feedback.

Your point about iteration speed and keeping this as a standalone library makes a lot of sense, especially in terms of avoiding unnecessary pressure on the Ecto core surface area.

Just to add context: I’m currently extending the prototype beyond PostgreSQL as well. I’m already working on support for other SQL backends, and I’m also experimenting with Oracle integration. The current repository is very much an MVP focused on proving the core idea of database-first scaffolding rather than a production-stable integration.

I appreciate your guidance — it helps clarify the direction I should take (especially keeping it modular and outside core Ecto for now).

Thanks again for the time and insight.