Peter K.

That would be awesome! Thanks!

Would be cool to have like an elasticsearch or redis backend option for the high volume use cases

We are probably a rare use case as we are a code review tool. That 700GB of spans is only 7 days of data for us (we have retention only to 7 days).

Seems better-ish? concurrently will use more CPU but it seems worth it

Ah ok. So it seems like if it did concurrently, nothing would change on startup except the existing instance wouldn't be hosed while the migration is running

We keep our phoenix version updated automatically so might just have to make that a manual process then for now I suppose

I would assume thats how would work for alembic as well since the postgres driver should just return when the index creation is submitted

Hrm I guess most of my experience is in rails but there, when you run concurrently, it moves to the next migration since concurrent is an async operation. Perhaps a thing to test

Ah, looks like it should be possible https://github.com/sqlalchemy/alembic/issues/277#issuecomment-2948601425

No problem! We've got it going now but just would be a nice rule on the PR check for cursor bot