Databricks vs Snowflake: Which one is better in 2025?

One stolen password can bring down an entire enterprise. The 2024 Snowflake breaches revealed how fragile weak access controls are, with 165 organizations and millions of users affected. The breaches were not the result of advanced attacks. They happened because stolen passwords went unchecked, and multi-factor authentication was missing. As businesses move more of their data to the cloud and centralize it on platforms like Snowflake, a critical question emerges: who should have access, and how do you manage it at scale without slowing the business or weakening security?

In this article, we’ll break down the Snowflake Role Hierarchy, explain why it matters, and share best practices for structuring roles that support security, compliance, and day-to-day operations.

What is Snowflake’s role hierarchy?

Snowflake’s role hierarchy is a structured framework that defines how permissions and access controls are organized within the platform. In Snowflake, access to data and operations is governed entirely by roles. Using the Role-Based Access Control (RBAC) model, you grant privileges to roles, and then assign users to those roles, simplifying administration, ensuring consistency, and making audit access easier. RBAC is generally recommended for production environments and enterprise-level governance.

The hierarchy operates on a parent-child relationship model where higher-level roles inherit privileges from subordinate roles, creating a tree-like structure. This structure provides granularity, clarity, and reusability, but it requires thoughtful planning to avoid sprawl or over-permissioned users.

Core components of Snowflake RBAC

• Roles: The fundamental building blocks that encapsulate specific privileges
• Privileges: Defined levels of access to securable objects (databases, schemas, tables)
• Users: Identities that can be assigned roles to access resources
• Securable Objects: Entities like databases, tables, views, and warehouses that require access control
• Role Inheritance: The mechanism allowing roles to inherit privileges from other roles

Understanding Snowflake's system-defined roles

Understanding the default role structure is crucial for building secure hierarchies:

ACCOUNTADMIN

• Root-level access to all account operations
• Can view and manage billing and credit data
• Should be tightly restricted to emergency use only
• Not a "superuser" - still requires explicit privileges for data access

SYSADMIN

• Full control over database objects and users
• Recommended parent for all custom roles
• Manages warehouses, databases, and schemas

SECURITYADMIN

• Manages user and role grants
• Controls role assignment and privilege distribution
• Essential for maintaining RBAC governance

Custom roles

• Created for specific teams or functions within an organization (e.g ANALYST_READ_ONLY, ETL_WRITER).

Best practices for designing a secure Snowflake role hierarchy

A well-structured role hierarchy minimizes risk, supports compliance, and makes onboarding/offboarding easier. Here’s how one should do it right:

1. Follow the Principle of Least Privilege

Grant only the minimum required permissions for each role to perform its function. Avoid blanket grants like GRANT ALL ON DATABASE.

Do this:

• Specific, targeted grants
• Avoid cascading access down the role tree unless absolutely needed
• Regularly audit roles to ensure they align with actual usage

GRANT SELECT ON TABLE SALES_DB.REPORTING.MONTHLY_REVENUE TO ROLE ANALYST_READ;
GRANT USAGE ON SCHEMA SALES_DB.REPORTING TO ROLE ANALYST_READ;
GRANT USAGE ON DATABASE SALES_DB TO ROLE ANALYST_READ;

Not this:

• Overly broad permissions

GRANT ALL ON DATABASE SALES_DB TO ROLE ANALYST_READ;

Why does it matter?

Least privilege prevents accidental (or malicious) misuse of sensitive data. It also supports data governance and compliance with various regulations like GDPR or HIPAA.

2. Use a layered role design

Design your roles using a layered and modular approach, often structured like this:

• Functional Roles (what the user does):

CREATE ROLE ANALYST_READ;
CREATE ROLE ETL_WRITE;
CREATE ROLE DATA_SCIENTIST_ALL;

• Environment Roles (where the user operates)

CREATE ROLE DEV_READ_WRITE;
CREATE ROLE PROD_READ_ONLY;

Composite or Team Roles (Group users by department or team, assigning multiple functional/environment roles under one umbrella)

CREATE ROLE MARKETING_TEAM_ROLE → includes PROD_READ_ONLY + ANALYST_READ

3. Avoid granting privileges directly to users

Always assign privileges to roles and not users. Then, assign users to those roles.

Why it matters?

This keeps access transparent and auditable. If a user leaves or changes teams, simply revoke or change the role. There’s no need to hunt down granular permissions.

4. Establish consistent naming conventions

Enforce naming conventions as consistent role and object naming makes automation and governance far easier to scale.

Recommended Naming Pattern:

• Access Roles: {ENV}_{DATABASE}_{ACCESS_LEVEL} (e.g., PROD_SALES_READ)
• Functional Roles: {FUNCTION}_{TEAM} (e.g., DATA_ANALYST, ETL_ENGINEER)
• Service Roles: {SERVICE}_{PURPOSE}_ROLE (e.g., FIVETRAN_LOADER_ROLE)

5. Use separate roles for Administration vs. Operations

Split roles that manage infrastructure (e.g., warehouses, roles, users) from roles that access data.

• Admins: SYSADMIN, SECURITYADMIN‍
• Data teams: DATA_ENGINEER_ROLE, ANALYST_ROLE, etc.

Why it matters? This separation of duties limits the potential impact of security incidents and supports audit compliance. Administrators should not have access to sensitive data unless it's absolutely necessary for their role.

6. Secure the top-level roles

Roles like ACCOUNTADMIN and SECURITYADMIN should be assigned to the fewest people possible, protected with MFA, and monitored for any usage.

Implementation Checklist:

• Limit ACCOUNTADMIN to 2-3 emergency users maximum
• Enable MFA for all administrative accounts
• Set up monitoring and alerting for admin role usage
• Regular access reviews and privilege audits
• Document and justify all administrative access

Monitoring, auditing & compliance: keeping your Snowflake hierarchy healthy

Even the best-designed role trees can get messy over time. Here’s how to maintain security:

1. Regular access reviews

Implement quarterly access reviews to maintain security hygiene:

• Role Effectiveness Analysis: Identify unused or over-privileged roles
• User Access Validation: Verify users have appropriate role assignments
• Privilege Scope Review: Ensure roles maintain least privilege principles
• Compliance Mapping: Document role mappings to business functions

2. Logging and monitoring

Enable Access History and Login History in Snowflake to track activity and implement automation tools for role assignments during employee transitions.

3. Onboarding/offboarding automation

Implement automation tools or scripts to efficiently manage role assignments during employee transitions.

4. Object Tagging for enhanced security

Use object tagging to classify sensitive data and control access accordingly.

Measuring RBAC Success: Key Performance Indicators

1. Security Metrics

• Access Review Coverage: % of roles reviewed quarterly
• Privilege Violations: Number of excessive privilege grants identified
• Failed Authentication Attempts: Monitor for unauthorized access patterns
• Role Utilization Rate: % of active roles vs. total created roles

2. Operational Metrics

• User Onboarding Time: Average time to provision new user access
• Role Management Efficiency: Time to modify/update role permissions
• Audit Response Time: Speed of access review and remediation
• Automation Coverage: % of role operations automated vs. manual

3. Compliance Metrics

• SOC 2 Readiness: Role hierarchy documentation completeness
• GDPR/Data Privacy: Data access control effectiveness
• Industry Compliance: Sector-specific requirement adherence
• Change Management: Role modification approval and documentation

Future-Proofing Your RBAC Strategy

The way you manage access today will define how secure and scalable your Snowflake environment is tomorrow. The strength of Snowflake’s RBAC model lies in its flexibility, but that power comes with responsibility. As AI features mature, as multi-cloud deployments become the norm, and as regulators tighten expectations around data privacy, static role hierarchies quickly fall behind. A poorly structured role hierarchy can lead to data leaks, audit failures, higher operational costs, and stalled innovation.

At Snowstack, we specialize in building RBAC strategies that are not only secure today but ready for what’s next. Our team of Snowflake-first engineers has designed role models that scale across continents, safeguard sensitive data for regulated industries, and enable AI without exposing critical assets. We continuously monitor Snowflake’s roadmap and fold new security capabilities into your environment before they become business risks.

Don’t wait for the next breach to expose the cracks in your access controls. Let’s design an RBAC strategy that keeps you secure, compliant, and future-ready.

👉 Book a free RBAC assessment

‍

Some companies still run databases like it’s 1999. Others have adopted cloud-native architectures that cut costs in half and double performance. Guess who’s winning?

Traditional databases force a trade-off between performance and budget. Collaboration still means passing around CSVs. Forward-thinking organizations have shifted to Snowflake’s cloud-native architecture, which scales instantly, operates securely, and keeps costs under control. But what truly sets Snowflake apart from traditional databases or even other cloud data platforms?

In this blog, we’ll break down three key architectural advantages that make Snowflake a game-changer for businesses that want to migrate to the cloud.

But first, what is a cloud-native database?

A cloud-native database is designed from the ground up for the cloud. Unlike traditional databases that were adapted from on-premise systems, cloud-native platforms are purpose-built to take advantage of the cloud’s strengths: scalability, flexibility, and resilience.

They scale horizontally by adding capacity in parallel instead of relying on bigger machines. They automatically adjust resources up or down based on demand, so you only pay for what you use. They also come with built-in high availability through data replication and automated recovery.

In short, a cloud-native database removes the rigid trade-offs of legacy systems and gives modern businesses the performance, efficiency, and reliability they need to stay competitive.

Snowflake's architecture: 3 strategic advantages

Snowflake isn’t just faster or cheaper. It’s built differently. The three architectural choices below explain why modern data teams trust Snowflake to scale, collaborate, and deliver insights in ways legacy systems never could.

1. Separation of storage and compute: elasticity without trade-offs

Most databases tie storage and compute together. Need more power to run quarterly reports? You’ll also pay for storage you don’t use. Want to keep historical data at a lower cost? You’re still paying for compute you don’t actually need.

Snowflake's Solution: Snowflake's architecture fundamentally decouples storage and compute layers, creating unprecedented flexibility for modern data teams.

• You can scale compute resources up or down independently of your data storage.
• Multiple workloads (e.g., data ingestion, analytics queries, and reporting) can run simultaneously on isolated compute clusters without performance conflicts.
• You can assign different warehouses (compute clusters) to different teams or departments without worrying about concurrency issues or resource contention.

Business impact: Imagine a BI team that runs heavy dashboards while a data science team trains models on the same data. The beauty behind this separation is that both can operate without stepping on each other’s toes. This translates to faster time-to-insight, cost control, and happy teams who aren’t waiting for resources to free up.

2. Multi-cluster shared data architecture: built for collaboration and scale

Traditional databases become performance challenge as more users access the system. Query response times degrade, teams queue for resources, and data silos emerge as different departments seek workarounds.

Snowflake's Solution: Snowflake’s multi-cluster shared data model allows any number of users and tools to access the same single source of truth without performance degradation. The platform automatically manages concurrency through intelligent multi-cluster compute scaling.

What this means for data teams:

• Unlimited concurrency: Teams don’t have to wait in line to access the warehouse. Snowflake automatically adds compute clusters as needed and scales them back down when demand drops.
• Cross-team collaboration: Data Engineers, analysts, and ML engineers can work off the same dataset in real time, using SQL, Python, or third-party tools.
• Data sharing across organizations: Snowflake’s architecture supports secure data sharing with external partners or vendors without copying or moving data. You simply grant access.

Business impact: This makes Snowflake not just a warehouse but a collaboration platform for data. Whether your team is distributed across continents or collaborating with external partners, Snowflake enables fast, consistent, and secure access to data.

3. Zero management with cloud-native infrastructure

Managing a traditional database means dealing with provisioning, tuning, indexing, patching, and more. These tasks require specialized DBAs and often lead to downtime, delays, and human error.

Snowflake flips the script with a “zero-management” approach.

Thanks to its fully managed SaaS model:

• No infrastructure to manage. Snowflake runs entirely in the cloud (on AWS, Azure, or GCP), abstracting away the underlying hardware.
• Automatic tuning and optimization. No need to manually set indexes or optimize queries, Snowflake handles that under the hood.
• Security and compliance out of the box. Features like automatic encryption, role-based access control, and compliance with standards (HIPAA, GDPR, SOC 2) are built-in.

Business impact: This lets your team focus on data and insights, not on maintenance. IT teams no longer need to waste time on low-value operational tasks. Instead, they can accelerate innovation and reduce costs.

Snowflake vs. the competition: why architecture matters

In 2025, your data architecture is more than a technical choice. It is a strategic decision that defines how quickly your organization can compete, innovate, and scale. When you compare modern data platforms, Snowflake's architectural advantages become clear when compared to alternatives:

How Snowflake’s architecture drives results?

Snowflake’s architecture solves the trade-offs that hold traditional databases back and delivers flexibility that many cloud platforms still lack. But technology alone is not enough. The difference comes from how you implement it.

Take the case of a $200M pharmaceutical distributor. Their teams were stuck with siloed on-prem systems, compliance risks, and reports that took hours to run. Our Snowflake-certified experts helped them migrate to Snowflake’s cloud-native architecture with a single governed data layer, dedicated compute clusters, and built-in role-based access. In just 90 days, reporting was 80% faster, the architecture was ready for AI and advanced analytics, and teams finally worked from the same source of truth.

👉 Read the full case study here

Making Snowflake’s architecture work for your business

Every organization’s data challenges look different, but the goal is the same: to turn Snowflake into a platform that delivers measurable results. That’s where Snowstack comes in. We bring proven experience from complex projects in finance, pharma, and FMCG. This gives clients confidence that their architecture is designed for scale, collaboration, and compliance from day one. Our role goes beyond implementation. We act as a long-term partner who helps data teams adapt, optimize, and grow with Snowflake as business needs evolve.

‍

For data teams, the pattern is almost always the same. You move to Snowflake for performance and scale. But then the first bill lands, and suddenly your Snowflake warehouse costs are far higher than forecast. What went wrong?

The first step to regaining control is understanding how Snowflake costs are calculated. This guide breaks down the cost structure and gives you five practical steps to optimize spend, so you only pay for the resources you actually need and can design a sustainable Snowflake FinOps practice before your next renewal.

But first, what Snowflake is used for?

Snowflake is a cloud data platform that enables organisations to store, process, and analyse data at scale. It operates on the three leading cloud providers (Amazon Web Services, Google Cloud Platform, and Microsoft Azure), giving businesses flexibility in how they deploy and expand their environments, whether as a greenfield implementation or as part of a larger Snowflake data platform rollout.

As a fully managed service, Snowflake removes the burden of infrastructure management. Users do not need to handle hardware, software updates, or tuning. Instead, they can focus entirely on working with their data while the platform manages performance, security, and scalability in the background - often with a lean internal team supported by a specialised Snowflake platform team.

One of Snowflake’s defining features is the separation of storage and compute, which allows each to scale independently. This design supports efficient resource usage, quick provisioning of additional capacity when needed, and automatic suspension of idle compute clusters known as virtual warehouses. These capabilities reduce costs while maintaining high performance when they’re configured with a cost-optimisation strategy.

Why your Snowflake cost keeps growing?

Before we discuses optimization, let's decode what you're actually paying for. Because if you're like most data teams, you're probably overpaying for things you didn't know you were buying.

Snowflake’s pay-as-you-go model is built on two primary components: compute and storage, along with a smaller component, cloud services.

1. Compute costs

This is typically the largest portion of your Snowflake bill. Compute is measured in Snowflake credits, an abstract unit that's consumed when a virtual warehouse is active.

Here's how the math works:

• Virtual Warehouses: These are the compute clusters (EC2 instances on AWS, for example) that run your queries, data loads, and other operations.
• "T-Shirt" Sizing: Warehouses come in sizes like X-Small, Small, Medium, Large, etc. Each size up doubles the number of servers in the cluster and, therefore, doubles the credit consumption per hour.
• Per-Second Billing: You're billed for credits on a per-second basis after the first 60 seconds of a warehouse running.

The formula for calculating the cost:

Credits Consumed = (Credits per hour for the warehouse) × (Total runtime in seconds) ÷ 3600

Real example: Running a Large warehouse (8 credits/hour) for 30 minutes (1800 seconds) would consume (8 * 1800)÷3600 = 4 credits. If you're paying $3 per credit, that half-hour just cost you $12. Scale that across dozens of queries per day, and you can see how costs spiral.

2. Storage Costs

At first, storage looks inexpensive compared to compute, but as data grows costs can rise quickly. Snowflake calculates storage charges based on the average monthly volume of data you store in terabytes. Because your data is automatically compressed, you’re billed on the compressed size, which most teams overlook.

You're paying for three different types of storage:

1. Active Storage: The live data in your databases and tables.
2. Time-Travel: Data kept to allow you to query or restore historical data from a specific point in the past. The default retention period is 1 day, but it can be configured up to 90 days for Enterprise editions.
3. Fail-safe: A 7-day period of historical data storage after the Time-Travel window closes, used for disaster recovery by Snowflake support. This is not user-configurable.

3. Cloud services costs

The cloud services layer provides essential functions like authentication, query parsing, access control, and metadata management. For the most part, this layer is free. You only begin to incur costs if your usage of the cloud services layer exceeds 10% of your daily compute credit consumption. This is rare but can happen with an extremely high volume of very simple, fast queries.

5 steps to optimize your Snowflake warehouse costs

Now that you know what you're paying for, here are five steps to significantly reduce your spend.

Step 1: right-size your virtual warehouses

Running an oversized warehouse is like using a sledgehammer to crack a nut - it's expensive and unnecessary.

• Start small: Don't default to a Large warehouse. Begin with an X-Small or Small and only scale up if performance is inadequate. It's often more efficient to run a query for slightly longer on a smaller warehouse than for a few seconds on a larger one. Look for slow queries in the Query History that generate a lot of “Bytes spilled to local storage”. For large joins or window functions, going for a Small to Large warehouse might be 4 times more expensive, but 10x faster, resulting in a 60% cost reduction.
• Set aggressive auto-suspend policies: An active warehouse consumes credits even when it's  inactive. Configure your warehouses to auto-suspend quickly when not in use. A setting of 1 to 5 minutes is a good starting point for most workloads. This single change can have a massive impact on your bill.
• Separate your workloads: Don't use one giant warehouse for everything. Create separate warehouses for different teams and tasks: (e.g., ELT_WH for data loading, BI_WH for analytics dashboards, DATASCIENCE_WH for ad-hoc exploration). This prevents a resource-intensive data science query from slowing down critical business reports and allows you to tailor the size and settings for each specific workload.
• Use multi-cluster warehouses for high concurrency: If you have many users running queries simultaneously (like a popular BI dashboard), instead of using a larger warehouse (scaling up), configure a multi-cluster warehouse (scaling out). This will automatically spin up additional clusters of the same size to handle the concurrent load and spin them down as demand decreases.

Step 2: optimize your queries and workloads

Inefficient queries are a primary driver of wasted compute credits. A poorly written query can run for minutes on a large warehouse when a well-written one could finish in seconds on a smaller one.

• Use the Query Profile: This is your best friend for optimization. Before trying to fix a slow query, run it and then analyse its performance in the Query Profile. This tool provides a detailed graphical breakdown of each step of query execution, showing you exactly where the bottlenecks are (e.g., a table scan that should be a prune, an exploding join).
• Avoid SELECT *: Only select the columns you actually need. Pulling unnecessary columns increases I/O and can prevent Snowflake from performing "column pruning," a key optimization technique.
• Be careful with JOINs: Ensure you are joining on keys that are well-distributed. Accidental Cartesian products (cross-joins) are a notorious cause of runaway queries that can burn through credits.
• Materialize complex views: If you have a complex view that is queried frequently, consider materializing it into a table. While this uses more storage, the compute savings from not having to re-calculate the view on every query can be substantial. Use Materialized Views for this, as Snowflake will automatically keep them up-to-date.

Step 3: manage your data storage lifecycle

While cheaper than compute, storage costs can creep up. Proactive data management is key.

• Configure Time-Travel Sensibly: Do you really need 90 days of Time-Travel for every table? For staging tables or transient data, a 1-day retention period is often sufficient. Align the Time-Travel window with your actual business requirements for data recovery.
• Use Transient and Temporary Tables: For data that doesn't need to be recovered (like staging data from an ELT process), use transient tables. These tables do not have a Fail-safe period and only have a Time-Travel period of 0 or 1 day. This can significantly reduce your storage footprint for intermediate data.
• Periodically Review and Purge Data: Implement a data retention policy and periodically archive or delete data that is no longer needed for analysis.

Step 4: maximize caching to get free compute

Snowflake has multiple layers of caching that can dramatically reduce credit consumption if leveraged correctly. When a query result is served from a cache, it consumes zero compute credits.

• The Result Cache: Snowflake automatically caches the results of every query you run. If another user submits the exact same query within 24 hours (and the underlying data has not changed), Snowflake returns the cached result almost instantly without starting a warehouse. This is perfect for popular dashboards where many users view the same report.
• Local Disk Cache (Warehouse Cache): When a warehouse executes a query, it caches the data it retrieved from storage on its local SSD. If a new query requires some of the same data, it can be read from this much faster local cache instead of remote storage, speeding up the query and reducing compute time. This cache is cleared when the warehouse is suspended.

Step 5: implement robust governance and monitoring

You can't optimize what you can't measure. Use Snowflake's built-in tools to monitor usage and enforce budgets.

• Set up Resource Monitors: This is your primary safety net. A Resource Monitor can be assigned to one or more warehouses to track their credit consumption. You can configure it to send alerts at certain thresholds (e.g., 75% of budget) and, most importantly, to suspend the warehouse when it hits its limit, preventing runaway spending.
• Analyse your usage data: Snowflake provides a wealth of metadata in the SNOWFLAKE database, specifically within the ACCOUNT_USAGE schema. Views like WAREHOUSE_METERING_HISTORY, QUERY_HISTORY, and STORAGE_USAGE are invaluable. Query this data to find your most expensive queries, identify your busiest warehouses, and track your storage costs over time.
• Tag everything for cost allocation: Use Snowflake's tagging feature to assign metadata tags to warehouses, databases, and other objects. You can tag objects by department (finance, marketing), project, or user. This allows you to query the usage views and accurately allocate costs back to the teams responsible, creating accountability.

Bringing it all together

So what’s your next step? These five practices will help you reduce costs and build smarter habits, but turning them into measurable savings at scale takes more than a checklist. It requires the right expertise and execution.

For example, a leading financial services company was spending more than $800K per month on cloud costs with no clear view of where the money was going. Within 90 days of working with our experts, they gained full visibility, reduced ingestion latency by 80%, and built a governed, AI-ready platform while bringing costs back under control.

👉 Read the full case study here

At Snowstack, we bring certified Snowflake expertise and proven delivery methods to help enterprises cut spend, improve performance, and prepare their platforms for AI and advanced analytics.

Ready to make your Snowflake environment cost-efficient and future-proof?

‍