Hi manigandham! One of Atlas's creators here. Thanks for the feedback! I completely understand your point here, and I would add that for many use cases the de

Hi manigandham! One of Atlas's creators here. Thanks for the feedback! I completely understand your point here, and I would add that for many use cases the declarative approach isn't robust enough for schema migrations. The classic example being, how does a tool discern between a column drop/add and a rename, and how does the migration tool allow for backward-compatible schema evolution? For this reason, as you can see on https://atlasgo.io https://atlasgo.io, we are going to publish to the CLI a different style of migration which we call "versioned migrations", that support the process of "migration authoring". This already exists in the Go API so if you want to delve into it on your own you can, but it will be out as part of the CLI really soon. Migration authoring means that you modify your desired schema, and the tool generates a possible migration for you. In cases where there is ambiguity (multiple ways to reach state B from A), the tool may interactively prompt you for decisions. So hopefully with Atlas you can get the best of both ways. Have an intelligent engine help you author the migration for you, but ultimately you get an SQL file you can edit, review in CR, and use your existing migration tools with (Flyway, Liquibase, etc.) Feel free to join our discord channel (https://discord.com/invite/QhsmBAWzrC https://discord.com/invite/QhsmBAWzrC) if you want to chat more :-) R