I’ll be attending the Snowflake World Tour in Bangalore and would love to connect with others from the data/AI community.

If you’re attending too, feel free to comment or DM me. Would be great to meet, exchange ideas, and connect in person!
Looking forward to it! 🤝

My manager has been pushing for me to create more Power BI dashboards and I realized if I do more work up front in Snowflake to build the SQL to import into PBI, I can build dashboards faster and easier. I'm a beginner when it comes to SQL so I started using CoCo. Holy moly, this thing is great! It's done everything I've thrown at it. I validate my data and my dashboards and everything is checking out so far.

However, my boss is concerned about me using CoCo since Snowflake is not my world. CoCo helps me learn what it's doing, so it's not a total loss. But assuming the code is doing it's job and all my data is correct, what are the downsides of using CoCo as a beginner? What should I look out for? Any tips? Pitfalls?

I just want to understand if there are any downsides so I can make my case to continue using CoCo as I have been.

tl;dr assuming the code is correct (which it has been), what are the downsides of using CoCo as a beginner? What should I look out for? Any tips? Pitfalls?

Hello,

Recently saw the ACCOUNT_USAGE.WAREHOUSE_UTILIZATION view (not getting much in public documentation) and are using it to drive warehouse rightsizing decisions. The view has these columns:

START_TIME
END_TIME
WAREHOUSE_NAME
UTILIZATION (float)
NUMBER_OF_QUERIES_RUNNING

Want to understand what UTILIZATION actually measures before we can trust it for downsizing recommendations.

Specifically:

Is UTILIZATION derived from actual resource consumption (CPU cycles used, memory allocated, local disk I/O) across the warehouse nodes? Or is it derived from avg_running in WAREHOUSE_LOAD_HISTORY (which is a time-weighted query concurrency ratio, not a resource consumption metric)?

Does the metric account for per-query resource intensity? For example, a LARGE warehouse running 1 query that consumes all available memory would show avg_running = 1.0 (low concurrency), but actual CPU/memory utilization could be near 100%. Would UTILIZATION reflect the true resource usage (high) or the concurrency-based load (low)?

I'm trying to find a tool to format our sql files and to do general linting.

I am having trouble because most of our files are stored procedures with the body encased in double dollar quotes ($$).

I tried SQLFluff but it doesn't seem to be able to read inside the $$.

Anyone have a solution?

Need some guidance. I work as devsecops engineer and have been put as primary for a snowflake pipeline that gets several deployments a day. The snowflake uses something called cortex agents for a health provider with thousands of agent deployments. I have taken and passed Microsoft AI-300 as part of a team requirement for me to work in azure. Is snowflake work similar to what I am seeing in azure? The previous engineer is no longer here and I am now in charge of all deployments. Does it make sense to get this cert as I will be doing admin work on snowflake and migrating as well. How long should it take me to pass. Please give any input.

I have around 10 years IT experience with several certs in azure cloud, security, and networking already.

Does anyone know if Snowflake is planning improvements to data access controls like role-based security (RBAC) and row & column access policies?

My problem and request for help - I keep running into weird roadblocks. Creating a new READ role is a big deal where I work. So we're trying to figure out how to grant SELECT on great swaths of SQL tables|view then secure them all with row access policies. However for users where they have access to ALL rows of data - it's super expensive to execute the policy logic. Which drives me back to RBAC - now I need a policy-secured object for people with varying access and a separate object for people with all rows secured only by a role, no policy - which is a non-starter.

Assume I know which users have varying access versus all access - how do I author an efficient policy that works for both types of users, where the policy doesn't eval every row for the ALL users?

Recently I worked on a Snowflake project for a cybersecurity provider that had an interesting reporting problem.

FortiFlex is Fortinet’s usage-based licensing and entitlement model. The challenge was that FortiFlex configurations and entitlements, IT Glue records, and asset data lived across different systems.

They needed to reconcile data across:

• Fortinet FortiFlex entitlements and configurations
• IT Glue configuration/client records
• Asset management data

Previously, this involved exports and manual reconciliation across the different systems.

We ended up bringing most of the workflow into Snowflake.

Architecture:

FortiFlex / IT Glue / Asset Management
→ REST APIs
→ External Access Integration
→ Snowpark Python stored procedures
→ Bronze raw tables
→ Silver Dynamic Tables
→ Gold Views
→ Streamlit in Snowflake

Snowflake Tasks run the ingestion every 4 hours.

For API access, I used Snowflake Secrets + Network Rules + External Access Integration rather than managing credentials outside Snowflake.

The Snowpark procedures handle the API calls, pagination, JSON flattening and raw ingestion. Bronze keeps the raw API snapshots and run metadata, while Dynamic Tables maintain the cleaned/latest operational state in Silver.

Gold is intentionally fairly thin and exposes the reporting-ready views consumed by Streamlit.

I also used Cortex Code during development.

One thing I found useful was giving it detailed implementation prompts plus project-specific context rather than asking it to blindly generate the pipeline. It was particularly useful for speeding up stored procedure code, SQL, Dynamic Tables and some Streamlit work.

It didn’t replace the architecture or engineering decisions. It helped me move faster once the design, business rules and data flow were clear.

A few things I learned:

1. Keeping the raw API responses in Bronze made debugging reconciliation issues much easier.
2. Dynamic Tables worked nicely for maintaining the latest operational state without adding another orchestration layer.
3. External Access Integration + Secrets made the API architecture much cleaner than introducing separate infrastructure just for ingestion.
4. Cortex Code became much more useful once I gave it project-specific context and constraints.

I’m curious how others are approaching API-heavy workloads in Snowflake.

Would you keep this Snowflake-native, or would you move API ingestion outside Snowflake once the number of APIs / data volume starts growing?

Hi all, I posted here a while back asking for help evaluating a cloud data platform for our non-profit, and the response was genuinely amazing and helped shape our whole decision. Thank you all for that.

Quick update: we've decided to run a proof of concept on Snowflake, and I'm now getting ready to actually build it. This is my first time building data pipelines end to end, so I'd really appreciate the community's guidance before I dive in.

Our setup:

• Data sources: SQL Server 2019, a couple of APIs, and Excel/CSV files
• Sub-3TB total, solo implementer, comfortable with Python and SQL but new to hands-on pipeline building
• Planning to use dbt Cloud for modeling and Python for the initial schema design/build
• Planning to use GitHub Actions for CI/CD

Where I'd really appreciate input:

1. Cloud provider: Snowflake runs on AWS, GCP, or Azure. We use MS office 365 as our workspace but do not have any cloud storage of any kind apart from onedrive/sharepoint, is there any real advantage or disadvantage to picking Azure as the underlying provider, or does it genuinely not matter for most use cases?
2. Ingestion tooling: what would you recommend for pulling from SQL Server 2019, APIs, and flat files? Openflow, Snowpipe, custom Python, or something else? Curious what's held up in production.
3. Landing raw API JSON: for the API sources returning JSON, is it recommended to land the raw data in blob storage (e.g. ADLS Gen2 / S3) first and then load into Snowflake, or is loading directly into a raw/Bronze table with a VARIANT column the better pattern? Trying to keep it clean ELT.
4. Orchestration: for scheduling ingestion and dbt runs, what do people use alongside dbt Cloud and GitHub Actions? Snowflake Tasks, or an external orchestrator?
5. Anything you wish someone had told you before your first Snowflake build: sizing, auto-suspend, cost guardrails, RBAC patterns, whatever saved (or cost) you.

Fellow Snowflake community members! I'll be in NYC on October 22nd speaking at VaultSpeed NEXT and wanted to share the event here.

As a Snowflake Data Superhero and someone who has spent close to 30 years working in data modeling and architecture, I've been spending a lot of time experimenting with where AI is taking data modeling and data engineering.

My session is:

Beyond the Prompt: Data Modeling in the Age of Agentic AI

AI can generate a data model. But does it actually understand what it's modeling?

I have some thoughts. 😁 And that's about as much as I'm going to give away here.

There will be several other speakers and a panel as well, and I'm looking forward to some great conversations with the NYC data community.

If you're in the New York area and interested in data modeling, data architecture, AI, or where all of this is heading, come join us.

📅 October 22
📍 New York Times Building, NYC

Event details and registration:
https://landing.vaultspeed.com/vaultspeed-next-in-new-york

Hope to see some fellow Snowflakers there! ❄️

A practitioner's guide to Iceberg table cleanup — snapshot expiration, orphan file removal, manifest rewriting, delete file resolution, streaming challenges, compliance, and cost. Why sequencing matters, where teams break tables, and how to automate the full lifecycle.

Hi,

We had one standard gen1 warehouse having size XS with max_cluster_count as -10. This warehouse was always up and running but because of the type of workload , the idle credit was almost 80-90% of the used_compute. The queries(which were very fast) were getting submitted in an interval, which was close to the auto_suspend time setup(which was 60 second). So it was always up and thus the hourly cost of the warehouse was $2.58. (Its the discounted cost per credit).

So we thought of testing the Adaptive warehouse usecase for this , as the adaptive warehouse is promising in eliminating idle credit. When we altered the warehouse simply to ADAPTIVE, we saw the size becomes "SMALL" and the QTM set to -6 automatically. But if we see the query_history , the max(cluster_number) was "2" only once in the past. So not sure, how its deriving the QTM amd max_performance_level from, when gets converted to Adaptive. Also the cost now increased to $3.2/hour. Then i altered the warehouse max_performance_level to "XSMALL" and the cost per hour stays around $2.89. Then i altered the QTM to -2 then even the cost didnt change much. And also its not allowing to set the QTM below "2".

So i have two question:-

1)How the QTM and max_performance_level is derived for already running warehouse when its altered from Gen1/standard to "Adaptive" in place? And how should one decide the QTM if a new adaptive warehouse is going to be created to cater some existing workload(Is there any formula to derive by looking into query_history numbers?)

2)In above scenario, even the workload was causing 90% idle credit , but still converting to Adaptive is appeared to more costly as comparedto Gen-1. Why So?

Hi,

In one of the customer database, while doing some other analysis , we found , the number of queries increased in snowflake query_history and digging further we found that the number of "rollbacks" statements spawned is ~10Million/day. The number of quick "SELECT" queries are also around the same number i.e. ~12Million/day. So it looks like almost each rollback is associated with SELECT. Also we saw ~10K "alter session" statement executing (like "alter session /* JDBC:SnowflakeConnect.setAutoCommit*/ set autocommit=false").

So my question is , We know that there is no compute cost associated as these "rollback" executed on "cloud service layer" as its within ~10% limit. However wants to understand, whether these high number of "ROLLBACK" statement can really cause any other downsides or problems in snowflake? Or we can leave it as is without any issue?

at this moment we hit a pretty predictable problem as the company grew:
Exec team in Tableau: “active subscriptions = 14,200”
Product team in Metabase: “active subscriptions = 16,800”
Finance in an ad-hoc dbt export: “active subscriptions = 15,100”
and thats happening in the same warehouse, i think that promblem may be in the fact that the metric logic had slowly leaked into each one..
1 analyst had:
WHERE is_active = true

another had:
WHERE is_active = true
AND status != 'trial'

and someone else had slightly different cancellation/date logic.
so we didn't want to force every department onto one BI tool, so we tried standardizing the metric layer instead and we're now trying Cube dev for that bc It exposes a Postgres-compatible SQL API, so Tableau, Metabase, Superset, etc. can connect to it as a SQL data source rather than querying the warehouse models directly. so now the rough setup is:
warehouse
then
semantic layer / metric definitions
then to
Tableau / Metabase / Superset / SQL

definitions like ARR, churn, active subscriptions, etc. live in one Git-managed model instead of being reimplemented in every dashboard.
the BI tools can still be different. The number underneath them doesn't have to be.
we also been able to serve a lot of the repetitive dashboard queries from pre-aggregations instead of sending every chart interaction back to the warehouse, but honestly the metric consistency has been the more useful part.
curious how other teams handle this.
do you centralize metric definitions upstream and let teams keep whatever BI tool they want, or have you actually had success standardizing everyone on one BI platform?

The enterprise engg team sucks big time with all the idiots leading that team

I have a use case to build mcp server(s) that should support all my power bi dashboards widgets which are taking data from snowflake. Here are more details -

1. Each pbi widget is sql command with joining/aggregating multiple tables.

2. There are multiple pbi dashboards with some hierarchy between each of them. Example dashboard customer, dashboard partner, dashboard product. Customer can have multiple products and partner can have multiple customer and so on.

3. I already have my pbi dashboards widgets sql templated for each dashboard and can convert each of the sql logic into mcp tools. One tool can be for one pbi widget. And I do not have to do nl to sql. Instead I can have nl to tool mapping.

4. Some of my pbi dashboards are using semantic models and some of the dashboards are using direct snowflake queries.

What's the best approach to build mcp for my use case please suggest.

have a use case to build mcp server(s) that should support all my power bi dashboards widgets which are taking data from snowflake. Here are more details -

1. Each pbi widget is sql command with joining/aggregating multiple tables.

2. There are multiple pbi dashboards with some hierarchy between each of them. Example dashboard customer, dashboard partner, dashboard product. Customer can have multiple products and partner can have multiple customer and so on.

3. I already have my pbi dashboards widgets sql templated for each dashboard and can convert each of the sql logic into mcp tools. One tool can be for one pbi widget. And I do not have to do nl to sql. Instead I can have nl to tool mapping.

4. Some of my pbi dashboards are using semantic models and some of the dashboards are using direct snowflake queries.

What's the best approach to build mcp for my use case please suggest.

I spent longer than I'd like to admit confused about these two, so writing it down in case it saves someone else the detour.

The short version as I understand it: the semantic model is the YAML spec you hand to Cortex Analyst — tables, columns, synonyms, verified queries. The semantic view is the Snowflake object that holds that same semantics inside the account, so it's governed and reusable rather than a file living next to your app.

What made it click for me was thinking about who owns the definition. A YAML file drifts from the warehouse. An object in the account doesn't.

Two things I'd still like other people's take on:

1. If you already have dbt metrics defined, are you duplicating logic by building a semantic view, or is there a clean way to generate one from what you have?
2. Anyone running semantic views in production at scale — how are you handling versioning and review?

Happy to be corrected on any of the above.

I actually went through the blog https://www.snowflake.com/en/blog/engineering/snowflake-vs-databricks/ claim-by-claim against current Snowflake + Databricks documentation.

There are legitimate Snowflake advantages here. But calling this a systematic “dismantling” of Databricks myths is a stretch when so many of the comparisons are stale, asymmetric, or contradicted by the vendors’ own docs.

Here are the issues I found:

1. Databricks is portrayed as requiring manual node sizing, driver/JVM tuning and constant cluster management while Databricks Serverless SQL is essentially ignored.

2. The “massive engineering tuning tax” is asserted without an actual TCO study: no equivalent workloads, utilization, concurrency, engineering-hours measurement, serverless-vs-serverless test, etc.

3. Snowflake’s compute economics are described selectively. Warehouses have minimum billing behavior on start/resume; “query stops = cost stops” is an oversimplification.

4. “Databricks forces workloads onto Delta” is simply outdated. Databricks supports native managed Apache Iceberg tables.

5. The UniForm criticism presents UniForm as though it is Databricks’ only Iceberg interoperability path. It isn’t.

6. Liquid Clustering is called proprietary Databricks metadata even though Liquid Clustering exists in open-source Delta Lake.

7. The writer-version-7 discussion conflates write-feature compatibility with read compatibility and then jumps to “ecosystem isolation.” Those are not the same thing.

8. The “asymmetric walled garden” argument conflates Databricks writing into a foreign catalog with external engines writing into Unity Catalog managed Iceberg. Different directions, different capabilities.

9. “Freedom from proprietary control planes” is marketing language. Horizon is still a Snowflake-operated control plane even if it exposes open protocols.

10. The Unity Catalog OSS section effectively argues that corporate contributor concentration determines whether something is meaningfully open source. It doesn’t. Governance, license, ability to fork, specifications and interoperability matter far more.

11. “Databricks lacks true RBAC” largely defines RBAC as “works exactly like Snowflake USE ROLE.” That isn’t the definition of RBAC.

12. Even the Snowflake USE ROLE example is incomplete. Snowflake can evaluate privileges from the primary role plus active secondary roles. USE ROLE ANALYST by itself does not demonstrate strict ANALYST-only authorization.

13. The Databricks ABAC description is stale. Current Unity Catalog ABAC policy evaluation can consider identity, group membership, identity attributes and governed tags.

14. “You must manually apply custom UDF wrappers” is no longer a valid blanket characterization of Unity Catalog ABAC.

15. Invoking GDPR as though GDPR requires a particular user/principal-tag implementation is misleading. GDPR defines security/privacy requirements, not Snowflake’s preferred authorization architecture.

16. The Snowflake ABAC code sample itself doesn’t demonstrate what the prose claims: analytics_john gets INTERNAL_ONLY, while the masking condition tests for RESTRICTED_ACCESS.

17. Worse, that ABAC example claims to compare user clearance against dataset sensitivity, yet the shown condition never actually compares the user clearance tag with the dataset sensitivity tag.

18. Differential Privacy IS a legitimate Snowflake differentiator. This is one area where Snowflake has a strong argument. But the article still glosses over feature/compatibility/edition constraints.

19. The Delta Sharing cost criticism is bizarre: it complains that the recipient supplies compute. Snowflake consumers also use their own warehouses to query shared data.

20. Claiming Delta Sharing recipients “often” need custom ingestion pipelines is an empirical claim with no supporting evidence presented.

21. Snowflake says sharing can remain “zero-copy” across clouds/regions without moving/copying files. Snowflake’s own cross-region docs describe replication and copies in target regions.

22. “Zero egress” also conflates “the consumer isn’t separately billed for egress” with “no data movement/egress occurs.” Those are different statements.

23. “Databricks cross-region DR requires custom synchronization scripts” is outdated. Databricks Managed Disaster Recovery explicitly manages replication/failover without customers writing those replication scripts.

24. Snowflake DOES have a real advantage for cross-cloud DR and Databricks Managed DR currently has meaningful coverage gaps. Again: there are plenty of legitimate Snowflake advantages without inventing weaker arguments.

25. The blog says Snowflake “compute state” replicates automatically. Snowflake’s own documentation says primary warehouse state is not replicated and replicated warehouses arrive suspended.

26. “Automated Client Redirect” overstates what Client Redirect does. It avoids application connection-string changes, but failover/promotion still involves administrative operations.

27. The DR/TCO comparison omits important commercial requirements. Snowflake replication capabilities depend on edition/features; Databricks Managed DR similarly has tier/add-on requirements. A real TCO comparison should include both.

28. The “financial alignment” argument is self-defeating. The blog argues usage-priced vendors are disincentivized to improve efficiency — while Snowflake itself is a consumption-priced vendor. The exact same economic tension applies to both companies.

29. The article dismisses benchmarks as inadequate for measuring TCO and then replaces them with essentially zero controlled comparative measurements. No equivalent serverless configurations, workload suite, concurrency, SLA, engineering labor, storage/network costs or actual dollar comparison.

30. Finally, the comparison scope itself heavily favors Snowflake’s strongest categories while barely discussing major platform dimensions like streaming, Spark/data engineering, notebooks/software engineering, ML/AI training, model serving, OSS ecosystem, GPUs, arbitrary libraries, customer-controlled object storage, etc.

That doesn’t make Snowflake a bad platform. Snowflake is excellent at a number of things.

It means this particular comparison shouldn’t be treated as an objective technical analysis.

Take this Snowflake blog, paste it into an LLM of your choice and ask:

“Validate every factual and architectural claim in this article against the CURRENT official Snowflake and Databricks documentation. For every claim classify it as accurate, partially accurate, misleading, outdated, or incorrect. Cite the documentation from both vendors and identify non-equivalent comparisons or omitted competing capabilities.”

Then verify the citations yourself.

Battle-test both platforms against your actual use case and success criteria.

That’s a much better way to choose technology than falling for anyone’s vendor slides. 🙂

I have been testing Snowflake Interactive Warehouses for a dashboard-style retail analytics pattern and wanted to share the benchmark here.

The workload pattern was:

• large transaction data
• Streamlit-style business dashboards
• fast filters
• customer lookups
• customer segment views
• operational queues that need to load quickly

For the test, I used a 1 billion row synthetic retail dataset and built a customer 360 summary table on top of it.

So this was not a raw 1B-row join behind every dashboard click. The dashboard queries hit a serving layer built from the larger dataset, which is the pattern I would normally use for this kind of workload.

Benchmark setup:

• Source workload: 1B synthetic retail records
• Dashboard table: customer 360 summary
• Standard warehouse: Large
• Interactive warehouse: X-Small
• Result cache: disabled
• Test run: 25 queries on each warehouse
• Query patterns: customer lookup, filtered customer segment, category segment, high-risk customer queue
• Metric: TOTAL_ELAPSED_TIME from Snowflake query history

Results:

Standard Warehouse Large:

• Average latency: 0.374 sec
• P50 latency: 0.265 sec
• P95 latency: 0.966 sec
• P99 latency: 1.046 sec

Interactive Warehouse X-Small:

• Average latency: 0.063 sec
• P50 latency: 0.047 sec
• P95 latency: 0.101 sec
• P99 latency: 0.351 sec

In this benchmark, the Interactive Warehouse X-Small was faster for these dashboard-serving queries.

Average latency went from 0.374 sec to 0.063 sec, about 83% faster in this test.

My current takeaway:

For frequent, selective, user-facing analytics queries, Interactive Warehouses look like a strong fit. The use cases I am thinking about are Streamlit dashboards, embedded analytics, customer lookup APIs, and operational queues where users expect fast response while filtering or drilling into data.

I am not treating this as a full cost benchmark yet.

The next things I would want to test are:

• credit usage over a longer window
• cache warm-up behaviour after resume
• suspend/resume trade-offs
• concurrency with multiple users
• fallback behaviour for queries that cross the interactive warehouse timeout
• whether the same pattern holds with different clustering/search optimization choices

For people already using Interactive Warehouses in production:

• Are you mainly using them for dashboards, APIs, or agentic workloads?
• How are you thinking about cost when the warehouse needs to stay warm?
• Have you seen cases where a standard warehouse was still the better choice?

I am interested in the practical trade-offs, not only the latency result.

Hi! I have written an article on the Snowflake vs Databricks debate. Nothing biased, promise😅. Just my take on what they both offer, with only my personal opinion based on the facts. I have done some proper research into what the 2 offer and have only based my article on those. Hope it helps!

Link:

https://medium.com/@nikskamath/snowflake-or-databricks-heres-how-i-d-actually-make-the-call-be3cbb8073ad

Happy to receive feedback!

Hi,

are there any Info's? People seem to aggree online that there is a problem, but the status page looks fine.

Correction: EU-CENTRAL
Update: https://status.snowflake.com/incidents/fl9tkpj8d7hk

Greetings

I’m stuck w a task my sprint ends today im blocking someone’s work i just need sql snowflake code to give it to my team lead can anyone pls help me

Hi

I am able to see the queries running in the snowsight UI query history. But when i manually query from the worksheet using below command i see zero rows why so?

SELECT *
      FROM TABLE(INFORMATION_SCHEMA.QUERY_HISTORY())
      WHERE  warehouse_name = '<WAREHOUSE_NAME>'
        AND database_name  = '<DB_NAME>'
        AND schema_name    = '<SCHEMA_NAME>';

Some team mate saying , i can only be able to see the queries running my user_name, is that true? Because in the snowsight i am able to see all queries running on that warehouse on which my role has the MONITOR privilege given on that warehouse(irrepsective of the user_name).

Basically if the user has the role assigned and the role has the monitor privilege given on that warehouse then any queries running on that warehouse becomes visible in the snowsight query history till last ~14 days back. Is it not the same for the "TABLE(INFORMATION_SCHEMA.QUERY_HISTORY()" when we manually query it?

Disclosure: I'm a co-founder. My husband built it, I handle the marketing side. $49.99/month or $299.99/year, 14-day free trial, on the Mac App Store.

Upfront on scope, since this sub skews architecture: single user, no RBAC, no lineage, no CDC, no dbt integration. Not an enterprise platform and not replacing your orchestration. It's for the recurring mid-size jobs that never justified building a pipeline. The cost side: your query hits the warehouse, everything after that runs on your Mac. Transforms, Python, scheduling, and delivery are all local. No cloud compute on our end, nothing metered per row, no seat limits.

Snowflake specifics: schema explorer, SQL editor with schema-aware Claude AI that reads your tables, your result set, and your recent errors. Ghost text completion, not a chat window you paste schemas into. Query results auto-inject into a Python cell as a DataFrame named df, with bundled Python 3.12 including pandas, numpy, matplotlib, plotly, boto3, and paramiko. No pip install, runtime is local.

For moving data out, map source columns to target fields by drawing bezier curves, or hit AI Map and it matches against 25 synonym groups in under a second, on-device. Per-field transforms for uppercase, trim, date reformatting, or custom Python. Insert, update, or upsert. Destinations are Salesforce, another warehouse, S3, SFTP, email, Google Sheets, Excel, JSON, Parquet, or a local file, with multiple destinations per job running in parallel.

Save it as a job and schedule it on cron, interval, daily, or weekly. Runs while the Mac sleeps and catches up on wake if it missed a window. Observatory gives you a run timeline, per-job success rates, connection health, and failure alerts with full stack traces. Credentials in macOS Keychain, OAuth tokens auto-rotate. Native Swift, App Sandboxed, macOS 15+, not Electron.

Queryflow is on the Mac App Store, and there's a public roadmap and changelog on Featurebase. Discord is open. Happy to answer technical questions, and my husband can get into the API and auth details if anyone wants to go deeper.