pancomplex

Yes! We have full i18n support and are available in the EU as well as US

Didn't demo it here, but the product comes with an entire AI-powered insights module with exactly these kinds of data :)

I personally use it in AWS and it has helped me resolve multiple production issues. Will record a demo some time in the future.

That's exactly right. We also have other aliases for systems that don't allow + or require special auth via Google/Microsoft and even SSO.

Fair point :) believe it or not, this website was actually manually built from scratch.

Currently we work will all kinds of software products, so haven't settled on any specific industry yet. But we do see a lot of interest from software with less technical end users.

And we haven't really seen security or privacy issues in terms of competitor leakage. There is more concern around customer data and privacy, and in that regard, we invest heavily in security and have safeguards to help minimize the risk of any customer data issues.

Thank you for the feedback! We may have gone a little too hard with the animations. What browser/system are you on?

In theory it could -- but we currently still depend on modern LLMs due to their great latency vs locally run LLMs.

thank god hn is hosted on a single bare metal server, free of all this bloat.

This seems like something that was evident for AI to disrupt into. I recently went through an entire underwriting process when getting my first mortgage and honestly was shocked with how slow and old-fashioned the process was. Even had to fax a few documents (!?).

Is your target market consumer or b2b financiers?

I am thinking about setting this up as as a configuration for the type of traffic that doesn't require Kafka.

That being said, Kafka has in my experience come in super handy again and again, simply because it adds an incredible extra layer of fault tolerance when running at scale, including the ability to replay events, replicate, fail over, etc. I'd be nervous about letting the amount of throughput we receive directly interface to ClickHouse (though I'd be excited to run an experiment with this).

We were inspired by datalakes and thought the name of a super deep lake could be a cool domain. Turns out 10 of the deepest spots on Earth are all trenches, and the domain was cheap, so we went with trench.dev https://www.marineinsight.com/know-more/10-deepest-parts-of-...

In my experience, at scale (~2-3k QPS), you'd run into a bottleneck ingesting so many events without Kafka. If you don't have this level of throughput, you could totally do the above and still get the advantages of ClickHouse's columnar datastore.

The stack is indeed very similar to Posthog. The biggest difference is that we don't come with all the feature bloat (Session Recordings, Feature Flags, Surveys, etc.) and instead provide a very minimal and easy to use backend + API that is applicable to a ton of use cases.

We (Frigade.com) actually use Posthog as well as Trench in production. Posthog powers all our website analytics. Trench powers our own SDK and tracking scripts we ship to our own customers.

I actually tried to spin up Posthog originally before building Trench, but there was just way too much overhead and "junk" we didn't need. I would need to strip out so many features of their Python app, it would eventually be faster to build a clean solution in Typescript ourselves.

Yes for sure. We intentionally designed Trench to be very unopinionated when it comes to the application. So you can use it to stream and query anything from page views, log traces to IoT object events.

Thanks for flagging. Just fixed this. Grafana is intentionally not included by default -- but it takes a few minutes to set it up. We're still trying to figure out what to bundle by default in terms of UI -- for now it's API only.

Once you've outgrown a single physical server, you can continue to scale the Trench cluster by spinning up more Trench application servers and switching to dedicated Kafka and ClickHouse (either self-hosted or via cloud offerings). You can also shard Trench itself depending on the structure of your data (e.g. 1 Trench instance per customer, use case, etc.)

Auto-archiving to cloud for Kafka (Confluent, AWS KMS, etc.) / ClickHouse (ClickHouse Cloud, etc.) is definitely high on the roadmap.

I think a major difference is that Jitsu depends on you having a data warehouse whereas Trench can be spun up as a standalone system. The nature of Trench's data is also to enable real-time querying a high scale which will be much slower when depending on ETL'ed data in a data warehouse.

Thank you!

1) All data is partitioned based on the "instanceId" of events (see `instanceId` here: https://docs.trench.dev/api-reference/events-create). Instance IDs are typically a logically meaningful way of separating users (such as by company/team/etc.) that allows for sharding the data across nodes.

2) Yes, this the number 1 thing on our roadmap right now (if anyone is interested in helping build this, please reach out!)

3) We're using the Kafka engine in ClickHouse for throttling the ingestion of events. It's partitioned by instanceId (see #1) for scaling/fast queries over similar events.

4) My benchmarks in production showed a single EC2 instance (16 cores / 32 gb ram) barely working at 1000+ inserts / second with roughly the same amount of queries per second. Load averages 0.91, 0.89 0.9. This was in stark contrast to our AWS Postgres cluster which continued to hit 90%+ CPU and low memory with 80 ACUs, before we finished the migration to Trench.

5) We seemed to solve this by running individual Node processes on every core (16 in parallel). Was the limit you saw caused by ClickHouse's inbound HTTP interface?

6) Right now the system uses just a default MergeTree ordered by instanceId, useId, timestamp. This works really well for doing queries across the same user or instance, especially when generating timeseries graphs.

7) I am still trying to figure out the best Kafka partitioning scheme. userId seems to be the best for avoiding hot partitions. Curious if you have any experience with this?

Let us know how the migration goes and feel free to connect with me (christian@trench.dev).

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.

Good news is you’re not required to write any HTML when your engineering counterpart has wired up your component. We have a visual editor powered by Tiptap that anyone can use

I am not too familiar with Magic Loops, but really there's nothing stopping you from building such a pipeline. Frigade allows you to use any schema for your content and state management.

We're targeting non-tech users who have some engineering resources available to wire up the React components. Once wired up, any non-tech user can deploy new versions of the same component without writing any code themselves (I demo this in the YouTube video around here: https://youtu.be/qrPip41Ecyg?feature=shared&t=70 ).

Not tightly coupled to React. You can use it with our Vanilla JS SDK that works with any Javascript stack (https://www.npmjs.com/package/@frigade/js) using the `getCollections` function: https://docs.frigade.com/v2/sdk/js/frigade#getcollections

Any features specifically you feel is missing in Frigade? Always trying to make the product better!

Ah my bad, Digital Adoption Platform :)

We also have a Vanilla JS SDK: https://docs.frigade.com/v2/sdk/js/quickstart

We’re focusing on React to start as it has most adoption.

Intercom is great too, depending on the type of product you’re building.

Appreciate the feedback — I think we can do a better job for folks not familiar with DAPs to explain the value prop.

Appreciate the feedback! We’re mostly serving b2b saas companies, but we do offer volume discounts.

We also only count people who actually interact with Frigade — not just your total MAUs.

Thanks! Totally makes sense re: who this is for. What we’ve seen work well is that the engineering team does the initial setup, and then after setting up the guard rails and look and feel, non technical folks can come in and manage the system from then on.