This is not a feature list copied from Snowflake's marketing page. Two of our engineers used Snowflake in production across two client engagements, and we asked them to share what they liked, what frustrated them, and what they would tell someone evaluating it today.
Their feedback is direct, practical, and unfiltered. We have organized it into themes, but the observations are theirs.
What Works Well
Performance on Large Datasets
Both engineers agreed on this without hesitation: Snowflake handles large data volumes comfortably. Queries are fast, there are no noticeable performance bottlenecks at scale, and the platform does not degrade the way some managed databases do when you push volume.
One engineer put it simply: "It does its job perfectly, it's snappy, and I have never had a performance issue."
For teams working with millions of rows across multiple tables, this matters. Some cloud databases start struggling when you layer complex joins on top of high row counts. Snowflake does not.
SQL and Python Side by Side
Snowflake lets you switch between SQL and Python within the same workflow. This is genuinely useful when you need to do something that SQL handles awkwardly, like string manipulation, custom parsing, or lightweight statistical transformations.
Instead of exporting data to a notebook, transforming it, and loading it back, you can do everything inside Snowflake. For data engineers who move between SQL and Python daily, this reduces context switching and pipeline complexity.
Built-in App Builder
Snowflake includes a drag-and-drop interface for building lightweight data apps directly on top of your warehouse data. For teams that need a simple internal tool (a KPI tracker, an operational status page, a data quality monitor), this can eliminate the need for a separate BI platform entirely.
It is not a replacement for Power BI or Tableau when you need full dashboarding capabilities, but for straightforward use cases it saves a tool, a license, and an integration.
Fully Managed Infrastructure
Unlike self-hosted databases such as MySQL or PostgreSQL, Snowflake handles infrastructure, security, backups, and scaling automatically. Your engineers focus on schema design and query logic instead of server provisioning, patching, and disaster recovery.
This is the core value proposition of any managed data warehouse, but it is worth noting because the alternative (running your own database on EC2 or a VM) still carries real operational overhead that many teams underestimate.
Cost Positioning
Snowflake's pay-per-query pricing model can be cheaper than running a managed database on AWS (RDS, Aurora) or Azure (Azure SQL, Cosmos DB) for analytics workloads. If your queries are intermittent rather than continuous, you are not paying for idle compute time.
This makes Snowflake particularly attractive for companies already on AWS or Azure who want a dedicated analytics layer without the cost of a continuously running database instance.
What Is Frustrating
Case Sensitivity Is Counterintuitive
This was the most emphatic piece of feedback: Snowflake's handling of case sensitivity is unnecessarily confusing.
If you write SELECT my_column FROM my_table, Snowflake silently converts it to SELECT MY_COLUMN FROM MY_TABLE. If your actual column and table names are lowercase, the query fails. The fix is to wrap every identifier in double quotes: SELECT "my_column" FROM "my_table".
This behavior is technically SQL standard compliant (unquoted identifiers fold to uppercase per the ANSI spec), but almost no other database enforces it this strictly. PostgreSQL folds to lowercase. MySQL ignores case entirely on most platforms. BigQuery does not care.
For engineers coming from any of those environments, Snowflake's behavior feels broken until you learn the rule. And once you learn it, you spend time quoting identifiers that you would never need to quote anywhere else.
The UI Splits Exploration and Querying
Snowflake's web interface has a database exploration section (where you can browse schemas, preview columns, and check data types) and a separate query editor section. These are not side-by-side. Switching between them reloads the page and breaks your flow.
If you are writing a query and need to check a column name or data type, you have to leave the query editor, navigate to the explorer, find what you need, then go back. In BigQuery, the schema browser sits right next to the query editor. In DBeaver or DataGrip, everything is in one window.
This is a UI design issue, not a platform limitation. It does not affect Snowflake's capabilities, but it slows down daily work. Engineers who connect through a desktop SQL client (DBeaver, DataGrip) avoid this problem entirely.
No Filtering or Sorting in Data Preview
When you preview data in the Snowflake UI, you cannot filter, sort, or search within the results. You always have to write a query.
Azure Databricks, for example, lets you interact with preview data directly, which speeds up data quality checks significantly. In Snowflake, even a quick "does this column contain nulls?" question requires writing and running a query.
Again, this is a UI convenience issue. It does not limit what the platform can do, but it adds friction during data exploration and QA.
Strict Date Parsing
Snowflake is very particular about date formats. Dataframes with date fields that any other database would parse and ingest correctly sometimes fail in Snowflake with "invalid date" errors.
This means that data pipelines that run without issues on PostgreSQL, MySQL, or BigQuery may need format adjustments when targeting Snowflake. It adds a conversion step that feels unnecessary when the source data is clearly valid.
On the other hand, strict parsing prevents silent data corruption. It is a trade-off: more upfront work during ingestion, fewer surprises downstream.
When Snowflake Makes Sense
Based on what our engineers observed, Snowflake is a strong fit when:
- You need a managed analytics warehouse and do not want to run your own database infrastructure
- Your queries are intermittent, making pay-per-query pricing more cost-effective than always-on instances
- You are already on AWS or Azure and want a dedicated analytics layer that integrates cleanly with your existing cloud
- Your data volumes are large and you need consistent performance without manual tuning
- Your team writes SQL and Python and benefits from having both in the same environment
Snowflake is less ideal when:
- Your team relies heavily on the web UI for daily work (the split between explorer and query editor is a real productivity drag)
- You are migrating pipelines from other databases without budget for reformatting date fields and adjusting case sensitivity
- You need a simple, low-volume database where PostgreSQL or MySQL on a small instance would be cheaper and simpler
How It Compares
| Factor | Snowflake | BigQuery | Self-hosted PostgreSQL |
|---|---|---|---|
| Infrastructure management | Fully managed | Fully managed | You manage everything |
| Pricing model | Pay-per-query + storage | Pay-per-query + storage | Fixed instance cost |
| SQL dialect quirks | Case sensitivity, strict dates | Minimal quirks | Familiar, widely documented |
| UI experience | Split explorer/editor | Integrated sidebar | Depends on client tool |
| Python integration | Native (Snowpark) | Via notebooks/Dataflow | External only |
| Performance at scale | Excellent | Excellent | Depends on hardware/tuning |
Final Take
Snowflake is a solid cloud data warehouse that performs well under load and removes infrastructure burden from engineering teams. The frustrations our engineers flagged (case sensitivity, UI flow, date parsing) are real but manageable once you know the patterns. None of them are dealbreakers.
The honest summary: once you get past the initial adjustment period, it becomes a reliable part of your data stack. Both engineers said they would recommend it.
If you are evaluating Snowflake for your analytics architecture, we can help you design the warehouse, set up the pipelines, and avoid the gotchas. Visit our Snowflake Consulting page or book a meeting to discuss your setup.
