Written by 
The hidden cost on most Snowflake bills
Snowflake is built for analytics: a few big questions asked of a lot of history. Scan a billion rows, aggregate, join, return. The pricing (credits per warehouse-second) fits that shape of work, where a query takes seconds and nobody minds.
On this page
The other kind of database work is the application’s own traffic: thousands of single-row lookups, small updates, a worker checking a status every few seconds. Millions of tiny questions instead of a few big ones, each needing an answer in milliseconds. (The industry calls the first one OLAP, for online analytical processing, and the second OLTP, for online transaction processing.) Point a warehouse at the second kind and it still charges you like the first.
Each of those small queries pays a cold-start tax: hundreds of ms warm, seconds cold, against work that should take single-digit ms. The warehouse spins up, the query runs in milliseconds, the warehouse keeps a minimum billable window open. Multiply by every worker tick and every dashboard refresh, and in this case the only way to make the latency tolerable was to keep an operational warehouse running all the time. That warehouse cost around £5,000 a month to do work a properly built database handles in a few milliseconds. The line item for “operational data” had overtaken the line item for the analytics it was meant to enable.
If your Snowflake spend has been creeping up while your reporting and analytics workloads have not, our experience says look at the operational side first.
What Snowflake Postgres changes
Snowflake Postgres is a managed PostgreSQL database that runs inside your Snowflake account. PostgreSQL is the open-source database behind a large share of the web, and it answers the small, constant questions an application asks in milliseconds rather than seconds.
It also runs on a laptop. Developers get a faithful copy of the production database locally, so work is built and tested properly before it reaches customers. That is a quieter benefit than the bill, and the engineers will tell you it is the one they feel every day.
You get the full engine, not a cut-down version, with thirty years of production hardening behind it. The same database that serves the application also does full-text search and geospatial work, so neither needs a separate product bought, integrated and paid for. It can also power a modest AI feature, the kind that answers staff questions from your own documents, so a first retrieval-augmented generation project does not need a specialist AI database bought alongside it. Whatever the operational data turns out to need next, the odds are Postgres has done it in production for a decade. We’ve written up Postgres full-text search in depth separately.
What stays the same:
- The security boundary. Same Snowflake account, same access rules your team already administers.
- The billing relationship. One vendor, one invoice, one procurement conversation.
- Co-location with your warehouse. Analytical and operational data sit side by side in the same account, and the warehouse can read the operational tables directly (we are using that for backups first, with more uses planned).
- Analytics on the operational data. Moving the application traffic off the warehouse doesn’t cut analysts off from it. Native Snowflake Postgres mirroring streams the Postgres tables continuously into a read-only Snowflake database, so the operational data stays queryable next to your warehouse data. You get the cheap operational engine and keep the analytics.
What you trade:
- Vendor-controlled upgrades and backups. Snowflake decides when the database is upgraded, and you rely on its built-in snapshots rather than running backup tooling of your own.
- A new networking surface. The database and the application do not share a private network inside the account, so connecting them safely takes deliberate setup and a security review. Solvable, but not free.
- A different operational mental model. A database needs a little routine tending that a warehouse does not, so the team picks up some new maintenance habits.
A real migration, with numbers
The client runs a survey-operations platform on Snowflake: pricing decisions, pipeline state, response data, fraud scores. All application traffic, none of it analytics. We moved that operational footprint onto a single Snowflake Postgres instance and kept the warehouse for what it is good at: reporting, analytics, and deciding who is allowed to see what.
| Metric | Before (Snowflake warehouse) | After (Snowflake Postgres) |
|---|---|---|
| Operational rows migrated | n/a | ~45 million across 56 tables |
| Operational compute | Dedicated warehouse, always-on (only way to hide cold-start latency) | One mid-sized Postgres instance with failover and storage, always-on |
| Monthly compute cost (operational, all-in) | ~£5,000 | ~£300 (–94%) |
| Operational query latency | Hundreds of ms (warm), seconds (cold) | 97% under 5 ms |
| Full data migration runtime | n/a | ~40 minutes (one-shot) |
| Production cutover downtime | n/a | Single-digit minutes |
| Time to first useful query during dev | Minutes (waiting on a warehouse) | Instant (local Docker Postgres) |
| Engineering cost to migrate | n/a | ~2 engineer-weeks (~£6,000); payback ~6 weeks |
One change didn’t fit the table: tests now run against a real copy of the database instead of a stand-in, so they stopped disagreeing with production.
When this isn’t the right call
Four disqualifications:
- You’re not already on Snowflake. The saving comes from consolidating onto a platform you already pay for and have already approved: one vendor, one security review, one contract. Without that, ordinary managed Postgres is cheaper and more flexible. This is a tidy-up for teams already on Snowflake, not a reason to join.
- This on its own isn’t the reason to adopt Snowflake. The consolidation is what makes it pay: one vendor, one security review, one contract. That only counts once the analytics case for the platform stands up on its own merits. Decide that first, and treat this as what it is, a strong addition rather than the deciding factor.
- Your application is genuinely enormous. Snowflake Postgres suits typical business applications, not systems handling a million writes a second. Benchmark first.
- You need control over upgrades and add-ons. Snowflake restricts which add-ons you can install, and decides when major upgrades happen.
The decision in one paragraph
If your Snowflake bill is paying for queries that any modest Postgres could serve in single-digit milliseconds, you are not making the best of Snowflake. You are using its most expensive primitive for its least suitable workload. For one client that misuse cost £5,000 a month; Snowflake Postgres took it to £300 without leaving the account boundary. The migration is bounded, the rollback path is real, and the per-month operational line item becomes predictable for the first time.
For most teams, the right question isn’t “should we add another database?” It’s “why are we still paying warehouse credits for state-machine ticks?”
FloreData leads the platform team at a market research company. The migration described here ran in production.
The Snowflake Postgres series: the business case · the migration write-up · cross-VPC networking · the psycopg3 connection layer · the migration script and cutover · mirroring back into Snowflake.
