How to Set Up Tinybird for Real-Time Analytics

Tinybird sits between your data and your application, turning raw event streams or uploaded files into real-time analytics APIs with sub-second response times. A basic setup takes under 30 minutes and does not require database administration experience.

What Tinybird Does

Tinybird runs on managed ClickHouse, a columnar OLAP database built for fast analytical queries on large datasets. The difference between running ClickHouse yourself and using Tinybird is that Tinybird handles the infrastructure, manages schema definitions through simple configuration files, and automatically wraps your SQL queries in REST API endpoints. You write SQL; Tinybird handles the plumbing.

The platform fits teams that need one of three things: user-facing analytics dashboards with real-time data, internal monitoring APIs that refresh within seconds, or lightweight event pipelines that need to be queryable immediately after ingestion. It is not designed for transactional workloads or complex joins across dozens of relational tables.

According to Tinybird's documentation, properly indexed endpoints return query results in under 100 milliseconds at the 99th percentile, making it competitive with purpose-built OLAP infrastructure without the operational overhead.

Core Concepts

Before starting, four terms appear throughout Tinybird's interface and documentation.

Data Sources are where your data lives in Tinybird. Think of them as tables. You define a schema for a data source, then push data into it via an HTTP Events API, file uploads, a Kafka connector, or scheduled imports from S3. All SQL queries in Tinybird run against data sources.

Pipes are the SQL logic layer in Tinybird. A pipe is a sequence of one or more SQL nodes chained together. You can filter, aggregate, join, or transform data across pipes. Pipes run on demand when called, not on a fixed schedule.

Endpoints are pipes that have been published as REST APIs. Publishing a pipe generates a public or token-gated URL you can call from any application, BI tool, or script. A small templating syntax lets you add query parameters to make endpoints dynamic.

Tokens are API keys scoped to a workspace. You generate read or write tokens and pass them as Authorization headers in API requests.

Step 1: Create a Workspace

Go to tinybird.co and sign up for a free account. The free tier includes 1 million rows per month of ingestion, which is enough to follow this guide end to end.

After logging in, click "New Workspace" and give it a name. Choose a cloud region close to your users; geographic proximity affects query latency. Workspaces are isolated environments similar to separate databases. You can create multiple workspaces to separate development and production environments.

Step 2: Ingest Your First Data

The simplest ingestion path is uploading a CSV file. From your workspace, click "Add Data Source" and select "File Upload." Drag in any CSV with headers. Tinybird infers the schema automatically and creates a data source with appropriate column types.

For production use cases, the Events API is more common. It accepts JSON or newline-delimited JSON (NDJSON) via HTTP POST:

curl -X POST "https://api.tinybird.co/v0/events?name=page_events" \
  -H "Authorization: Bearer <your_token>" \
  -d '{"user_id":"u123","event":"page_view","timestamp":"2026-04-27T12:00:00Z","path":"/dashboard"}'

Tinybird appends the event to the named data source. If the data source does not exist, Tinybird creates it with an inferred schema on the first write. For high-volume scenarios, batch multiple events in NDJSON format in a single request to reduce API overhead.

Teams using Kafka can connect a topic directly to a Tinybird data source through the native Kafka connector, available on paid plans. Tinybird consumes the topic continuously and appends records in real time.

Step 3: Write a Pipe

Once data is in a source, open the SQL editor and create a new Pipe. Pipes use standard SQL with ClickHouse-specific functions available for date arithmetic, approximate distinct counts, and array operations.

A simple daily aggregation pipe looks like this:

SELECT
  toDate(timestamp) AS date,
  count()           AS total_events,
  uniq(user_id)     AS unique_users
FROM page_events
WHERE timestamp >= now() - INTERVAL 7 DAY
GROUP BY date
ORDER BY date DESC

You can chain multiple SQL nodes inside a single pipe; each node can reference the output of the previous one using the node name as a table alias. This makes it easy to break a complex query into readable, testable stages.

For performance-critical queries over large datasets, Tinybird supports Materialized Pipes. These pre-aggregate data at ingestion time rather than at query time, dramatically reducing latency on multi-million-row tables. To create one, write a pipe that outputs to a new data source. Tinybird runs the transformation incrementally as new data arrives, keeping the result always up to date.

Step 4: Publish as an API Endpoint

When your pipe returns the right data, click "Create API Endpoint" in the pipe editor. Tinybird generates a URL you can call immediately:

curl "https://api.tinybird.co/v0/pipes/daily_summary.json" \
  -H "Authorization: Bearer <your_read_token>"

To make the endpoint accept dynamic filters, add query parameters using Tinybird's templating syntax inside the SQL:

SELECT date, total_events, unique_users
FROM daily_summary
WHERE date >= {{Date(start_date, '2026-01-01')}}
  AND date <= {{Date(end_date, '2026-04-27')}}

Callers pass ?start_date=2026-04-01&end_date=2026-04-27 in the URL. Tinybird validates the parameter types and acceptable value ranges before executing the query, preventing SQL injection without additional application-side handling.

Step 5: Integrate with Your Application

Tinybird endpoints return standard JSON. Any frontend framework, BI tool, or data pipeline that can make an HTTP GET request can consume them. Grafana and Metabase can connect to Tinybird endpoints directly through their JSON data source plugin.

Response times for aggregation queries over a few million rows typically land between 50 and 150 milliseconds, fast enough for real-time dashboard refreshes without client-side caching.

For teams working in code, Tinybird provides a CLI tool (pip install tinybird-cli) that enables a GitOps workflow. Data source definitions and pipe SQL live in version-controlled .datasource and .pipe files, making schema changes reviewable and deployable through CI/CD pipelines.

If your team works primarily with uploaded files and needs to skip the API and infrastructure layer entirely, VSLZ handles analysis end to end from a file upload, returning charts and statistical summaries in plain English without writing SQL or configuring endpoints.

What to Watch For

A few limitations are worth knowing before building on Tinybird for production. The free tier caps ingestion at 1 million rows per month and excludes Kafka connectors and Materialized Views above a small data volume. Paid plans start around $500 per month for small teams.

ClickHouse does not support frequent row-level updates or deletes efficiently, and Tinybird inherits this constraint. If your data requires high-frequency mutations, verify that an append-only architecture fits your use case before committing to the platform.

Tinybird's native connector library is also narrower than established ETL platforms. Direct ingestion paths exist for Kafka, S3, and the HTTP Events API, but pulling data from SaaS tools like Salesforce or HubSpot requires an external ETL step before data reaches Tinybird.

Finally, Tinybird is optimized for analytics queries with a pre-defined schema. Ad-hoc exploratory analysis across changing schemas is slower to iterate on than in notebook-based tools.

Summary

Tinybird compresses the time to a working real-time analytics API from weeks to hours. Create a workspace, push data through the Events API or file upload, write aggregation logic in a Pipe, and publish as a REST endpoint. For teams that need fast, queryable analytics on live data without managing ClickHouse infrastructure, it is a practical starting point that handles scaling without additional operational complexity.