alrocar

We made the exercise to building a "wrapped" kind of feature for our users.

Being an analytics data platform on top of CLickHouse made it "simpler" because we are used to develop and support that kind of uses cases, but still that's the full story for those interested on the internals of those kind of features.

just ran the LLM to SQL benchmark over opus-4.1 and it didn't top previous version :thinking: => https://llm-benchmark.tinybird.live/

Learn how to effectively use partitioning, sorting and compaction, and when Apache Iceberg is not enough for real-time analytics

See README.md => https://github.com/tinybirdco/llm-performance-tracker

Awesome stuff! Just published something similar today

Just curious, what is the most challenging thing in your opinion when building such log viewer?

I cloned the Auth0 activity page - and made it better - by connecting the Auth0 logs to Tinybird and sprinkling on some LLM magic.

mmm didn't know about that, but my server may have big latency so it could happen. I see there's a reproducer in the issue, I'll take a look.

Good thing to me (besides being an open spec) is their simplicity, with libraries such as FastMCP you can just bring stuff you already have implemented into Claude (or any MCP client).

We recently built an MCP server (https://github.com/tinybirdco/mcp-tinybird/tree/main) so our users could ask questions to their workspace. We released fast and since MCP servers run locally we lacked observability on product metrics, error monitoring and all that stuff you usually want when you are in production.

Built something generic to monitor MCP servers (https://github.com/tinybirdco/mcp-tinybird/tree/main/mcp-ser...) using events + tinybird + prometheus + grafana, but I'm wondering what others are using for that purpose?

Some individuals in the AI space mentioned they didn't quite understand what AnthropicAI MCP is about.

Here's a complete walkthrough of how I built an MCP server to connect Tinybird and Claude, so you can build yours

I'm really interested in different points of view.

I guess you mean the kind of trunk based development? But still some sort of CI happens, maybe locally.

Never worked in a different way than using a local / remote CI pipeline, that's why I'm curious.

Thanks for this comment. I guess there's sometimes we (developers) take things for granted when they are not, and that puts a lot of pressure on us instead of celebrating our wins.

I would change now "pretty standard" by "we don't invented the wheel" xD :pray:, in the end I wanted to mean we use existing tools and "just" put them together

Yep, it's part of our culture, we do many releases per day to constantly iterate things. Also as in other projects there are maintenance and bug fixing we want to bring to production as soon as possible.

Our context is the one of a startup that is constantly validating things, also in our context a release does not necessarily mean releasing to the users, sometimes stuff is behind feature flags or for beta testing.

Yep, default runners in most CI platforms shared resources so they are prone to produce flakiness (depending on your set up).

That was one of the reasons we ended up setting up our own runners. Didn't mention in the post but we use spot VM instances.