Atlas is quite nice. I recently started using it in a typescript/node.js project (which was using liquibase before) and I find the DX to be great.
Primary additional feature I wish it had is support for manual migrations in addition to declarative hcl. So it would be great if I could have a unified changelog or migration list where some of the migrations were autogenerated from the diff in hcl and others were manually written (for things the hcl doesn't current support like procs and triggers) and I could rollback them together if needed.
I also wrote a simple code-generator[1] for typescript & zod to prevent having to duplicate the row types between atlas and ts, which others may find useful. It's still pretty early stage though.
I am working on versioned migrations right now and you can expect the first release in the near future.
We will allow users to specify a migration directory where Atlas will create migration files you can edit manually. We want to support existing well working tools like golang-migrate or Flyway as well, where you can easily add your own migrations files.
If you have any further question, I am happy to answer them!
M
Going through the readme and the homepage still left me asking "What exactly does it do?". Going through the readme, their home page, and this blog post (https://blog.ariga.io/meet-atlas-cli/), here's a tldr;
It's terraform, but for database.
- It allows defining SQL database schema in HCL (terraform's DSL) for now.
- It can inspect a database and create the HCL for it.
- It can do database migrations similar to terraform. You define the new schema in HCL, and it allegedly takes care of producing the SQL needed to perform the migration. It also has a "plan" step like Terraform.
---
I hope I didn't missunderstand or missed something.
Hey bitspook!
One of Atlas’s creators here.
Thanks for sharing this!
You describe the existing state well. Atlas can currently be used to perform what we call declarative database migrations.
This is great for many use cases. But it will not do for others, for a few reasons .
First, there are many ways to get from point A to point B. The classic example is a table rename. To get from the existing to the desired state, we can either ALTER TABLE or DROP and CREATE it. What did the user mean? Second, migrations are a very sensitive operation that can easily result in an outage if done wrong. Therefore, many companies check each migration into source control and have it reviewed in CR, and perform different quality and safety assessments on it.
Therefore, while “terraform for DBs” sounds great, it’s not enough. In the next versions of Atlas, we’re rolling out a different workflow that we call migration authoring or “versioned migrations” that address these issues in a very cool way that I hope many will view as useful.
It would be great if you could plug in other configuration frontends. I'd love to be able to just define a proto and have this manage database schemas for me.
Hey gravypod!
Thanks for writing. Indeed we built the schemaspec implementation so that it’s definitely possible to use other syntaxes to define schemas. HCL was chosen for various reasons to be first but we are planning on supporting others
Primary additional feature I wish it had is support for manual migrations in addition to declarative hcl. So it would be great if I could have a unified changelog or migration list where some of the migrations were autogenerated from the diff in hcl and others were manually written (for things the hcl doesn't current support like procs and triggers) and I could rollback them together if needed.
I also wrote a simple code-generator[1] for typescript & zod to prevent having to duplicate the row types between atlas and ts, which others may find useful. It's still pretty early stage though.
[1] https://github.com/lorefnon/atlas2ts