What does Snowflake offer you that you can’t get from Postgres or even an analytics engine like Elasticsearch? (I understand the general differences but curious about your specific situation)
Also what “upstarts” did you not consider over JIRA?
Also what “upstarts” did you not consider over JIRA?
Good things:
- it's pretty fast (it does automatic partitioning of your data based on usage patterns, which is sweet)
- it integrates with your cloud storage pretty transparently
- the SQL dialect is pretty full-featured (it even has about half of PostGIS, which was useful to me recently)
- it's pretty fast, without custom tuning (which is annoying)
- the docs are pretty comprehensive, and they have a set of tutorials which are great (even if I only found them by accident).
Problems:
- No SparkSQL. Spark is super, super annoying, but the notion of PySpark and sparkr were pure genius. Why yes, of course I want to write my ETL in a real programming language (can define a function to remove 100+ case when statements.
- It's very, very expensive, and their purchasing model seems designed to prevent people from realising this.
- It's proprietary.
Not the OP, but this is why I like Snowflake (and I've been using solutions in the distributed SQL space for almost a decade at this point).
>It's very, very expensive, and their purchasing model seems designed to prevent people from realising this.
How is it expensive in a way that's not transparent?
The real trouble is that they don't show the credits used anywhere in their SQL interface (there's a table, but you need to go looking for it). If they wanted to help you keep costs down, they'd show you how many you'd used without needing to jump through hoops.
As I said, great product, but pricing could be a lot more transparent.
– Ability to ingest 100s of terabytes to petabytes of data per day, and store those for months to years.
– Ability to provide a delightfully interactive user experience, despite managing terabytes of data.
– Ability to work efficiently with semi-structured data (i.e. the messy slop you find in logs).
– Ability to efficiently execute the kinds of band-joins and window analytic functions needed for us to realize efficient queries on Resources.
– Unit economics that make sense for the Observability use-case.