When I started with my meltano deployment I didn't...
# best-practices
a
When I started with my meltano deployment I didn't have a separate systemdb, so used Azure for state store. Now I've seen the light, and moved to a system db. Is there any good reason to maintain a separate state store in Azure storage? Or is it just unnecessary complication?
v
all depends of course! They key in my opinion is to just pick one, then determine how critical it is and if you need to do backups / etc. In my use cases the systemdb failing and us starting from scratch would not be a big deal (as long as it's rare) so we don't worry about it
1
e
Now I've seen the light, and moved to a system db
I'm curious what your motivation was 🙂
a
Basically I never moved away from using sqlite. When I deployed in a container sqlite continued to work fine and I didn't mess with it. However, I got stuck in some situations where dagster interrupted a meltano run, and it got left in a 'RUNNING' state. So I wasn't able to start a new run via dagster as the old one was considered to be running, and I couldn't connect to the sqlite db in my container to mark the run complete. Moving systemdb to my postgres warehouse allowed me to end any runs which hadn't been terminated properly. and hopefully the upcoming changes to dagster-meltano will mean that sigkill/sigterm etc should get propagated to meltano correctly. The change was a lot simpler than I expected 🙂 had put it off for too long
e
nice!