_peregrine_

as a tpuf employee i can say we feel very well represented in this article. author did a really nice job. good read too

confirmed - we still write by hand

instant bookmark!

this is actually not how cursor uses turbopuffer, as they index per codebase and thus need many mid-sizes indexes as opposed to one massive index as this post describes

unfortunately i'm not able to share the customer or use case :( but the metrics that you see in the first charts in the post are from a production cluster

the solution described in the blog post is currently in production at 100B vectors

seems like a good rule of thumb to me! though i would perhaps lump "cost" into the "until it breaks" equation. even with decent perf, pg_vector's economics can be much worse, especially in multi-tenant scenarios where you need many small indexes (this is true of any vector db that builds indexes primarily on RAM/SSD)

yeah I mean that's basically what Javi talks about in the post... if you can throw hardware at it you can scale it (ingestion scales linearly with shards)

but the post has some interesting thoughts on how you do the high-scale ingestion while also handling background merge processes, reads, etc.

definitely interesting and related

nice one

Pretty solid at SQL generation, too. Just tested in our generation benchmark: https://llm-benchmark.tinybird.live/

Not quite as good as Claude but by the best Qwen model so far and 2x as fast as qwen3-235b-a22b-07-25

Specific results for qwen3-coder here: https://llm-benchmark.tinybird.live/models/qwen3-coder

Yeah we're always looking for new models to add

Yeah I mean SQL is pretty nuanced - one of the things we want to improve in the benchmark is how we measure "success", in the sense that multiple correct SQL results can look structurally dissimilar while semantically answering the prompt.

There's some interesting takeaways we learned here after the first round: https://www.tinybird.co/blog-posts/we-graded-19-llms-on-sql-...

We need to add it

Actually no, we have it up to 3 attempts. In fact, Opus 4 failed on 36/50 tests on the first attempt, but it was REALLY good at nailing the second attempt after receiving error feedback.

We should definitely add o3 - probably will soon. Also looking at testing the Qwen models

Noted, also feel free to add an issue to the GitHub repo: https://github.com/tinybirdco/llm-benchmark

No it's definitely interesting. It suggests that Opus 4 actually failed to write proper syntax on the first attempt, but given feedback it absolutely nailed the 2nd attempt. My takeaway is that this is great for peer-coding workflows - less "FIX IT CLAUDE"

yeah this was a surprising result. of course, bear in mind that testing an LLM on SQL generation is pretty nuanced, so take everything with a grain of salt :)

yeah that surprised me too

According to our SQL Generation Benchmark (methodology linked in the results dash), Claude Opus 4 is the best of the popular models at SQL generation by a pretty decent margin.

Already test Opus 4 and Sonnet 4 in our SQL Generation Benchmark (https://llm-benchmark.tinybird.live/)

Opus 4 beat all other models. It's good.

Chance to win >$3000 in credits from devtools like Vercel, Tinybird, Dub, Resend, etc.

Since MCP Servers are installed locally, it can be a bit painful to log and analyze usage of MCP Servers you built. My coworker built a utility to capture remote logging events from our MCP Server, could be extended to any MCP Server. Free to use, easy to set up. It uses Tinybird to capture events + generate Prometheus endpoints for Grafana, Datadog, etc.

This is the full, unedited transcript of our conversation with Claude, whose context-awareness is provided by a v0 Tinybird MCP Server.

I think Tinybird is a nice option here. It's sort of a managed service for ClickHouse with some other nice abstractions. For your streaming case, they have an HTTP endpoint that you can stream to that accepts up to 1k EPS and you can micro-batch events if you need to send more events than that. They also have some good connectors for BigQuery, Snowflake, DynamoDB, etc.

I am not sure of specifics on features, but I think the fundamental difference is that Arroyo is a stream processing engine i.e., it doesn’t have a database, whereas Tinybird has the statefulness afforded by ClickHouse as its primary data store. Arroyo would be more like Flink, Tinybird would be more like ClickHouse.

Disclaimer: I work for Tinybird.

+1 for Tinybird

Ahh okay, this answered my question: https://www.tinybird.co/blog-posts/mockingbird-announcement-...

It's an open source library and you can build new destination plugins. That's cool!

This seems pretty cool. So you can only send data to Tinybird and Upstash? Any support for other destinations?