Hacker News Reader

Comment by pancomplex | Hacker News Reader

I looked around, but all the open source analytics projects I could find were bloated with all kinds of UI and unnecessary code paths. They also all seemed to use row-based RDMS as the data backbone (vs columnar stores like ClickHouse). I was looking for a backend-only solution that we could shape for our product use case that could scale.

So TLDR, if you're at a smaller scale (<1M MAUs), you probably will be fine just using a table in MySQL or Postgres. If you have a lot of traffic and users, you will need something like Trench that uses Kafka and ClickHouse.

View on HN

You are selling the underlying technologies(Kafka/Clickhouse).

I'm interested in your project can do for me, my project(s), team/company. There is a reason that most of the internet still uses PHP and old technologies. Because they focused not on the latest tech but on solving problems for others.

The project looks cool, but tell us the usecases.

Use case #1: You have a problem table (e.g. a high-volume events table) that grows non-linearly as your business starts to scale up. A queue + columnar store package like Trench moves the problem table out to a system better equipped to deal with it and lets your DB server handle its relational business in relative peace and quiet.

Maybe I wasn't clear enough but my questions have been rhetorical. They were not for me. If one starts stating technologies, it is akin to describing the individual ingredients of a sandwich.

The question remains: Why choose Trench over just using Kafka and Clickhouse or any other message queue and columnar database / big data base?

If the goal of the post and the landing website is to entice people to use the tool, then answering these questions is important. If what is being discussed seems obvious, then who is the target demographic? Because they already know the space, use alternatives or have built their own.

Probably it's just me, but your comment is very similar to the famous one on Dropbox:

My YC app: Dropbox - Throw away your USB drive

https://news.ycombinator.com/item?id=9224

These two comments are worlds apart.

My comment is feedback to better pitch the project with the goal of attracting more users.

The Dropbox comment, in contrast, is a mean-spirited criticism that just lists alternatives.

It seems pretty clearly spelled out. If you have enough traffic that an events table is slowing down your postgres instance, you can easily set this up as a service to offload the events table. The author says <1 million MAUs, and you probably don't need this.

It's built on tech known for handling very large amounts of traffic, which answers the how after the what.

Sometimes the innovation is a new underlying technology applied to an old problem?

Reply on news.ycombinator.com