pancomplex

Works with any frontier LLM model

No definitely not!

Our customers run the training on their own applications using a demo or staging environment. Then they install the in-app agent you see in the demos and turn on the tool calls they like. All the API calls are executed client side and never touches any of our servers.

Not at this point - but we’re considering it! What would you use it for?

Thank you! Along those lines, we did Airbnb too: https://demo.frigade.com/

thank you!

100% - that's why it's so confusing why PMs/PMMs think they need to keep adding these to their products.

tbh adblockers should just filter these out. I guess the reason they don't is it's "technically" the product ¯\_(ツ)_/¯

couldn't agree more - they always pop up at the right time. I don't know why every PM thinks they can save retention by spamming users :(

seems non of these are typescript-based? Strand appears to have a typescript sdk available but not natively ts.

We use typescript for all our entire stack and it's super dope to see a production-grade framework (with no vendor lock in) launch!

Yes

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).