[Author] it was more like: we underestimated the problem and complexity of workloads our customers want to run. We did not rewrite anything but developing a new stack we can give to our customers doing warehousing. Agreed that this context is not really clear from the blog post.

Unironically, I think we will see a lot more of this given how engineering is being done currently. I have been involved in 2 green field projects in the last 2 years. Both have been rewritten or had massive "ship of theseus" type changes multiple times over that time window.

Engineers working on new products, thanks to LLMs, have very little understanding of the technical details of the product. They have the same level of understanding a traditional high level manager had of products they owned. If you ever worked in an engineering org with an M2 or M3 who always attended your outage review, and in every outage review something has to involve some issue with Postgres or your Kafka queue, that disconnected M3 would conclude:

    "Almost every outage involves some problem with Postgres. My conclusion, observed over the last 6-12 months, Postgres is bad. I see this new FancyDB or DynamoDB thing is popular on Twitter. We should try that"

I have lost count of the number of idiotic takes like that from M2s or M3s who have no idea how things work but instead focus on keywords they can latch onto that seems to be in the intersection of all issues. Then the logical solution is just to remove that and see what happens. This used to be very expensive, but if you can throw an LLM at a code base and say "Replace Postgres with FancyDB, split it to a list of logical checkpoints adding regression testing when missing to each checkpoint and open stacked PRs for all checkpoints", let it churn for an after noon, and 46k-line change PR (and $800 token bill) later you are ready to try FancyDB, why would you not give it a try? Then if you have issues with FancyDB, are you gonna spend the time to understand what's going on or just say "lets try DynamoDB next"?

[Author] Basically yes, but we spun up pods on EKS. It was hard for the customer to estimate how much they might need and hard for us to know how much capacity to provide. Given our plans on pricing on CPUHours (or similar) the logic was kinda broken.

How does Snowflake use that information? You still need to pick the warehouse. It would be cool if there was an "elastic warehouse" where heavier queries are routed to bigger Warehouses, but that's not the case

Why didn't you just use Iceberg and Trino from the get go (or Paimon if you are fancy)? This has been the accepted answer for quite some time now. The fast OLAP stores just don't scale as well as going object store to a proper query engine like Trino.

> Happy to answer more questions.

Ah yay, I appreciate it! I feel like its rare to get a look at how these decisions cone about.

What did you measure? How'd you realise there was a problem? And did you measure anything to give you confidence that Trino won't hit the same issues?

I don't know about their development or business practices, but if you think that their CEO posts on LinkedIn are serious and not satire I'm sorry to say the jokes are flying above your head a bit.

The entire website is a bit of a red flag to me, starting with the cookie banner featuring an image of Ursula von der Leyen and some misinformation (cookie banners are not legally required).