Hello.
I want to ask, how stable is the Advanced Visibility in postgres/other SQL in 1.20?
I see that is online, and in the docs, I see no indication that it is in beta
Here, and on other places.
However, when I go to releases page, I see that it is actually in beta.
Release v1.20.0 · temporalio/temporal (github.com)
The release notes on github releases is the only place where this feature is mentioned as “beta”.
How stable is this function? Is this recommended in production?
1 Like
As far as “stability” goes, the feature itself is stable to use, would note one issue found in forum post here specific to MySQL.
For production environments recommendation is still to use Elasticsearch if possible for now. Using SQL based persistence for advanced visibility will also depend on db size you have available so would consider this when making a decision especially for large use cases.
Thank you!
To make more clear what we need/want. We use Temporal, but we use Advanced Visibility features very rarely. We are fine with read operations taking long, as long as the write operations are fast.
We figured out the operational cost of managing ES is too high for us, taking into consideration we already do manage Postgres and have operations (backups, compliance, etc) around it set-up well. (We had a ES crash as I wrote here).
That being said, we are a bit scared to use something labeled as “beta” in production, if it’s in some way unstable and can cause the whole Temporal to behave undeterministic. (I don’t mean in Temporal terms 
just to behave weird.)
So the question for us is - is switching from visibility ES to Postgres generally safe, given that we use it very little, and we just want the rest of the app work fine.
One relevant question for the maintainers would be: if I start with advanced visibility on SQL, and then find later that my needs have changed and I need the additional performance of ElasticSearch, how hard is it to migrate from SQL to ES without losing historical data?