Snowflake
Warehouse of choice where SQL analytics dominates and operational simplicity is valued.
Snowflake is our default recommendation when a client's analytical workload is predominantly SQL, when concurrency spikes at month-end, and when the organisation would rather not employ someone to tune a cluster. Storage and compute separate cleanly, warehouses suspend when idle, and scaling is a configuration change rather than a project.
We use the full surface where it earns its place: Snowpipe for continuous file ingestion, Streaming Snowpipe where sub-minute latency genuinely matters, Snowpark for transformations that need procedural code rather than SQL, and external tables over Iceberg where data should stay in the customer's own object storage.
The recurring engagement, though, is cost. Snowflake pricing rewards careful design and punishes carelessness severely, and we have taken over accounts where three unreviewed scheduled queries accounted for most of the bill.
Where it fits
What Snowflake genuinely gives us
Separated storage and compute
Multiple teams query the same data on independent warehouses without competing for resources.
Genuinely elastic concurrency
Month-end load is absorbed by multi-cluster scaling instead of queueing behind a fixed cluster.
Semi-structured data handled natively
JSON and nested data are queryable without a flattening pipeline, which removes a whole layer of engineering.
Time travel and zero-copy cloning
A full-size test environment in seconds, and recovery from a bad load without a restore.
Modelling for a warehouse people trust
Technical performance is rarely why a warehouse project is judged a failure. It fails when two dashboards show different revenue figures and the business stops believing either. That is a modelling and governance problem, not a compute problem, and no amount of warehouse tuning addresses it.
The discipline that prevents it is a defined layering with clear ownership. Raw data lands untransformed and is never queried directly by reporting. A cleaned and conformed layer resolves types, deduplicates and standardises keys. A presentation layer holds the metrics the business has agreed on, defined once, in one place, with the definition documented in language a finance manager can check. Any dashboard reads that layer and nothing else.
The politically difficult part is agreeing the definitions — what counts as an active customer, whether revenue is booked net of returns, which date a transaction belongs to. Those conversations belong at the start of the project with the people who own the numbers, not at the end when a discrepancy has already damaged confidence. We facilitate them explicitly, and we write the outcome into the model rather than into a document nobody reads.
Snowflake economics, and the bill nobody forecast
Snowflake is genuinely excellent technology and its pricing model punishes carelessness in a way that surprises most first-year customers. Compute is billed by the second while a warehouse is running, and a warehouse left on because someone disabled auto-suspend during a debugging session will bill through the weekend. We have reviewed accounts where a third of spend came from warehouses doing nothing at all, and others where a single badly written dashboard refreshing every five minutes cost more than the entire analytics team’s tooling budget.
The controllable levers are well understood but rarely applied by default. Warehouses sized to the workload rather than to optimism. Aggressive auto-suspend, measured in seconds. Separate warehouses per workload so a heavy load job cannot starve interactive queries and so cost is attributable to a team. Result caching used deliberately. Clustering applied only where query patterns justify the maintenance cost, because automatic clustering on a large frequently-written table is itself an expensive background process.
The other half of a successful Snowflake implementation is governance, which is easy to defer and expensive to retrofit. Role hierarchy, database and schema conventions, environment separation, and a policy on who may create what all need to be decided before the platform fills with objects nobody will admit to owning.
Where the bill actually goes
Compute, almost entirely, and within compute it is usually a small number of queries scanning far more than they need. The levers are consistent: cluster keys on the columns people genuinely filter by, aggressive auto-suspend so warehouses do not idle at cost, right-sized warehouses per workload rather than one large shared warehouse, and materialising aggregations that are recomputed dozens of times a day.
We also attribute cost by team and by query tag, so the conversation about spend is specific. A general instruction to reduce warehouse costs achieves nothing; a report showing that one dashboard's refresh accounts for a fifth of the bill achieves it in an afternoon.
Ingestion patterns
Snowpipe for continuous file-based loading from cloud storage — cheap, simple and adequate for most cases where a few minutes of latency is acceptable. Streaming Snowpipe where sub-minute latency genuinely changes a decision, which is less often than people expect. And CDC from operational databases through Debezium into staging tables, merged into target tables idempotently.
The important discipline is idempotency at the merge, so a replayed file or a retried load cannot duplicate rows. Without it, reconciliation becomes a permanent manual task.
How Snowflake projects usually go wrong
These are the failure modes we look for first when we are called in to rescue somebody else's implementation.
Snowflake questions we get asked
Including where we would recommend something other than Snowflake. Call +91 70033 91355 and you will get the same answer from an engineer.
Snowflake when the workload is predominantly SQL analytics and you value operational simplicity and easy secure sharing. BigQuery if you are already on Google Cloud and want fully serverless with no warehouse management. Databricks when significant Spark, streaming or machine learning work sits alongside SQL and your team is comfortable with notebooks. We run all three in production and the recommendation follows your workload and team, not our preference.
Usually less, but only with disciplined design. Across our migrations the median platform cost reduction is 41%, and that comes from suspending idle compute, sizing warehouses per workload and eliminating queries that scan whole tables unnecessarily. A lift-and-shift without tuning can absolutely cost more, which is why tuning is part of our migration rather than a follow-up phase.
Yes, through external tables over Iceberg or Parquet in your own S3, ADLS or GCS. You keep the data in an open format under your control and use Snowflake purely as a query engine. This is increasingly our recommendation for clients concerned about long-term platform lock-in.
Services built on Snowflake
Technologies we pair it with
Tell us what is slowing your business down.
A 30-minute call with a senior engineer — not a salesperson. You leave with an architecture sketch and an honest cost range, whether or not you hire us.
Direct line
+91 70033 91355Mon–Sat · 9:30 AM – 7:30 PM IST · Sealdah, Kolkata