Snowflake is good software. We have shipped on it, our clients run it, it solves problems that Postgres cannot. None of that is the question. The question is whether a company at Series A scale needs it yet. In almost every case we have seen, the honest answer is no.
What "needing a warehouse" actually means
A data warehouse is for separating analytical workloads from your transactional database. The point is that your finance team's heavy quarterly reports don't lock up the product database during business hours. The point is also to combine data from multiple sources: your Postgres, your Stripe, your Segment events, your Salesforce, your ad platforms.
If you have one or two data sources and one or two analysts running ad-hoc queries, you don't need a warehouse. You need a read replica.
The pattern that works through Series B
Here is what we recommend for companies between 15 and 100 people, doing under $20M ARR, with one to three analysts:
- One Postgres read replica, sized for analytical queries (more RAM than the primary, slower CPU is fine).
- A handful of dbt models, materialized incrementally, running on a nightly cron.
- Metabase or Hex or Mode pointed at the read replica.
- For external sources (Stripe, Salesforce), nightly ingestion via Fivetran or Airbyte into the same Postgres replica.
That stack costs around $400 to $800 a month all-in, scales to billions of rows in well-designed tables, and is operationally simple enough that one engineer can own it part-time. We have run this exact shape for five clients. Two of them have outgrown it. Three haven't, after years.
What Snowflake actually costs in practice
The sticker price you see in marketing is misleading. The real cost includes:
- The compute, billed by the second, which sounds great until you realize each scheduled dbt run wakes up the warehouse for 90 seconds at a $4/hour rate.
- Storage, which is cheap, until you find out you've been writing every Segment event into a table with no partitioning.
- An additional ingestion tool, since Snowflake doesn't pull from your transactional databases on its own.
- An additional layer of access control, separate from your application's RBAC.
We have audited Snowflake bills for four clients in the last year. The cheapest was $1,400 a month. The most expensive was $5,800. Two of them could have been doing the same work on a $200/month Postgres replica.
The point where Snowflake starts to make sense
Roughly the moment you have:
- Four or more concurrent analysts, hitting the warehouse hard enough that query queues become a thing.
- Multiple BI tools that need consistent semantic layers.
- External data shares with partners or customers.
- A real data team (data engineer plus analytics engineer plus analyst) who can own the cost optimization work.
If you don't have those, you don't have the operational maturity to use Snowflake well. You will end up with a $40,000-a-year bill that mostly funds Snowflake's quarterly earnings call.
A real example
One of our clients spun up Snowflake at Series A because their previous CTO had used it at his last company. We came in nine months later. They were spending $3,200 a month on Snowflake, mostly on a single nightly dbt run that re-materialized 40 tables from scratch. There was one analyst, who used the data three times a week.
We moved the same dbt project to a Postgres read replica. Same tables, same queries, same Metabase dashboards. The replica costs $260 a month. They saved $36,000 a year and the dashboards loaded faster, because Postgres doesn't have the warehouse cold-start problem.
None of this is a criticism of Snowflake. It is the right tool eventually. The mistake is reaching for it before you need it, because everyone in the Series A founder Slack channel said you should.
How to know when to switch
The signals that you are about to outgrow Postgres for analytics:
- Your nightly dbt run takes longer than 30 minutes and is starting to overlap with analyst working hours.
- You are storing more than 500 GB of analytical data and the replica is straining on writes.
- You have hired a second or third analyst and they keep stepping on each other's queries.
- You have a real reason to share data outside your company (partner dashboards, customer-facing analytics).
When you see two or three of those, start planning the migration. Until then, the boring Postgres setup is doing fine, and the budget is better spent on hiring.