---
title: "Slate scopes product ideas around users, not infrastructure"
excerpt: "How Slate replaced a Redis bottleneck with Tinybird to unlock real-time prices and P&L for thousands of investors, and stopped saying no to growth."
authors: "Tinybird"
categories: "Customer Stories"
createdOn: "2026-08-05 13:00:00"
publishedOn: "2026-08-05 13:00:00"
updatedOn: "2026-08-05 13:00:00"
status: "published"
---

{% image src="logo.svg" alt="Slate logo" className="text-primary w-[120px] h-auto" /%}

## About the company

[Slate](https://www.slatewt.com/) is a B2B investment platform for fintechs and financial institutions worldwide. The company ships both a white-label app and a brokerage API, giving partners everything they need to offer a modern investing experience: live prices, real-time portfolio views, and a growing universe of tradable assets.

{% cs_counters data=[{value: "100s of millions", label: "events ingested per day"}, {value: "<200ms", label: "API p99 latency at peak"}, {value: "~4 weeks", label: "to first production workload"}] /%}

{% cs_quote quote="Slate's data layer used to define what was possible. Now, it gives the team the freedom to build around what users want." author="Slate Engineering" /%}

## Problem

Slate's partners build investing apps for consumers who expect live prices and real-time P&L. Delivering that experience through a B2B platform meant Slate's data layer had to absorb hundreds of millions of market-data ticks and portfolio updates daily, then serve pre-computed values with sub-second latency to every connected user.

The original architecture ran on AWS with Kotlin/Spring Boot services. Market data arrived through direct feed handlers with no streaming layer. Background workers pre-computed prices and P&L and stashed the latest values in Redis; the apps polled REST endpoints that read straight from cache. There was no historical store: once a tick was overwritten, it was gone.

The design worked until it didn't. During volatile market opens, every user holding the same instrument hammered the same hot keys in Redis. Contention spiked, REST tail latency stretched into multiple seconds, and Slate took outages during market opens more than once. Every new instrument made it worse: more hot keys, more workers, more memory pressure. The data layer wasn't just struggling; it was capping the product.

## Why Tinybird

Slate needed three things at once: absorb hundreds of millions of events per day, serve app-facing queries with low latency during market peaks, and avoid adding a dedicated data platform team.

Tinybird gave them managed ClickHouse® for the analytical workload, plus an API layer for serving product traffic directly from SQL. Slate got the column-store engine they wanted without owning the cluster, ingestion path, and serving layer themselves. They had a working endpoint in days and cut the first production workload over in about four weeks.

For a financial workload, the bar was not just speed. Slate needed predictable behavior during market volatility, a managed service they could trust in production, and a path that did not add more operational surface area to the engineering team.

## Results

- **Latency.** REST tail latencies that used to stretch into multiple seconds at peak now stay under 200ms p99, including during volatile market opens.
- **Throughput.** Hundreds of millions of market-data and portfolio events flow through Tinybird every day, including the same traffic patterns that used to overload Redis.
- **Cost.** The Tinybird path costs less than the Redis cluster it replaced, while handling more volume, more instruments, and more clients.
- **Engineering time.** Volatility-related pages stopped after the cutover. The team no longer loses roadmap time to Redis scaling, evictions, restarts, and cache tuning.

![Tinybird x Slate](tinybirdxslate.png)

## A data layer that punished growth

The operational burden was outsized. Every volatile market open meant pages. The team could set their watches by them. Manual Redis ops became routine: scaling, evictions, restarts, hand-tuning the same cluster over and over. Roadmap work kept getting deprioritized to firefight the data layer.

The bigger cost wasn't the features Slate delayed. It was the ones they never pitched. The team learned to scope ideas around what Redis could survive, not what users needed.

The breaking point came when the business wanted to expand the asset universe: more instruments, more markets, the kind of catalog growth a brokerage competes on. The engineering team had to say no. Every instrument they'd already added had made Redis worse, and they knew the next batch would tip it over. Growth wasn't a goal anymore; it was a threat to uptime.

{% cs_quote quote="The better the product idea, the louder the data layer pushed back. Growth wasn't a goal anymore; it was a threat to uptime." author="Slate Engineering" /%}

## Ruling out the obvious paths

Slate evaluated several alternatives before settling on Tinybird.

**Self-hosted ClickHouse** was the most attractive option technically, but it meant owning a column store, the ingestion pipeline, and the query layer. That would have required dedicating engineers to running data infrastructure instead of building the product.

**A streaming stack (Kafka, Flink, Materialize, Druid)** solved the freshness problem but multiplied the moving parts. They'd be trading one operational headache for four.

**Staying on Redis** with Redis Streams and bigger custom workers was the same trap with a different label: rebuilding ClickHouse on Redis primitives and still owning every layer.

None of them fit an engineering team that needed to ship product, not run a data platform.

## Managed ClickHouse, without the ops

Three capabilities sealed the decision:

**Managed ClickHouse.** Slate got the column-store engine that solved their query problem without taking on the operational burden they'd just ruled out. No cluster management, no capacity planning, no 2 AM pages about compaction.

**Built-in API layer.** Every query becomes a hosted, low-latency endpoint. Slate didn't need to build and maintain a separate API service in front of the data. The serving layer came with the platform.

**Speed to production.** The team could prototype the endpoint in days, validate it against real traffic, and move the first production workload over in about four weeks. For Slate, that ratio of capability to operational footprint was the entire argument.

From decision to first production endpoint was about four weeks. Slate started with the real-time prices endpoint: the highest-traffic, highest-pain surface in the old stack, and the one users feel first. They ran it in parallel with the Redis path, validated behavior under real load, then cut over. The cutover was uneventful.

![Slate's market data architecture before and after Tinybird](slate-architecture.png)

{% cs_quote quote="We expected to add a service in front of Tinybird; instead, we deleted Spring Boot code. The backend got smaller, not larger." author="Slate Engineering" /%}

The new path is built around read-optimized data rather than cache mutation. Slate ingests market and portfolio events into Tinybird, models the high-traffic reads around denormalized tables and materialized values, then exposes the app-facing queries as Tinybird APIs. The application no longer asks Redis for the latest cached answer. It calls an endpoint backed by ClickHouse and shaped around the query pattern users hit most.

## Negative code and a new mental model

The pleasant surprise was negative code. Slate expected to add infrastructure; instead, they removed it. Endpoints they'd handwritten for caching, recomputing, and serving prices went away entirely, replaced by Tinybird APIs the app now calls directly.

![Slate real-time prices and portfolio analytics powered by Tinybird](slate-product-screenshot.png)

The friction was the mental shift to ClickHouse. Slate's engineers were used to thinking relationally: joins, normalization, foreign keys. ClickHouse rewards the opposite: denormalize aggressively, materialize what you'll read, design schemas around the query, not the entity. They had to retrain before they were designing tables the way the engine wanted.

The Tinybird team carried Slate through that learning curve. They've shipped ClickHouse into enough production workloads to know which patterns hold and which fall apart, and Slate leaned on that experience instead of grinding through it alone.

## What Slate can do now

Beyond the raw performance gains, three things are possible now that weren't before:

**The asset universe can grow.** New instruments, new asset classes, new markets. Adding them is a product decision now, not a data-layer fight. Crypto, derivatives, FX, and fixed income are all on the roadmap.

**B2B partners onboard faster.** Each new client used to mean more hot keys and more pressure on the same Redis. Now they slot in, and sales can say yes without checking with infrastructure.

**End-user features ship.** Charts, alerts, performance views. The kind of features users expect from a modern investing app, and the kind Slate used to scope away because the data layer couldn't carry them.

Looking ahead, Slate plans to push Tinybird outward: turning the same data pipeline into per-partner analytics so their B2B clients can offer their own users dashboards and data products on top of the platform. The same engine that powers Slate's app becomes a surface partners can build on.

For Slate, the change is not just faster queries. It is a different product posture. More instruments, more partners, and more real-time features no longer start with the same infrastructure question: can Redis survive this?

{% cs_cta /%}