Aedrian E.

Hi Peter D., the advice we have been given is to contact your Sigma Sales team, and they'll take it from there :)

Hi Peter D., thanks for your interest! I'm checking this internally and will get back to you with the steps to try the connector

Hi Mark T. and Henri K., the incident is resolved. The fix was applied at approximately 11:50 UTC, and database and share attach times in eu-central-1 have returned to normal levels. The degradation came from excessive load on an internal metadata service in the region, which slowed the step that opens a database when a new session or connection starts. Established sessions were largely unaffected, while new connections from the web UI, MCP, and the Postgres endpoint could be slow to establish or time out. Any query or connection that failed during the incident can be retried and should now succeed. We are continuing to monitor, and we are following up with preventative work, including alerting for this failure mode across all regions. Apologies for the impact this has caused on your workflow, and thank you for your patience.

Hi Henri K., our team is actively working on the issue, but we don't have an exact timeline to share. We'll post here if we do have an update on the fix

Hey aaran! We don't have information about migrations at the moment, but if you do run into issues while doing so, we are here to help!

This will have read access to your central DB because it's tied to your "central" service account - only read or rw?

The answer here is: it depends. If you use the default, it's going to use the MotherDuck Flights access token which has rw access. If you select a read scaling token, it would only have read access. But at the very least you're guaranteed read access.

do they need to be shared to central db or? - did not get this - central flight has rw token for each tenant db, but do tenant db need to be shared/attached to central service account also?

In how I envisioned the process, you won't need to attach the tenant db on the central service account. Please allow me to do a POC on this and I'll get back to you

and how provisioning works - can central flights create tenant db's? I also have app where tenants are initialy created - they need to flow somehow to motherduck for provisoning/scoping. App in the end has embedded dive, and should choose db that belongs to that users tenant

As for provisioning, once you have the tenant rw token you should be able to create the tenant db from within a flight. Please let me know if I'm missing something here

You're welcome! So on your "central" flight, you would have two sets of tokens

The tenant rw token would be used to write to the tenant database, but you'll still use the token that came with the flight to read from the central db. I think given your limitation that the tenants cannot access data from the central DB other than what they're scoped to, this is what I would recommend

In that case, the central flight would require write access to each tenant database so it needs to have a read/write token for each service account and stored as a Flight secret. When running the central flight, it would retrieve the secret to update the database tied to it

Hey Marin Š., glad it works now! As for your question, it seems you are trying to make the "central" service account update the data of the tenant databases, which are owned by different service accounts. Is that correct? Each tenant service account should have read access to the central DB, and they should then have a flight configured to update their respective databases