Technology / Snowflake
A Snowflake platform with a clear purpose.
Snowflake is a cloud data platform that separates storage from compute, commonly used for governed analytics, concurrent BI workloads and data sharing across teams. Quorlytic evaluates it against representative workloads and existing cloud commitments, makes compute cost observable by workload, and migrates business logic and access roles, not just SQL syntax.
By QuorlyticUpdated
Use the platform decision to clarify the data product you need to deliver. Evaluate Snowflake against representative workloads, governance requirements and your team's operating model.
Architecture role
Where Snowflake fits.
A Snowflake platform commonly sits between ingestion and the semantic layer, holding governed data that many teams read from. The architecture decision is less about storage and more about how workloads, access and cost are separated.
Position in the end-to-end path
- 01SourcesApplications, databases, APIs
- 02Ingest & orchestrateBatch, CDC and scheduling
- 03SnowflakeGoverned storage and isolated compute
- 04Semantic & analyticsMetrics, relationships and access
- 05DecisionsDashboards and workflows
Ingestion
- Batch
- CDC
- SnowpipeContinuous load
Snowflake
Compute — isolated virtual warehouses
- TransformOwn size · own bill
- BIOwn size · own bill
- Data scienceOwn size · own bill
Roles · masking · row access — defined once
- dbt models
- BI tools
- Data sharing
- Apps
Illustrative architecture. It shows a typical position for discussion, not a mandatory stack or a client implementation.
Fit and capability
When it is relevant, and what the work involves.
Relevant workloads
- Governed analytics
- Concurrent BI
- Data sharing
- Isolated workloads
Engineering capabilities
- Workload and access requirements
- Target architecture and ownership model
- Migration validation plan
- Cost-observation and operating checklist
Integration points
What it connects to.
The platform is only as useful as the boundaries around it. These are the interfaces that usually need an explicit decision.
- 01Cloud object storage
- 02Ingestion and orchestration
- 03Semantic / BI layer
- 04Identity and access
Delivery and operating considerations
What to decide before you commit.
Each consideration changes something concrete in the architecture, the operating model or the cost profile.
- 01
Define the workload
Map ingestion frequency, transformation patterns, query concurrency and downstream consumers. Separate business-critical reporting from exploratory workloads and evaluate how each should use compute. Test with data and query patterns that resemble production.
- 02
Make cost observable
Assign ownership to workloads and inspect compute, storage and transfer costs separately. Establish resource controls and operational review. A platform bill cannot be understood from storage volume alone; concurrency and repeated transformations can materially change the workload.
- 03
Migrate semantics, not just SQL
Inventory stored logic and data types, reconcile key business measures, and plan incremental migration waves. Validate access roles and downstream consumers before cutover. Automated conversion is an input to validation, not evidence of business equivalence.
- 04
Know when to compare alternatives
Evaluate existing cloud services and other platforms when requirements involve a different processing model, governance boundary or team skill set. Quorlytic does not claim official Snowflake partner status. Technology selection should be supported by a workload experiment rather than a badge.
- 05
Make the cost model part of the design
Snowflake separates storage from compute, so cost tracks how workloads use warehouses, not how much data is stored. Warehouse sizing, auto-suspend behaviour, query concurrency and repeated transformations all move the bill. Attribute usage to a workload and review the compute model after a baseline exists, rather than optimising from the invoice alone.
- Warehouse and workload ownership recorded
- Auto-suspend and sizing reviewed against real concurrency
- Storage growth and retention priced together
Typical delivery sequence
- 01Ingestion
- 02Governed models
- 03Isolated workloads
- 04BI & applications
Decision table
When Snowflake fits, and when to compare.
| Dimension | Snowflake is a strong fit | Compare alternatives when |
|---|---|---|
| Workload | Concurrent, governed SQL analytics and BI over modelled data. | The centre of gravity is distributed processing, streaming or model training on the same data. |
| Concurrency | Many readers need isolated compute, sized per workload and suspended when idle. | Usage is a few steady batch jobs that a smaller managed service would handle at lower cost. |
| Team | A SQL-led team that wants platform administration kept contained. | The team already operates Spark and Python pipelines on a lakehouse. |
| Data sharing | Data has to reach other teams, partners or accounts without copying it. | Data never leaves one team and one application. |
| Existing estate | You want one analytical platform across AWS, Azure or Google Cloud. | Existing cloud commitments already cover a native warehouse such as BigQuery, Redshift or Fabric. |
Test the access boundary before accepting the platform.
A successful dashboard query proves that one access path works. It does not prove that the reporting identity is restricted correctly. This hypothetical acceptance matrix pairs permitted actions with actions that should fail for a reporting consumer, a loader and an operator.
Scope and assumptions: Adapt the proposed role boundaries to the actual account, role hierarchy, object types and data policies. These are test requirements, not grant commands or a security certification. Run approved checks with sanitized data in a representative environment.
| Dimension | Proposed allowed and denied actions | Acceptance evidence |
|---|---|---|
| Reporting consumer | Allow reads from the approved reporting view; deny source-table modification and unrelated sensitive data access. | Record the identity, active primary and secondary roles, object and result for both positive and negative tests. Confirm the intended view and policy behavior, not just query success. |
| Load identity | Allow the required writes within the loading boundary; deny writes to published reporting objects unless explicitly required. | Test the actual connector's role configuration. Check inherited roles and grants that could make a negative test pass unexpectedly. |
| Warehouse use | Distinguish using approved compute from changing or operating its configuration. Object privileges and warehouse privileges serve different purposes. | Verify that each identity can perform its intended workload and cannot perform the separately restricted management action. Record any additional privilege intentionally required by the connector. |
| Grant administration | Name who may change access; do not assume a developer who creates an object should decide its production grants. | Confirm whether the schema uses managed access. In a managed access schema, check the schema owner or MANAGE GRANTS authority rather than relying on object ownership alone. |
| Removal and replacement | After an approved role change, retest access through the application identity and intended session setup. Look for other effective grant paths. | Capture the before/after role configuration and a fresh connection test. Keep credential rotation and authentication validation as separate checks; revoking one grant does not establish complete offboarding. |
At narrow widths, scroll the worksheet to read every column. With the table focused, use the arrow keys to scroll.
Worked decision: suppose the reporting role cannot modify a table when tested alone, but the application's secondary role permits that write. The proposed acceptance fails for the application identity. Resolve the effective grant path and repeat the negative test; a screenshot from a more restricted test session is insufficient.
- Attach expected allow/deny results before execution, then retain actual results and the security owner's disposition of exceptions. Do not broaden a role simply to make a connection test pass.
- Include row and column policy expectations where relevant. A role matrix complements network, authentication and audit controls; it does not replace them.
When the same platform is a migration target, connect these access tests to the Snowflake migration acceptance requirements so that consumer parity includes permitted data access.
Official references for this example:
Questions
Questions worth asking.
Is Snowflake always the best warehouse choice?
No. Compare your workload, cloud commitments, governance and operating skills. Use representative query and ingestion tests, including the cost of running and maintaining the complete architecture.
Can we reduce Snowflake cost without changing the model?
Sometimes. Warehouse sizing, auto-suspend, query patterns and repeated transformations often change the bill more than the data model does. Start by attributing usage to workloads and finding the queries that dominate compute, then change the model only where the workload genuinely requires it.
Integration ecosystem
What sits around Snowflake.
Adjacent technologies grouped by the role they play next to this platform, and why that role usually needs an explicit decision.
Ingestion
- Change data capture
- Snowpipe-style continuous loading
- Batch extracts
- Kafka connectors
Snowflake holds data; something else has to put it there. Whether updates and deletes must be preserved decides this more than volume does.
Transformation
- dbt
- SQL
- Stored procedures
- Python worksheets
Transformation runs inside the platform, so the choice is about how logic is versioned and tested rather than about where the compute lives.
Consumption
- Power BI
- Tableau
- Looker
- Applications
- Data sharing
Consumer mix drives concurrency, which drives warehouse topology. It is the input that most changes the platform design.
Identity and access
- SSO
- SCIM provisioning
- Role hierarchy
- Row access policies
- Masking
Access is modelled once in the platform rather than per reporting tool, which is one of the stronger reasons to consolidate onto it.
Operations
- Query history
- Resource monitors
- Task and stream objects
- CI/CD
Separated compute makes cost attributable per workload, but only if warehouses are separated deliberately in the first place.
Technology marks belong to their respective owners. No partnership, certification or endorsement is implied.
Migration and modernization
What moves, and what that asks of you.
The common paths into and out of a Snowflake platform. Each changes what has to be proven before consumers move.
Planning a move onto Snowflake? The phased method, reconciliation gates and cutover plan are set out on Snowflake migration services.
Legacy on-premises warehouseSnowflake
Teradata, Netezza and SQL Server estates carry procedural logic and physical design assumptions that do not transfer. Discovery and reconciliation dominate the effort, not data movement.
Redshift or another cloud warehouseSnowflake
SQL translates comparatively cleanly. The work moves to workload isolation, access model design and re-establishing a cost baseline under separated compute.
SnowflakeA lakehouse
Worth considering when machine learning and engineering workloads need direct file access, or when open table formats are a deliberate portability decision. External tables and Iceberg support reduce, but do not remove, the move.
Scattered extracts and spreadsheetsSnowflake
The most common starting point in practice. The platform is the smaller half; agreeing metric definitions and ownership is the larger one.
Performance and economics
What drives the bill.
Separated storage and compute changes cost from a fixed capacity question into a usage question, which helps some workloads and penalises others.
For the operating detail of reducing a Snowflake bill, read Snowflake cost optimization.
- Compute
- Billed per second while a warehouse runs. Auto-suspend settings and warehouse size are the two levers that most change the bill.
- Concurrency
- Multi-cluster warehouses absorb concurrent load by adding clusters, which protects performance and scales cost with it.
- Workload isolation
- Separate warehouses stop a heavy transformation contending with reporting, and make each workload's cost attributable.
- Storage
- Comparatively inexpensive, but time travel, failsafe and unmanaged clones accumulate without anyone deciding they should.
- Cost governance
- Resource monitors and per-workload attribution make an expensive query a visible decision rather than a monthly surprise.
Governance and security
What has to be designed first.
What has to be designed rather than configured after the fact.
- Role hierarchy
- Functional roles granted to access roles, designed once. Retrofitting a hierarchy after hundreds of grants exist is materially harder than designing it first.
- Row and column policies
- Row access policies and masking applied in the platform so every consuming tool inherits them, rather than each BI tool reimplementing the rules.
- Data sharing
- Sharing without copying is a genuine strength and a governance obligation: what leaves the account, to whom, and under what agreement.
- Time travel and retention
- Retention windows are a cost and a compliance decision at once, and the default is rarely the right answer for either.
- Auditability
- Query history supports access review and reconciliation, and it is only useful if someone is accountable for reading it.
Trade-offs
When it fits, and when it does not.
Where a Snowflake platform tends to fit, and where another architecture deserves consideration. Both halves matter; a page that only states the first is not telling you anything you could act on.
Where Snowflake tends to fit
- Governed analytical workloads with many concurrent readers and a SQL-first team
- Estates where workload isolation and attributable cost are explicit requirements
- Organisations consolidating access control that is currently reimplemented per BI tool
- Data sharing with partners or business units without copying data between systems
Where another answer deserves consideration
- A lakehouse such as DatabricksMachine learning, feature engineering and large-scale file processing need direct access to the same data, rather than reading an analytical copy of it.
- BigQueryThe estate is already on Google Cloud, or a serverless model with no cluster to size suits the team better than managing warehouses.
- Staying on the current platformThe real constraint turns out to be pipeline design, metric governance or unattributed cost, all of which travel with you to a new platform.
- A transactional databaseThe workload is operational rather than analytical. Snowflake is not a substitute for a system of record serving single-row reads at high frequency.
References
Primary sources for this platform.
Vendor documentation, linked for verification. It is not an endorsement, partnership or certification.
Related on Quorlytic
- SolutionsCustomer 360
- IndustriesFinancial services
- InsightsWarehouse Migration Playbook
- InsightsSnowflake vs Databricks
- InsightsSnowflake Cost Optimization
- InsightsETL vs ELT
- InsightsTeradata to Snowflake Migration Guide
- InsightsOracle to Snowflake Migration Guide
- InsightsNetezza to Snowflake Migration Guide
Next step
Review your Snowflake architecture.
Bring a query history export. Warehouse topology and cost questions are answerable from it in a first conversation.