Last week I shared that Tinybird is changing to a local-first experience.
This was the first step in adapting Tinybird to better fit a developer’s workflow, but deploying changes to production was still a manual, error-prone process. Not anymore.
We redesigned the Tinybird CLI to handle the hard parts of managing state changes in data infrastructure so you can focus on shipping.
Imagine this common scenario: you have an insights page in your live app.
The latency is good, but you realize you can optimize your queries by adding a materialized view. If you’re making changes in a raw database, you need to think about:
Tinybird has handled some of those things for you, but you still had to figure out how to:
A seemingly simple optimization required manual steps that were easy to get wrong. This added a ton of friction that prevented you from shipping fast.
With these changes, it's just this:
tb deployWe’re changing the Tinybird CLI to better manage data projects and state changes. We believe you should be able to do everything locally, even test a deployment.
Think about the new CLI like:
You don’t usually see so many features at the same time.
Most CLIs follow the UNIX philosophy of “do one thing and do it well.” But in Tinybird’s case, that “one thing” is handling large, complex data projects, so "one thing" becomes many things.
Read on to learn about some of our design decisions…
We were inspired heavily by Next.js. You run npx create-next-app@latest, answer some basic questions, and – boom – your app is running. In Tinybird, you can now do the same:
tb create
Like create-next-app, this generates all of the scaffolding for your project. We also added some nice features:
.cursorrules to teach your AI code editor to play nicely with the data project resources.--prompt to allow an LLM to generate the basic resources for your app.This way, you can use your AI-assisted IDE to start working fast, no Tinybird experience required (btw, you should try Cursor Agent Mode. I made this video to show how it works).
We decided to have a massively reduced set of primitives:
With those primitives, you can build any project. You only need to learn 2 things, and one of them is pretty much just SQL.
Any project needs data, but it becomes critical when your only tool is SQL. You can start up a project with:
That generates the data sources and fixtures to use during the project build.
Sometimes, your data is generated by your app and you don’t have a sample. Don’t worry, we got you covered:
Again, we are using LLMs to help you move faster. Tinybird even saves the prompt in case you want to change it later.
Nobody wants to wait 20 minutes for a build. Programming is about iteration, the faster the better. We are investing heavily in a fast feedback loop. To give you some data: When we started testing our first iteration of the new local experience, the build was 30+ seconds. Now, it’s 150ms. And we don't even use Rust. It's Python and C++.
We also added a command to get feedback about your project: tb dev
Again, we were inspired by Next.js and other frameworks. Like those frameworks, Tinybird has a dev command that listens to changes in data project resources and rebuilds the project with each change. The feedback is instant.
We decided to take it further. Instead of just checking the syntax, we rebuild the project and print the results so you can validate the logic and see the endpoint results in your terminal.
The dev command does not just listen for .datasource and .pipe resources. It also listens for changes in your fixtures and reloads it. So you can edit the fixture and see how different data affects your build.
We are still improving on error reporting. SQL is tricky, and sometimes giving the exact location for an issue is not trivial. More on that later.
Like before, you can run tb sql “select …. from table” and get results to check things ad hoc.
But now, if you already have the logic, the CLI can generate tests for you:
Again, we are using LLMs to analyze the SQL, generate a set of tests that cover all the possible paths based on the parameters, and generate the expected results. This is usually boring (and often overlooked). Now Tinybird will handle for you.
To run the tests, use the command:
But what happens when you update the logic? You can update the test as well:
This reruns the test and updates the expected result.
We are clearly differentiating the execution environments. Each environment has different properties.
There is a disposable build environment that is regenerated on each build. You can still access it and check what’s inside. Think about it like an in-memory database (sqlite).
There is a local environment where you can test the deployment using the Tinybird local container before moving to production.
And finally, there is a production environment where you can deploy to the Tinybird cloud service.
You can access environments with:
You need to pick the right environment based on your objective, but it gives you a lot of flexibility.
Internally, we've given this new CLI a codename: FORWARD. It's a good name, not only because it represents a step forward in terms of improving the Tinybird developer experience and continuing to shift toward a local-first workflow, but also because it represents the broader shift Tinybird is making to better serve all developers who need an analytics backend for their app (and want to skip the complex infra work this typically requires). Tinybird Forward is our commitment to developer velocity and modern workflows.
This is now in beta. If you want to start working with the new CLI and experience Tinybird Forward firsthand, check out the beta docs. Get help and provide feedback in the #forward channel of our Slack Community.