I wanted a better way, and so I’ve started working on a new project: tycostream. It turns Materialize views into real-time GraphQL APIs, so you can quickly build live, type-safe apps, agents, and dashboards without needing custom infrastructure or glue code.

It would need a lot more work for production use, but the core functionality is ready for feedback. Let’s take a look.

How It Works

The design is inspired by view servers such as Finos Vuu or the Genesis Data Server, which are common components of financial markets applications. These components excel at streaming ticking prices, positions, and orders to thousands of connected UIs with fine-grained permissions and filtering. I wanted to build something similar but using open standards: GraphQL for the API and Postgres wire protocol for the database connection.

With that in mind, tycostream works a bit like Hasura, but for streaming databases (currently Materialize). There are two key features:

• Subscriptions stream typed, real-time updates to clients, with optional where clauses for filtering.

• Triggers register webhooks that fire when data meets specific conditions, for alerting, workflow automation, or integrating with external systems.

You define the views to expose, and tycostream generates GraphQL subscriptions and mutations from their schema. For example, given a trades table like this:

CREATE TABLE trades (
  id INT,
  instrument_id INT,
  side TEXT,
  quantity INT,
  price NUMERIC,
  executed_at TIMESTAMP
);

tycostream generates a GraphQL API like this:

type Subscription {
  trades(where: tradesExpression): tradesUpdate!
}

type Mutation {
  create_trades_trigger(input: tradesTriggerInput!): Trigger!
  delete_trades_trigger(name: String!): Trigger!
}

type Query {
  trades_triggers: [Trigger!]!
  trades_trigger(name: String!): Trigger
}

type tradesUpdate {
  operation: RowOperation!
  data: trades
  fields: [String!]!
}

type trades {
  id: Int!
  instrument_id: Int
  side: side
  quantity: Int
  price: Float
  executed_at: String
}

type Trigger {
  name: String!
  webhook: String!
  fire: String!
  clear: String
}

enum RowOperation {
  INSERT
  UPDATE
  DELETE
}

enum side {
  buy
  sell
}

input tradesTriggerInput {
  name: String!
  webhook: String!
  fire: tradesExpression!
  clear: tradesExpression
}

input tradesExpression {
  id: IntComparison
  instrument_id: IntComparison
  side: sideComparison
  quantity: IntComparison
  price: FloatComparison
  executed_at: StringComparison
  _and: [tradesExpression!]
  _or: [tradesExpression!]
  _not: tradesExpression
}

input IntComparison {
  _eq: Int
  _neq: Int
  _gt: Int
  _lt: Int
  _gte: Int
  _lte: Int
  _in: [Int!]
  _nin: [Int!]
  _is_null: Boolean
}

input FloatComparison {
  _eq: Float
  _neq: Float
  _gt: Float
  _lt: Float
  _gte: Float
  _lte: Float
  _in: [Float!]
  _nin: [Float!]
  _is_null: Boolean
}

input StringComparison {
  _eq: String
  _neq: String
  _in: [String!]
  _nin: [String!]
  _is_null: Boolean
}

input sideComparison {
  _eq: side
  _neq: side
  _in: [side!]
  _nin: [side!]
  _is_null: Boolean
}

Under The Hood

tycostream is built with TypeScript using NestJS, RxJS, and Apollo Server. NestJS provides database connectivity and WebSocket support out of the box, along with modules for authentication, observability, and deployment for later down the line. RxJS handles the reactive stream processing, and Apollo Server provides the GraphQL layer with an interactive explorer for testing queries.

The project is architected into three core modules:

• A database module that manages Materialize connections and parses the data stream

• A view module that maintains an in-memory cache and handles client-side filtering

• An api module that generates the GraphQL schema from view definitions

tycostream lazily instantiates a cache and Materialize connection for each view exposed over the API. When the first request for a given view comes in, tycostream opens a new connection, caches incoming updates, and streams them to the client. Additional requests for the same view are first served a snapshot from the cache, then connected to a live stream of inserts, updates, and deletes. When requests have where clauses, tycostream compiles them into JavaScript functions to filter each row as it streams through.

Integration Testing

The project includes integration test infrastructure built on Testcontainers, Apollo Client, and Express. You define a test scenario as:

1. A sequence of database operations for tycostream to process

2. The number of clients to spin up and how they should interact with tycostream’s subscriptions and triggers

3. The expected state each client should see at the end

For example, a test with one client subscribed to positions and a loss alert trigger looks like this:

const testEnv = await TestEnvironment.create({
  appPort: 4001,
  schemaPath: 'test/schema.yaml',
});

const client = testEnv.createClient('positions-client');

await client.subscribe('positions', {
  query: `subscription { positions { operation data { id quantity } } }`,
  expectedState: new Map([[1, { id: 1, quantity: 100 }]]),
});

await client.trigger('loss-alert', {
  query: `mutation($url: String!) { create_trigger(name: "loss", view: "positions", ...) }`,
  expectedEvents: [{ event_type: 'FIRE', data: { id: 1 } }],
});

await testEnv.waitForCompletion();

The test passes when all clients converge to their expected state, and fails if it times out or the liveness check detects that data has stopped flowing.

Why This Matters

In Part 1, I asked whether we’d see business logic pulled out of applications and centralized in streaming databases. Turns out there’s already a name for this pattern: the streaming data mesh. The idea is that individual teams can publish well-defined, versioned “data products” that anyone can use, thereby creating internal APIs for live data.

I believe streaming databases like Materialize are the unlock for this pattern. They let developers join and transform live data using standard SQL, making it much easier to build scalable, real-time applications. And as demand for streaming databases grows, I expect we’ll need an ecosystem of tools around them — API layers for access, entitlements for security, and ways to trigger logic on certain conditions. This is where tycostream fits in.

Imagine vibe coding a positions dashboard in Retool. Under the hood, it’s a simple case of connecting workflows and UI elements to live data products via GraphQL, making streaming applications as easy to build as CRUD.

Try It Out

Want to see tycostream in action? There’s a positions dashboard demo in the repo you can spin up locally with a single command. It uses a lightweight simulator to generate trades and market data, a Materialize emulator instance to calculate real-time positions as materialized views, and tycostream subscriptions to stream everything to the frontend. There’s also an alerts panel showing when realized losses exceed a threshold, implemented via tycostream triggers.

If you’re building real-time applications with SQL and GraphQL, I’d love to hear from you. What problems are you solving? What would make this useful for your use case? Drop me a line here or at chris@tycoworks.com.

This post continues from Part One, where I built a real-time core for a positions UI using Materialize. Trades, instruments, and market data were flowing into a live view of quantity, market value, and theoretical P&L, with millisecond-level latency. The next step was getting that data into a UI in real time, with minimal code and infrastructure.

Exploring the Options

As in Part One, the goal was to build the UI with as little custom code as possible. I began by looking into whether anyone had done this before, and what tools they’d used to make it work.

I found surprisingly little. There was a Materialize plugin for Grafana, which wasn’t a good fit given Grafana’s focus on monitoring. Some people were piping views to database tables to feed Streamlit or Metabase dashboards, which wasn't truly real-time. But most commonly, people were building their own lightweight processes to stream data over WebSockets, like this blog post using Deno and Chart.js.

So I started looking more broadly. Were there other approaches that could work for my use case?

Low-Code Platforms and Admin Panel Builders

I started with low-code platforms like Retool. Retool excels at creating UIs and workflows on top of APIs and data sources, so in theory it felt like a good fit. But it doesn't support real-time subscriptions — only polling or manual refresh.

I also looked briefly at Refine. It’s a more developer-oriented React framework for building admin panels with strong Postgres support. While it does support real-time data, I would have needed to build a custom Materialize integration, so it wouldn’t have saved any coding.

There are many other similar low-code platforms and admin panel builders, but I couldn't find any with true, off-the-shelf real-time support.

REST and GraphQL

I also explored exposing Materialize over REST or GraphQL, both common APIs for front-end data access. REST was a non-starter — it isn’t built for real-time — but GraphQL supports subscriptions and is well supported by most frontend frameworks.

That led me to Hasura, a data access layer for Postgres. It exposes your database as a GraphQL API with minimal setup, featuring built-in filtering, joining, and access control. Since Materialize is Postgres-compatible it seemed like a perfect fit, but Hasura polls periodically rather than streaming changes in real time, which wouldn't give me the tick-by-tick updates I needed.

I also looked at Apollo, a more flexible way to build GraphQL APIs over any data source. It looked promising, but I’d still have needed to build an integration for Materialize. Since the main goal was to get streaming data into a UI with minimal effort, I didn’t want to add another platform and a bunch of glue code.

View Servers

Finally I explored view servers, which are common in many financial markets applications. These components typically stream data to frontends over WebSockets, with built-in rate limiting and access control. Genesis and Deephaven, for example, both feature UI servers as part of their larger platforms (e.g. Genesis’ Data Server), but these aren’t available as standalone components.

FinOS Vuu was promising as an open source project designed for fast-moving data and many connected users. While it seemed straightforward to integrate and get running, I would’ve also needed to adopt its built-in grid, whereas I was more looking to compose a solution from standalone components.

Implementation

Overview

Having found no plug-and-play options, it was time to build. I decided to follow the approach outlined in the Deno + Chart.js example: a backend process subscribing to Materialize, pushing updates over WebSockets to a grid. Another option was to use a Materialize sink, but that would’ve needed a Kafka cluster and made it harder to send data to the frontend.

As I hadn’t coded in over a decade, I was going to need some help. I wanted to treat AI as if it were a developer colleague — I’d provide the spec, and it would generate and update the code as the spec evolved. This 'AI-native development' approach — championed by startups like Tessl — is gaining ground as a more deterministic alternative to vibe coding. I worked with Claude to write detailed specifications, and used Cursor to implement the code.

Backend

I chose Rust for the backend relay. It's fast, memory-safe, and widely used for low-level infrastructure — including Materialize itself. Deno was another solid option, but I’d already seen that path explored and wanted to try something different.

Next, I used Claude to create a detailed specification for Cursor to work from, covering the context, architecture, and requirements. Cursor implemented the code using tokio and, after a few issues with authentication and connection handling, got everything working. I’m no stranger to vibe coding, but watching Cursor write code and fix bugs on the fly still felt like magic.

Once up and running locally, I connected to the relay with wscat and saw real-time data flowing into the terminal. The data refreshed as the market moved and as new trades were inserted, meaning everything was in place for the UI.

You can find the backend code on GitHub: tycoworks/rust-relay.

Frontend

Since the UI was simple — just a grid connected to a WebSocket — I went with plain HTML and JavaScript. I used Vite to build and test the app locally, which automatically detected file changes and refreshed the browser as I worked.

For the grid, I needed something that could handle large, streaming datasets. Two options stood out: AG Grid, a high-performance data grid which we used at Genesis; and Perspective, a grid and charting component compiled to WebAssembly. AG Grid would’ve been a perfect fit, but I went with Perspective to try something new, and because I was curious about its built-in analytics features.

As with the backend, I created a specification file describing the UI layout and requirements, but implementation was a little trickier. Cursor struggled with CDN imports, WebAssembly loading, and even tried to swap out Perspective for another grid component a couple of times. After nearly 30 iterations and some manual debugging in the browser, we finally got Perspective up and running — but the grid was empty.

After a bit of debugging, I realized the problem was with the relay. It was correctly forwarding updates from Materialize, but wasn’t sending the initial state of the data when the frontend connected. This turned out to be a gap in the spec, so I asked Cursor to add it and regenerate the code. After a couple of iterations on the snapshot logic, I had a live positions view ticking with the market.

Frontend code is available here: tycoworks/ui-grid.

Conclusion

So, can a streaming database power a real-time financial markets UI? I believe so. I built a real-time positions UI with Materialize at its core and, although updates ticked a little more slowly than I expected, I suspect that was due to things like using trades instead of BBO, the Estuary bridge, or running with stock Materialize config.

While getting data into Materialize was a little fiddly, getting data out was the bigger surprise. Most people seemed to be creating custom processes to stream data into the browser, with no clear off-the-shelf option. It feels like there should be a better way — especially if you also need entitlements, filtering, and scalability.

Is there a product here? A "Hasura for streaming databases", providing streaming data over GraphQL and WebSockets? Is there demand for streaming data into UIs, or is the bigger opportunity in powering AI agents? That's what I'll look at next.

These ideas have been around for a while in capital markets, and are now becoming common in real-time data processing. Products like Materialize and RisingWave, for example, let developers build live views over streaming data with Postgres-compatible SQL, kept up to date with millisecond-level latency. These ‘streaming databases’ blur the line between databases and stream processors, and are gaining traction in areas like capital markets, manufacturing, and e-commerce.

This got me thinking recently about the trading desk of the future — what role might these technologies play, especially in the parts that don’t need ultra-low latency? Will we see business logic pulled out of applications and centralized in tools like these? Could they power a real-time financial markets UI?

To explore this, I set out to build a positions view powered by a streaming database, to see what’s possible and where the friction lies.

Specification and Setup

For the UI, I wanted a simple grid showing live positions, market value, and theoretical P&L per instrument. It’s a small scope, but it covers many of the things you'd expect in a financial markets application, such as live and static data, real-time calculations, and ticking frontend updates. On the backend, I wanted to approximate a production setup — secure, scalable, and fast — but without glue code or heavy infrastructure.

The high-level architecture was therefore simple: trades and instruments flowing from a Postgres instance; market prices piped in from a cloud WebSocket feed; a materialized view for the positions logic; and results streamed out to a grid in the browser.

Choosing the Streaming Database

One of the first big decisions was picking a streaming database to power the backend. I went with Materialize because it ticked all the boxes: broad SQL support, streaming over a standard Postgres connection, and strong consistency guarantees. But this space is evolving fast, and there were other solid contenders.

Materialize

Materialize positions itself as a 'live data layer' for apps and agents. It supports Postgres-compatible SQL, is built in Rust, and uses Timely and Differential Dataflow under the hood, enabling low latency and strong consistency across all views. You can query results on-demand or push updates out over Kafka or a Postgres connection, and it's easy to get started with their hosted offering and local development emulator.

RisingWave

RisingWave describes itself as a 'real-time event streaming platform' and appears similar to Materialize at first glance - SQL-first, Rust-based, and designed to make stream processing feel like working with Postgres. It's fully open source, built around open storage formats like Apache Iceberg, and has a high-performance 'Ultra' edition designed for use cases in financial markets and online betting. Unlike Materialize however, it doesn't guarantee strict consistency, meaning views can be temporarily out of sync.

ksqlDB

ksqlDB is a streaming SQL engine for working with real-time data in Kafka. It supports SQL-like queries over Kafka topics, is open source, and has built-in support for other Confluent products like Schema Registry. However, it requires a running Kafka cluster and uses a proprietary SQL dialect — both of which I was looking to avoid.

Deephaven

Deephaven is a Python-based real-time engine originally built at a hedge fund, tailored for financial data workflows. It comes with its own UI server and scripting environment, so you can build full-stack UIs with just a few lines of Python. It’s powerful and polished, and would be a great choice if I were building this scope “for real.” But it’s a bit of an outlier — most streaming databases don’t bundle a UI server — so it didn’t feel like a good fit for this experiment.

Wiring It All Up

With the streaming database chosen, I spun up a Materialize Cloud instance — a managed service that’s secure, scalable, and production-ready out of the box. Then, I needed data: trades and instruments from Postgres, and market prices from a live feed.

Trades and Instruments

For trades and instruments, I used Neon — a managed Postgres service that’s quick to set up and has a free tier. I used Claude to generate the tables and some fake data, and created a ‘publication’ so Materialize could subscribe to updates in real-time. I registered Neon as a source in Materialize, and the data was live.

Market Data

To keep things realistic, I wanted to use real market data delivered over WebSockets. Claude suggested a few great options — like Databento (great for latency-sensitive use cases) and Polygon (broad instrument coverage) — but I decided to go with Alpaca for its free tier and clean API.

That’s when I realized I’d missed something: Materialize doesn’t support WebSockets as a source. Oops. I could’ve switched streaming database (to e.g. Deephaven) or written a custom process to transform the data, but I wanted to avoid changing stack or adding glue code.

That’s when I found Estuary Flow: a real-time ETL tool with native support for both Alpaca and Materialize. Within a few minutes, I’d configured Estuary’s Alpaca connector for the IEX trades stream, mapped it to a Kafka topic, and registered it as a source in Materialize. Live prices were streaming in.

Positions

The final step was to pull trades, instruments, and market prices together into a live positions view. I had Claude generate two materialized views: one to surface the latest trade price per instrument, and another to join everything together, aggregate trades into positions, and calculate market value and P&L.

I ran SELECT * FROM live_pnl; and, after a short ‘hydration’ period, watched my positions update in real time as trades and prices streamed in.

Wrapping Up

So far so good. I had a real-time view of positions, fed from live market data and a Postgres database, without any glue code. And since it ran on production-grade managed services, it didn’t feel far off a real setup, even if I hadn’t optimized for latency, scale, or security.

The next question: can this view drive the UI, and how easy is that in practice? That’s the focus of Part Two.