There's a problem that's bugged the database industry since the 1980s: you run an expensive query over millions of rows, cache the result, and then a single new row arrives. Logically that's one small update, but most engines throw the cached answer away and recompute everything from scratch. Some will handle changes incrementally, but only for "simple" queries - and the rules for what counts as simple are arbitrary and brittle. So can you incrementally maintain *any* SQL query, no matter how complex? For decades the answer was no. Then an award-winning paper called DBSP proved that the answer is yes - all queries are simple enough.

Joining me to explain how that works is Lalith Suresh, CEO of Feldera, the company built on top of DBSP. We start with the problem itself, then trace how a group of VMware researchers arrived at it from the unlikely direction of Kubernetes and network control planes. Lalith walks through Z-sets, the weighted data structure that turns database changes into something you can add and subtract, and the four DBSP operators - including one borrowed straight from digital signal processing - that let you compile any SQL program into an incremental version deterministically. Along the way we get into which operations need state and which don't, how the delta join falls out for free, building a standalone query engine with its own storage layer and Calcite front-end, backfills as the real Achilles heel, and how this all differs from stream processors like Kafka Streams and Flink.

If you've ever fought with materialized views that won't refresh, watched a nightly batch job recompute three years of data to capture last night's changes, or you're just curious how one elegant bit of maths unifies batch and stream processing, Lalith has some genuinely satisfying answers. There's an MIT-licensed open source edition and a sandbox at try.feldera.com if you want to play along.

---

Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices

Support Developer Voices on YouTube: https://www.youtube.com/@DeveloperVoices/join

Feldera: https://www.feldera.com/

Feldera Sandbox (try it online): https://try.feldera.com/

Feldera on GitHub (open source): https://github.com/feldera/feldera

DBSP Rust crate: https://crates.io/crates/dbsp

DBSP Paper - "Automatic Incremental View Maintenance for Rich Query Languages" (VLDB 2023 Best Paper): https://arxiv.org/abs/2203.16684

Mihai Budiu - "Streaming Queries Without Compromise" (Current 2024): https://www.youtube.com/watch?v=cn1Yaxwl6x8

Mihai Budiu - DBSP talk at CMU Database Group: https://db.cs.cmu.edu/events/dbsp-incremental-computation-on-streams-and-its-applications-to-databases/

Differential Dataflow: https://github.com/TimelyDataflow/differential-dataflow

Apache Calcite (Feldera's SQL front-end): https://calcite.apache.org/

Kafka Streams: https://kafka.apache.org/documentation/streams/

Apache Flink: https://flink.apache.org/

ksqlDB: https://ksqldb.io/

Apache Spark: https://spark.apache.org/

Snowflake: https://www.snowflake.com/

Databricks: https://www.databricks.com/

Kris on Bluesky: https://bsky.app/profile/krisajenkins.bsky.social

Kris on Mastodon: http://mastodon.social/@krisajenkins

Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/

AI is changing the way we all build software — that much seems clear. But the landscape is moving so fast that even the people paid to keep up are struggling. MCP or skills? Fine-tune or just prompt? LangChain or let a thousand agents loose? With almost 70 competing technologies and a shelf life of maybe six months on any advice, how do you figure out what's actually worth your time?

Henry Garner is CTO of JUXT, a consultancy with about 150 senior engineers working at the coalface of AI-assisted development, including building AI platforms for tier-one banks. JUXT publishes a quarterly AI Radar — 68 technologies rated and reviewed — and Henry's been watching his own team go through the full adoption arc, from "spicy autocomplete" skepticism through to building Byzantine-fault-tolerant distributed systems over a weekend with Claude. Along the way we cover MCP vs skills, Conway's Law for LLMs, neurosymbolic AI and the unexpected return of Prolog, the "Ralph Wiggum loop" for getting agents to converge on correct implementations, and Allium — a new behavioral specification language Henry's co-authored that sits between human prose and TLA+, aiming to give LLMs just enough structure to pin down what a system should do without falling into waterfall thinking.

If you're trying to make sense of the AI tooling landscape, or you've hit that wall where your agents keep drifting away from what you actually wanted, Henry's thesis — velocity through clarity of intent — might well help out yours.

--

Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices

Support Developer Voices on YouTube: https://www.youtube.com/@DeveloperVoices/join

JUXT: https://www.juxt.pro/

JUXT AI Radar: https://www.juxt.pro/ai-radar/

Allium on GitHub: https://github.com/juxt/allium

Allium Documentation: https://juxt.github.io/allium/

Composition at a Distance (Henry's blog post): https://www.juxt.pro/blog/composition-at-a-distance/

A New Vocabulary for an Old Problem (Henry's blog post): https://www.juxt.pro/blog/new-vocabulary-for-an-old-problem/

Model Context Protocol (MCP): https://modelcontextprotocol.io/

LangChain: https://www.langchain.com/

LangGraph: https://www.langchain.com/langgraph

Gas Town (Steve Yegge): https://github.com/steveyegge/gastown

Kiro (spec-driven AI IDE): https://kiro.dev/

Phoenix (LLM observability): https://github.com/Arize-ai/phoenix

Temporal: https://temporal.io/

Taalas (LLM-on-a-chip): https://taalas.com/

Kris on Bluesky: https://bsky.app/profile/krisajenkins.bsky.social

Kris on Mastodon: http://mastodon.social/@krisajenkins

Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/

I have a theory that only bad projects get finished — good ones keep finding new things to do. Asciinema is a case in point. What started as a way to share terminal sessions with friends has, over 14 years, grown into a full suite of tools covering recording, hosting, playback, and live streaming — and been rebuilt multiple times along the way. So what does it actually take to record and replay a terminal session faithfully in a browser?

Joining us for this conversation is Marcin Kulik, Asciinema's creator. The project's architecture has passed through almost every interesting corner of software engineering: a Python recorder built around pseudo-terminals (PTY), a ClojureScript terminal emulator for the browser that hit performance limits with immutable data structures and garbage collection pressure, a move to Rust compiled to WebAssembly, a Go experiment that didn't last, and a new Rust CLI for concurrent live streaming backed by an Elixir/Phoenix server that calls Rust code via NIFs. The same Rust terminal emulator library now powers all three components — the browser player, the server, and the CLI.

If you've ever looked at those terminal animations embedded in a README and wondered what's underneath them, or if you're interested in how a passionate open-source developer navigates 14 years of language changes and rewrites, this conversation has plenty to offer.

---

Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices

Support Developer Voices on YouTube: https://www.youtube.com/@DeveloperVoices/join

Asciinema: https://asciinema.org

Asciinema Docs: https://docs.asciinema.org

Asciinema CLI (GitHub): https://github.com/asciinema/asciinema

Asciinema Player (GitHub): https://github.com/asciinema/asciinema-player

Asciinema Server (GitHub): https://github.com/asciinema/asciinema-server

AVT - Rust terminal emulator library: https://github.com/asciinema/avt

vt-clj - the original ClojureScript terminal emulator: https://github.com/asciinema/vt-clj

Paul Williams' ANSI/VT100 State Machine Parser: https://vt100.net/emu/dec_ansi_parser

Rust: https://www.rust-lang.org

WebAssembly: https://webassembly.org

SolidJS: https://www.solidjs.com

Elixir: https://elixir-lang.org

Phoenix Framework: https://www.phoenixframework.org

Rustler (Rust NIFs for Elixir/Erlang): https://github.com/rusterlium/rustler

Clojure: https://clojure.org

ClojureScript: https://clojurescript.org

cmatrix: https://github.com/abishekvashok/cmatrix

Marcin Kulik on GitHub: https://github.com/ku1ik

Marcin Kulik on Mastodon: https://hachyderm.io/@ku1ik

Marcin Kulik on asciinema.org: https://asciinema.org/~ku1ik

"They're Made Out of Meat" demo: https://asciinema.org/a/746358

Kris on Bluesky: https://bsky.app/profile/krisajenkins.bsky.social

Kris on Mastodon: http://mastodon.social/@krisajenkins

Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/

---

0:00 Intro

2:28 What Is Asciinema?

4:48 How Asciinema Started

9:51 The Problem of Parsing Terminal Output

14:07 Building a Cross-Platform Recorder

17:01 Rewriting the Parser in ClojureScript

22:19 The Hidden Complexity of Terminals

29:28 Rendering Terminals in the Browser

39:47 When ClojureScript Can't Keep Up

45:28 Moving to Rust and WebAssembly

52:01 The Go Experiment

57:43 Adding Live Terminal Streaming

1:07:12 Can You Scrub Back in a Live Stream?

1:14:40 Editing Recordings

1:25:27 Outro

Eighteen months ago, Tyler Cloutier appeared on the show with what sounded like an ambitious (some might say crazy) plan: build a new distributed database from scratch, then use it to power a massively multiplayer online game. That's two of the hardest problems in software, tackled simultaneously. But sometimes the best infrastructure comes from solving your own impossible problems.

The game, Bitcraft, has now launched on Steam. SpacetimeDB has hit version 1.0. And Tyler returns to share what actually happened when theory met production reality. We cover the launch day performance disasters (including a cascading failure caused by logging while holding a lock), why single-threaded execution running entirely from L1 cache can outperform sophisticated multi-threaded approaches by two orders of magnitude, and how the database's reducer model - borrowed from functional programming - enables zero-downtime code deployments. We also get into how SpacetimeDB is expanding beyond games with TypeScript support and React hooks that make building real-time multiplayer web apps surprisingly simple.

If you're building anything where multiple users need to see the same data update in real time - which, as Tyler points out, describes most successful applications from Figma to Facebook - SpacetimeDB's approach of treating every app as a multiplayer game might be worth understanding.

--

Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices

Support Developer Voices on YouTube: https://www.youtube.com/@DeveloperVoices/join

SpacetimeDB: https://spacetimedb.com/

SpacetimeDB on GitHub: https://github.com/clockworklabs/SpacetimeDB

Our previous episode with Tyler: https://youtu.be/roEsJcQYjd8

Clockwork Labs: https://clockworklabs.io/

Bitcraft Online: https://bitcraftonline.com/

Bitcraft on Steam: https://store.steampowered.com/app/3454650/BitCraft_Online

WebAssembly: https://webassembly.org/

Flecs (ECS for C/C++): https://www.flecs.dev/flecs/

TigerBeetle: https://tigerbeetle.com/

CockroachDB: https://www.cockroachlabs.com/

Google Cloud Spanner: https://cloud.google.com/spanner

Erlang: https://www.erlang.org/

Apache Kafka: https://kafka.apache.org/

Tyler Cloutier on X: https://x.com/TylerFCloutier

Tyler Cloutier on LinkedIn: https://www.linkedin.com/in/tylercloutier/

--

Kris on Bluesky: https://bsky.app/profile/krisajenkins.bsky.social

Kris on Mastodon: http://mastodon.social/@krisajenkins

Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/

0:00 Intro

2:01 The Architecture of SpacetimeDB

5:01 Client-Side Prediction in Multiplayer Games

11:00 Reducers and Event Streaming

15:00 Launching Bitcraft on Steam

19:00 Debugging Launch Performance Problems

26:56 Hot-Swapping Server Code Without Downtime

30:01 In-Memory Tables and Query Optimization

42:00 Is SpacetimeDB Only For Games?

51:00 Performance Benchmarking For Web Workloads

55:00 Why Single-Threaded Beats Multi-Threaded

1:00:01 Multi-Version Concurrency Control Trade-offs

1:05:01 Sharding Data Across Multiple Nodes

1:10:56 Inter-Module Communication and Actor Models

1:17:00 Replication and the Write-Ahead Log

1:24:00 Supported Client Languages

1:29:00 Getting Started With SpacetimeDB

1:39:02 Outro

SQLite is embedded everywhere - phones, browsers, IoT devices. It's reliable, battle-tested, and feature-rich. But what if you want concurrent writes? Or CDC for streaming changes? Or vector indexes for AI workloads? The SQLite codebase isn't accepting new contributors, and the test suite that makes it so reliable is proprietary. So how do you evolve an embedded database that's effectively frozen?

Glauber Costa spent a decade contributing to the Linux kernel at Red Hat, then helped build Scylla, a high-performance rewrite of Cassandra. Now he's applying those lessons to SQLite. After initially forking SQLite (which produced a working business but failed to attract contributors), his team is taking the bolder path: a complete rewrite in Rust called Turso. The project already has features SQLite lacks - vector search, CDC, browser-native async operation - and is using deterministic simulation testing (inspired by TigerBeetle) to match SQLite's legendary reliability without access to its test suite.

The conversation covers why rewrites attract contributors where forks don't, how the Linux kernel maintains quality with thousands of contributors, why Pekka's "pet project" jumped from 32 to 64 contributors in a month, and what it takes to build concurrent writes into an embedded database from scratch.

--

Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices

Support Developer Voices on YouTube: https://www.youtube.com/@DeveloperVoices/join

Turso: https://turso.tech/

Turso GitHub: https://github.com/tursodatabase/turso

libSQL (SQLite fork): https://github.com/tursodatabase/libsql

SQLite: https://www.sqlite.org/

Rust: https://rust-lang.org/

ScyllaDB (Cassandra rewrite): https://www.scylladb.com/

Apache Cassandra: https://cassandra.apache.org/

DuckDB (analytical embedded database): https://duckdb.org/

MotherDuck (DuckDB cloud): https://motherduck.com/

dqlite (Canonical distributed SQLite): https://canonical.com/dqlite

TigerBeetle (deterministic simulation testing): https://tigerbeetle.com/

Redpanda (Kafka alternative): https://www.redpanda.com/

Linux Kernel: https://kernel.org/

Datadog: https://www.datadoghq.com/

Glauber Costa on X: https://x.com/glcst

Glauber Costa on GitHub: https://github.com/glommer

Kris on Bluesky: https://bsky.app/profile/krisajenkins.bsky.social

Kris on Mastodon: http://mastodon.social/@krisajenkins

Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/

--

0:00 Intro

3:16 Ten Years Contributing to the Linux Kernel

15:17 From Linux to Startups: OSv and Scylla

26:23 Lessons from Scylla: The Power of Ecosystem Compatibility

33:00 Why SQLite Needs More

37:41 Open Source But Not Open Contribution

48:04 Why a Rewrite Attracted Contributors When a Fork Didn't

57:22 How Deterministic Simulation Testing Works

1:06:17 70% of SQLite in Six Months

1:12:12 Features Beyond SQLite: Vector Search, CDC, and Browser Support

1:19:15 The Challenge of Adding Concurrent Writes

1:25:05 Building a Self-Sustaining Open Source Community

1:30:09 Where Does Turso Fit Against DuckDB?

1:41:00 Could Turso Compete with Postgres?

1:46:21 How Do You Avoid a Toxic Community Culture?

1:50:32 Outro

How do you build systems with AI? Not code-generating assistants, but production systems that use LLMs as part of their processing pipeline. When should you chain multiple agent calls together versus just making one LLM request? And how do you debug, test, and deploy these things? The industry is clearly in exploration mode—we're seeing good ideas implemented badly and expensive mistakes made at scale. But Google needs to get this right more than most companies, because AI is both their biggest opportunity and an existential threat to their search-based business model.

Christina Lin from Google joins us to discuss Agent Development Kit (ADK), Google's open-source Python framework for building agentic pipelines. We dig into the fundamental question of when agent pipelines make sense versus traditional code, exploring concepts like separation of concerns for agents, tool calling versus MCP servers, Google's grounding feature for citation-backed responses, and agent memory management. Christina explains A2A (Agent-to-Agent), Google's protocol for distributed agent communication that could replace both LangChain and MCP. We also cover practical concerns like debugging agent workflows, evaluation strategies, and how to think about deploying agents to production.

If you're trying to figure out when AI belongs in your processing pipeline, how to structure agent systems, or whether frameworks like ADK solve real problems versus creating new complexity, this episode breaks down Google's approach to making agentic systems practical for production use.

--

Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices

Support Developer Voices on YouTube: https://www.youtube.com/@DeveloperVoices/join

Google Agent Development Kit Announcement: https://developers.googleblog.com/en/agent-development-kit-easy-to-build-multi-agent-applications/

ADK on GitHub: https://google.github.io/adk-docs/

Google Gemini: https://ai.google.dev/gemini-api

Google Vertex AI: https://cloud.google.com/vertex-ai

Google AI Studio: https://aistudio.google.com/

Google Grounding with Google Search: https://cloud.google.com/vertex-ai/generative-ai/docs/grounding/overview

Model Context Protocol (MCP): https://modelcontextprotocol.io/

Anthropic MCP Servers: https://github.com/modelcontextprotocol/servers

LangChain: https://www.langchain.com/

Kris on Bluesky: https://bsky.app/profile/krisajenkins.bsky.social

Kris on Mastodon: http://mastodon.social/@krisajenkins

Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/

How do you monitor distributed systems that span dozens of microservices, multiple languages, and different databases? The old approach of gathering logs from different machines and recompiling apps with profiling flags doesn't scale when you're running thousands of servers. You need a unified strategy that works everywhere, on every component, in every language—and that means tackling the problem from the kernel level up.

Mohammed Aboullaite is a backend engineer at Spotify, and he joins us to explore the latest in continuous profiling and observability using eBPF. We dive into how eBPF lets you programmatically peek into the Linux kernel without recompiling it, why companies like Google and Meta run profiling across their entire infrastructure, and how to manage the massive data volumes that continuous profiling generates. Mohammed walks through specific tools like Pyroscope, Pixie, and Parca, explains the security model of loading code into the kernel, and shares practical advice on overhead thresholds, storage strategies, and getting organizational buy-in for continuous profiling.

Whether you're debugging performance issues, optimizing for scale, or just want to see what your code is really doing in production, this episode covers everything from packet filters to cultural changes in service of getting a clear view of your software when it hits production.

---

Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices

Support Developer Voices on YouTube: https://www.youtube.com/@DeveloperVoices/join

eBPF: https://ebpf.io/

Google-Wide Profiling Paper (2010): https://research.google.com/pubs/archive/36575.pdf

Google pprof: https://github.com/google/pprof

Continuous Profiling Tools:

Pyroscope (Grafana): https://grafana.com/oss/pyroscope/

Pixie (CNCF): https://px.dev/

Parca: https://www.parca.dev/

Datadog Continuous Profiler: https://www.datadoghq.com/product/code-profiling/

Supporting Technologies:

OpenTelemetry: https://opentelemetry.io/

Grafana: https://grafana.com/

New Relic: https://newrelic.com/

Envoy Proxy: https://www.envoyproxy.io/

Spring Cloud Sleuth: https://spring.io/projects/spring-cloud-sleuth

Mohammed Aboullaite:

LinkedIn: https://www.linkedin.com/in/aboullaite/

GitHub: https://github.com/aboullaite

Website: http://aboullaite.me

Twitter/X: https://twitter.com/laytoun

Kris on Bluesky: https://bsky.app/profile/krisajenkins.bsky.social

Kris on Mastodon: http://mastodon.social/@krisajenkins

Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/

Git might be the most ubiquitous tool in software development, but that doesn't mean it's perfect. What if we could keep Git compatibility while fixing its most frustrating aspects—painful merges, scary rebases, being stuck in conflict states, and the confusing staging area?

This week we're joined by Martin von Zweigbergk, creator of Jujutsu (JJ), a Git-compatible version control system that takes a fundamentally different approach. Starting from a simple idea—automatically snapshotting your working copy—Martin has built a tool that reimagines how we interact with version control. We explore the clever algebra behind Jujutsu's conflict handling that lets you store conflicts as commits and move freely through your repository even when things are broken. We discuss why there's no staging area, how the operation log gives you powerful undo/redo capabilities, and why rebasing becomes trivially easy when you can edit any commit in your history and have changes automatically propagate forward.

Whether you're a Git power user frustrated by interactive rebases, someone who's lost work to a botched merge, or just curious about how version control could work differently, this conversation offers fresh perspectives on a tool we all take for granted. And if you're working with large monorepos or game development assets, Martin's vision for the future of Jujutsu might be exactly what you've been waiting for.

---

Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices

Support Developer Voices on YouTube: https://www.youtube.com/@DeveloperVoices/join

Jujutsu (JJ): https://github.com/martinvonz/jj

Jujutsu Documentation: https://martinvonz.github.io/jj/

Git: https://git-scm.com/

Mercurial: https://www.mercurial-scm.org/

Rust: https://www.rust-lang.org/

Watchman: https://facebook.github.io/watchman/

Google Piper: https://research.google/pubs/why-google-stores-billions-of-lines-of-code-in-a-single-repository/

Kris on Bluesky: https://bsky.app/profile/krisajenkins.bsky.social

Kris on Mastodon: http://mastodon.social/@krisajenkins

Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/