diff --git a/develop-docs/backend/application-domains/database-migrations/index.mdx b/develop-docs/backend/application-domains/database-migrations/index.mdx
index 2d141229f9de8..79d5ed7395764 100644
--- a/develop-docs/backend/application-domains/database-migrations/index.mdx
+++ b/develop-docs/backend/application-domains/database-migrations/index.mdx
@@ -135,11 +135,12 @@ generally prefer that, since it averages the load out over a longer period of ti
 
 ### Indexes
 
-We prefer to create indexes on large existing tables with `CREATE INDEX CONCURRENTLY`. Our migration framework will do this automatically when creating
-a new index. Note that when `CONCURRENTLY` is used we can't run the migration in a transaction, so it's important to use `atomic = False` to run these.
+These are automatically handled by the migration framework, you can just create them on the Django model and generate the migration.
 
 When adding indexes to large tables you should use a `is_post_deployment` migration as creating the index could take longer than the migration statement timeout of 5s.
 
+Note: These are created using `CONCURRENTLY`, so it's important to not set `atomic = True` for migrations that contain indexes. This is disabled by default.
+
 ### Deleting columns
 
 This is complicated due to our deploy process. When we deploy, we run migrations, and then push out the application code, which takes a while. This means that if we just delete a column or model, then code in sentry will be looking for those columns/tables and erroring until the deploy completes. In some cases, this can mean Sentry is hard down until the deploy is finished.