upvote
> The article then ends before saying if the new setup solved their problems.

They got to put ClickHouse, DuckDB and Trino on their resume & LinkedIn. Problem solved!

reply
Things like this are a part of why I push back on people telling me we can do important things later. I don’t want to swap the engine out of a machine that’s moving that fast. There’s no time to learn about how it behaves with real versus synthetic traffic and what the failure modes are when you’re doing many thousands of transactions per second.

Why wouldn’t you want to sort stuff like that out when the problem is still relatively small?

The only other reasonable option is to wait until the problem gets so big that it splits into several domains. And then you can move one domain over, see how that goes, and move more over if it goes well.

If you can’t know for certain how the system will behave under organic load that may mean migrating traffic onto the new system and then back to the old one several times, which means you need migrations in both directions and each transition is an opportunity for human error to destroy data or take the service offline.

reply
> Things like this are a part of why I push back on people telling me we can do important things later. I don’t want to swap the engine out of a machine that’s moving that fast. There’s no time to learn about how it behaves with real versus synthetic traffic and what the failure modes are when you’re doing many thousands of transactions per second.

Counter-point - the longer you delay a crucial decision the more information you have to make it a correct one, so you might avoid migrating DB engine twice a year

reply
>The article then ends before saying if the new setup solved their problems.

This reads to me like a recruiting post; thats why they are open if it solved their problems. I'm not a fan of the way they framed it, it seems they have made their architecture decision and now need help implementing this.

I'd imagine if you are the kind of person that wants to work on large scale data query problems this is an invite for you to apply. That said, if you are that person it might not be ideal to join after all the fun decisions have been made.

reply
Founder here -- this is about our warehouse product which is separate from our main analytics DB. Our DuckDB warehouse was used by a handful of pilot customers. Our clickhouse database is serving all of our analytical queries.
reply
If this is a pilot program for a small number of users, the blog post would feel a lot more logical.

As it was written, it looks like the engineering team is migrating the core infrastructure of the company around.

reply
It reminds of people who use ORMs, never pop the hood to analyze the queries, indexes, etc - then decide it's the database that's the problem.
reply
There are many good reasons why the industry largely moved away from having DBAs as a specialist position. But one downside I've seen is that it's increasingly common to have teams decide to just switch platforms without fully exploring whether that's really necessary.

I'm not really surprised. Data storage and data access technology is a pretty large subject all by itself, and a "jack of all, master of none" developer might never develop the expertise needed to properly optimize a database.

reply
What's wrong with ClickHouse again?
reply
I think it was closer to what they need; it comes down to keeping TB of data on local SSD and having a query engine next to it. That takes persistent, shared CPU, caching, sharding, resource management, etc.

Duckdb is an interesting approach to resource management (all ephemeral), but TB's are TB's. I doubt it was finding data where it needed it.

Clickhouse seems slow at getting to the top end of scaling; it's stuck with the 99% of its userbase doing 1 GB queries. I'm hoping they put some of their money into it.

reply
ClickHouse is fast OLAP. Just do Iceberg with Trino like a normal big data person. WTF?
reply
DuckDB is now close to competitive with Trino. As the post shares, large distributed multi-tenant data systems require a ton of work no matter what technology you use, but as a huge DuckDB fan, I do have to agree that it is not an out of the box data warehouse, though check back in a year or so when DuckLake and DuckDB 2.0 have had time to mature a bit more for this use case.
reply
I don’t know? They have blog posts about it but I don’t know how much I’d trust them because their chosen replacement only lasted 5 months before the next replacement.
reply
Unless something has changed in the last year, a lot of teams have serious problems with stability.
reply
PostHog has listed a lot of job openings in the last couple of years. I figured growth but maybe it’s turnover.
reply
I am curious to learn more about those issues, anyone have shared their experience publicly? would love to read
reply
reply
That's where it started very long ago, but they are based out of the Netherlands mostly now.

https://clickhouse.com/blog/we-stand-with-ukraine

> We have no infrastructure, servers or people in Russia. The original engineering team successfully moved out of Russia and are now working in our Amsterdam office.

reply
You can take the guy out of Russia.. :)

I kid but that's probably what people have a problem with.

reply
No support for real S3 (zero copy replication) in the open source version.
reply