Is it possible to manage the Elsa's collections by ourselves?

[Andrew-p32]

Elsa working with MongoDB with DBA.

1. Is it possible to manage the Elsa's collections by ourselves? Like creating them as part of CI/CD process?
2. Is it possible to set TTL for the items in the collection?
3. Based on having ~2600 workflows executed daily, can we estimate the number of reads/writes to Mongo?

[Nekrosis1]

In my experience with Elsa (we also use MongoDB), you can add and remove documents however you like (like with TTL indexes) and Elsa handles this well. Adding new definitions and instances and removing anything has never produced problems for me. I haven't done anything with bookmarks, this might not work as smoothly.
Reads and writes depend on your workflows, activities write to logs and definition_instances, so if your workflows have many activities, you will have more read/writes per workflow run.

[Andrew-p32]

Thank you for your message.
The question is that for work Elsa creates collections. I don't want Elsa to create them, I want to write a script to create collections and pass the created collections to Elsa. I would also like to set TTL on the workflow_instances and workflow_execution_logs collections.
Is this possible?
Can all this work without problems?

[Nekrosis1]

Okay, I understand what you would like to do. Unfortunately, I don't know if that is possible. Looking at modules/persistence/Elsa.MongoDB, I could not see an easy way.

[sfmskywalker]

There isn't a supported database-level migration path for carrying Elsa 2 workflow instances into Elsa 3.

The persisted instance and bookmark/state models are different enough that copying or transforming the tables directly would be application- and provider-specific, and we do not ship an automatic upgrader for them. That is also true for newer Elsa upgrades when their persisted state shape changes: see the current guidance in #7758.

Your parallel-run approach is therefore the safest one:

1. Start new workflows in Elsa 3.
2. Keep the Elsa 2 host and its persistence store available until its in-flight and suspended instances complete or are explicitly handled.
3. Migrate workflow definitions and host integration separately, and validate them before switching traffic.

If you must move in-flight instances, treat it as a custom migration project: test a copy of the persisted data, including related bookmarks, and validate resume behavior for every workflow shape you rely on. We cannot recommend a generic table-level conversion.