We just shipped Atlas v1.1 - The focus of this release is Database Security as Code and Declarative Data Management.
You can now declare database users, roles, permissions, and managed seed data as code - versioned, reviewed, and applied via CI/CD like schema changes.
Ariel from Atlas here. This setup is pretty common (declarative locally, versioned in real environments). Since migrations are auto-generated (by Atlas) on PRs, most developers never touch the versioned workflow directly.
I wrote a very rudimentary schema and automatic migration system for SQLite. One problem that I ran into recently was deploying changes that spanned two migrations, because the tool doesn’t know how to step through commits to do successive auto-migrations between schema versions. I guess there are rather obvious ways to handle this if you generate and then commit the full migration sql for each schema change. Nonetheless I’m curious if this is a problem you have had to think about, if you find it interesting or if it sounds like a bad path to go down, and if atlas does anything smart in this department. Thanks in advance!
Good point regarding ORMs - that was one of the main problems I wanted to tackle when we built Atlas (https://atlasgo.io). We added support for reading ORM definitions directly, then let you extend the "base schema" defined in them. For example, you can define your models in SQLAlchemy, EF Core, Ent, or others as a partial schema, and then extend it with functions, views, and additional objects.
From there, Atlas handles diffing, planning, and execution. This is similar to importing modules in TF, but for database schemas in Atlas. See this example: https://atlasgo.io/guides/orms/sqlalchemy
Liquibase does support rollback DDL with MySQL; I used it.
I put each DDL in a Liquibase changeset with a corresponding rollback DDL I constructed by hand. If the Liquibase changeset failed, I could run the rollback for all the steps after the "top" of my wish-I-could-put-them-in-a-MySQL-transaction operations.
But you are right MySQL itself doesn't support transactions for DDL and that is true whatever tool you use.
It is true that if you put multiple SQL operations in a single Liquibase changeset that are not transactional you can't reliably do rollbacks like the above.
It is also true that constructing an inverse rollback SQL for each changeset SQL by hand takes time and effort particularly to ensure sufficient testing, and the business/technical value of actually doing that coding+testing may or may not be worth it depending on your situation/use-case.
I'm @a8m's co-founder and also a maintainer of Atlas. I don't have an exact feature comparision but Atlas (and esp the Postgres driver) are heavily maintained with advanced features like views and materialized views (functions and procedures coming up, followed by triggers and more).
What features specifically are you missing in migra? Perhaps we can prioritize them. Also feel free to join our Discord https://discord.gg/zZ6sWVg6NT
Hey! For a long time, one of the most common feature requests we've been getting from our users is the ability to manage their desired "schema state" using SQL. For this reason, we're excited to announce the release of Atlas v0.9.0, which fully supports SQL.
We also released the Atlas Playground, where users can visualize their database schemas and plan migrations in an interactive way. Check out the example below and let me know what you think <3
Hey, I am the creator of entgo.io. I'm sorry to hear that your experience with the project was not great. I try to be available on our Discord, Slack, or the issue tracker, but sometimes I do miss some messages. If you ever consider to rejoin the community, please don't hesitate to drop me a message on our Discord.
I would also like to emphasize that Ent is an open-source project under the Linux Foundation, and it is not monetized in any way. Most of my work on it in the last years was on my free time, including when I was working at Facebook and wanted to OSS it. We (heavily) use Ent in our own products today, and that is why we continue to sponsor and maintain the project. I love it and I find it useful.
Just to emphasize, that OSS version of Ent models SQL tables in the traditional way (edges as foreign-keys and join-tables). i.e., the database structure is not obscure or something and can be easily read by developers and ported to other ORMs in case it's needed.
Happy to share with you the new version of Atlas, the terraform for databases and a migration engine.
There are many great features in this release, but one of the biggest features we added is multi-tenant support. Using this option, users can define, in a few lines of code, that a migration should be executed on N databases/environments.
Please, checkout the code examples in the link and share your thoughts on it. Your feedback is greatly appreciated.
You can now declare database users, roles, permissions, and managed seed data as code - versioned, reviewed, and applied via CI/CD like schema changes.
Feel free to share any thoughts or feedback.