iasql

you write are SQL statements to mutate your infrastructure rather than editing a declaration file, which is a different mental model vs IaC. But you gain from the constraints and foreign key relations on tables to catch mistakes in configuration before execution even happens to a greater degree than IaC tools can as this is like a "type safety" on top of dynamic information (other tables you depend on). Third, you can enter an IaSQL transaction (slightly different from a normal Postgres transaction as you can't hook function calls on `BEGIN` and `COMMIT`) to make these changes and inspect what IaSQL will do like you can with IaC tools, but if there is a failure, the `iasql_commit` will take the information from the audit log and roll back the changes that were applied by applying the prior versions in reverse, so IaSQL should always be in a working state. Finally, (since this is getting long) the live-infra data model of IaSQL makes dynamic infrastructure much simpler (eg, you deploy isolated instances of your services per customer) -- anything with a SQL client and credentials for the IaSQL database can connect and initiate these changes, which can be Postgres stored procedures you write and added to the database. We're in beta so our coverage is not as large as existing IaC tools, but we now cover 25 different AWS services with our modules: https://iasql.com/docs/modules/ But please let us know if there's something you use that's missing. :)