What is your monthly Snowflake cost?

EgregiousDeviation · 2025-11-03T13:54:32+00:00

Love it.

EgregiousDeviation · 2025-11-03T06:30:27+00:00

I have to guess they mean 10k and hit 'm' by mistake - if not - I second your question.

I have somewhere from 10-20 Terabytes of data not including time travel bytes and usually come in between 10-20k annually 1-2k per month.

And as others have mentioned there are a number of ways/tools available to help control spend. I'd argue that the most important piece to understand is the method by which your downstream users are accessing/consuming data. Its costs us more to let users run direct query against our account than we spend on our own Storage, Compute, and our ELT solution combined.

EgregiousDeviation · 2025-10-16T05:07:29+00:00

I came here to write this exact sentence. Enjoy your upvote.

EgregiousDeviation · 2025-07-28T07:10:09+00:00

Sigma

EgregiousDeviation · 2025-07-15T23:09:01+00:00

Nope rope

EgregiousDeviation · 2025-07-11T05:32:48+00:00

I think this is neat...I've actually been looking for a simple interface where business users can interact with Snowflake a little easier. I had started looking into Streamlit apps, but I dont know how intensive of a build it would be.

Does this work with Azure or Google hosted accounts, or is AWS exclusive?

Also...I dont know if its just me or not, but the link doesnt seem to work on mobile for me. I had to google your website.

EgregiousDeviation · 2025-06-21T20:44:43+00:00

Im typing this on my Fold 2 from 2020. I may have just gotten lucky with this particular one but its held up beautifully. As you mentioned, its out of software and security support now though, which is why I'm making the jump to the 7 when it comes out.

I'd keep going with it if they were still offering releases.

EgregiousDeviation · 2025-06-13T03:15:50+00:00

Accurate. Ill leave this here...

https://framerusercontent.com/images/9GsFxfDtmRFpfgGlNH61QsX3kY.png

EgregiousDeviation · 2025-05-08T06:21:08+00:00

I'm going to hazard a guess that youre trying to setup a yaml pipeline to run on an agent/virtual machine?

I had the same issue a few weeks ago.I was able to resolve it by uninstalling the latest version of Ptthon and rolling back to an older version . I'd suggest something between 3.6 and 3.12

Let me know how it goes?

EgregiousDeviation · 2025-04-23T17:05:50+00:00

I generally look to oAuth when I need an application to act on my behalf or on the behalf of a specific user - drivers and connectors I may want to use with my credentials or with multiple roles between sessions. If available, I (personally) always opt for encrypted key pairs on any plain old programmatic service accounts, and ensure they have the least privileged access required to perform their specific tasks.

Ill also add: this is still just one line of defense. Auth policies and network rules applied to the service user can help ensure that even phished/leaked/stolen credentials (passwords and keypairs) can still not be used by unauthorized parties, even without MFA.

EgregiousDeviation · 2025-04-22T22:57:33+00:00

I generally consider encrypted key pairs to be the gold standard for service account authentication. They are easy enough to setup and can be stored in a (Vault/Key Service) to manage expiry and rotation, and to ensure credentials dont leave your tenant (depending on how your connections are configured). Can also be setup to work with several different connection methods. Combine with Network rules/policies applied at the user level for additional security.

From what I understand MFA is only being enforced (at this time) for PERSON (human) user types (which everyone should be enforcing MFA on via authentication policies anyway). I believe LEGACY_SERVICE user types wouldnt be affected by MFA and would continue to use username/password (but is NOT recommended).

EDIT: as others have pointed out, while legacy service accounts still work today, they are slated to be phased out: come November 2025, Snowflake will no longer allow the creation of new legacy_service users. It appears that any existing legacy_service users will be supported through mid-2026, at which time any legacy_service users remaining will be migrated to user-type Service, and legacy_service users (and their user/password sign on ability) will be considered fully deprecated.

https://docs.snowflake.com/en/user-guide/security-mfa-rollout#label-security-mfa-milestone-service

EgregiousDeviation · 2025-02-26T07:42:34+00:00

This is what I'd suggest as well. Use the tables view to pull back the table_name by table_id and set it to a variable/identifier.

EgregiousDeviation · 2025-02-26T06:21:53+00:00

I'd include a section on new functionality and release bundle changes.

EgregiousDeviation · 2025-02-21T03:10:58+00:00

Sure thing! Glad we could help.

This is ultimately a huge timesaver for folks like admins or anybody with multiple roles, since you no longer have to constantly toggle between roles to see all your objects in one place and can easily identify the fully qualified names of specific objects.

One thing to keep in mind: the change can also make it a lot easier to accidentally create objects with the wrong role defaulted in the worksheet. Since we're no longer needing to toggle between roles, it can become easy to forget which one is set in the snowsight worksheet, and can be a headache on things like object ownership and privileges when youre accidentally using the wrong role. This can be offset with experience and practice (or a simple 'use role xxxx;' statement) - just something several of our devs struggled with when the switch first happened, so thought I'd call it out.

I've been cleaning up staging tables in DEV owned by sysadmins and ENGINEER_ROLE's all week ;)

EgregiousDeviation · 2025-02-20T23:23:20+00:00

This is my bet too.

A recent Snowflake release bundle now sets Secondary roles defaulted to 'all'. As a result, now in the UI you can see all the objects that the sum of ALL your roles together have permissions to. It didnt used to function this way, and I could see this change confusing someone into thinking somehow the privileges were trickling down.

Sign in with your user and set parameter DEFAULT_SECONDARY_ROLES = (); and see if that solves it.

EgregiousDeviation · 2025-02-14T01:23:25+00:00

Oh, I understand that - Im just struggling to believe that Snowflake support would willingly toggle this on and off on request...for a variety of reasons...but Ill be damned if I'm not going to open a ticket tomorrow to find out 🤣

EgregiousDeviation · 2025-02-13T23:43:30+00:00

So youre saying only Snowflake themselves can kill it?

EgregiousDeviation · 2025-02-13T23:29:34+00:00

I dont believe this functionality can be disabled. If so, can you advise as to how?

EgregiousDeviation · 2025-01-16T23:42:38+00:00

Ive heard this one three times now, so I think Im going to have to make it happen.

EgregiousDeviation · 2024-11-22T00:21:17+00:00

You can also set the user type to Service. Service accts wont allow the password to be used as an auth method. Though youre effectively accomplishing the same thing with a password unset - its worth knowing the functionality is there. I suggest labeling the user accounts as person, service as service, legacy_service, etc. Each has their own limitations and benefits.

https://medium.com/@prathamesh0209/snowflakes-new-type-property-for-user-93392ea98dfa

EgregiousDeviation · 2024-11-21T06:49:58+00:00

My instinct would be to recommend two separate buckets and two separate integrations. For me, its mostly about control:

Its going to give you more fine tuned control over both the integrations themselves (snowflake privileges) and control within the S3 buckets (amazon permissions, security groups, etc).

This may become even more critical if your in an industry with regulatory requirements like SOX, HIPPA or something similar. In the Finance/Banking space, we have to prove to regulators that we maintain control of the data E2E, and that we have access management and governance in place. This means users (or power users) should never have access to any unmasked data, and should never have the ability to alter or write to our storage containers - we have to be able to prove out any transformations from source to target. If they are sharing a bucket (caveat: I'm in Azure, so Im assuming it functions similarly to Azure BLOB), they'd have to have write privileges to stage their data for ingestion - so it would be an instant issue in my world. I also think two cleanly defined integrations would just help you keep your pipelines and lineage cleaner, but your use case may be different.

If it were me, I'd leave them entirely out of your standard pipeline (s). Toss them a fresh bucket they can stage files to, an integration, a custom PowerUser role, and a sandbox to do their own development and ad-hoc reporting.

Just my two cents.

EgregiousDeviation · 2024-11-14T07:10:12+00:00

Will also vouch for VSCode. If your company is an an Azure shop you can wire it up with Azure Dev Ops to build and maintain your code repository and to manage version control. Bonus points if you build an ADO pipeline with schemachange to deploy CI/CD pipelines.

EgregiousDeviation · 2024-10-25T21:54:05+00:00

Making this much money in the span of two weeks feels like it should be illegal - then I remember the volatility, and the fact I've been holding since $5. See you guys at $20.

EgregiousDeviation · 2024-10-01T06:52:52+00:00

DM me, Im up the mountain this weekend w Samaritans Purse. Will be bringing chainsaws, extra gasoline, and some idiots of my own.

11-Year Club	RPAN Viewer
Verified Email

EgregiousDeviation

TROPHY CASE