2 million databases and counting: the architecture behind Sauna's AI teammate

Sauna is a proactive AI assistant for work, launched in April 2026.

In a modern team, very little work happens in isolation, but a lot of it is siloed across tools and individuals. Sauna learns what you and your team are working on, from individual tasks and preferences to team deliverables and relationships, and acts proactively to help you get work done.

An assistant for your personal life is helpful, but as Matthias Pichler, Founding Engineer at Wordware, puts it: "there's only so many restaurants that you can book in a week." Sauna focuses on work: the day-to-day chores and tasks that make businesses run. It's proactive from day one, and surfaces actions from your Slack, Gmail, calendar and Granola. And because the whole team uses it, Sauna also learns how people work together.

Every session and agent a user starts in Sauna gets its own database, and so does every inbox and calendar they connect. That's where Turso comes in: Sauna created over 2 million total databases, with around 90,000 created on any given day.

#A Proactive AI assistant with compounding context

The Sauna team built the product on the idea that "proactivity, persistent memory and learning are the foundations" that everything else builds on. Sauna doesn't wait to be asked: it watches your inbox, calendar, and all relevant connections, flagging what needs doing before you get to it. As you continue to work (writing emails, analyzing data, drafting presentations, reviewing candidates), Sauna compounds with additional context: past decisions, the people involved, how you like things done. This makes the proactive suggestions and drafted work Sauna brings you progressively stronger, and lessens the burden to remember every last detail and start work from scratch. Each repetition adds more context, and that context builds up over months.

That is what the Sauna team calls "compounding context," and the effect grows when a whole team uses Sauna. As Matthias puts it, Sauna starts "curating relationships and information about you and your company," so over time it builds a picture of how the team works together: who works with whom, who owns which project, and what each person is in the middle of. That shared knowledge is what lets your Sauna ask a colleague's Sauna for specific docs, or keeps a shared client space current without anyone having to re-explain the project to their own assistant.

#The context architecture

Matthias describes the memory behind Sauna in terms of how people remember. There's the conversation you're in. There's a memory that brings up past conversations when a topic comes up again (the same way something someone says reminds you of something else). And there's what you write down and file away because you can't keep it all in your head.

In practice, Sauna's architecture has four elements. Two run on Turso, and the Sauna team built the other two in-house:

Conversations. Every session and agent you start with Sauna gets its own Turso database, which holds the full chat history of that conversation.
Synced connections. Every inbox or calendar you connect gets its own Turso database, kept in sync, so Sauna has a local copy to search instead of going back to Gmail every time.
Memory system. A two-tier memory system, built with a provider, curates relationships and information about you and your company. When a topic comes up again, it pulls in what was said about it in earlier conversations.
File system. A custom, versioned and searchable file system where the Sauna agent keeps the drafts, documents and proposals it works on.

What this architecture enables:

Sharing exactly what you choose. Users give Sauna their inbox, calendar and meetings, and in a multiplayer product they share some of that with colleagues. Each connection is its own database, so data can't leak from one user to another, and an agent only gets access to the connections it's been allowed to use. Sharing your inbox with your Sauna assistant means sharing that one database and nothing more. Users don't have to rely on rules that filter individual rows and columns to keep the rest private. In Matthias's words, the security boundary is "a lot easier to reason about and a lot harder to break."
Fast answers from your own data. With a local copy of each connected inbox and calendar, Sauna can search your email and events without calling an external service for every lookup. As Matthias says of his own meeting notes: "I don't even know how I can search through my Granola transcripts. I have to scroll and think and try to remember the meeting, but really, I can't really figure it out. And Sauna doesn't have to because it actually gets a full copy."
A history you can go back to. Every conversation is kept, so you can find work from weeks ago and pick it up again.
Retention for each conversation. Because each conversation is its own database, Sauna can manage them individually. Matthias describes long-term plans to move conversations you haven't opened in a long time to cheaper storage, or to offer tiered retention periods.

#Why Turso over the alternatives

Matthias chose Turso because he sees agents changing what software gets built, and Turso is one of the few databases designed for that. In his own words:

"With the current state of agents, everybody spins up a small app for something. Software used to be built by teams, and now the demand for these individual, throwaway pieces has grown massively. There are very few providers that actually build a primitive that fits that, where you can spin up a database and give it to an agent. Turso is right now one of the very few, if not the only one. I think this direction, these one-off pieces of software, will be the next innovation frontier."

Turso had been on Matthias's radar for years: from Glauber's and Pekka's posts on X (we knew all that effort posting on X would pay off!), through the fork of SQLite, to the plan to rewrite SQLite in Rust. Sauna itself has run on SQLite from the start, with every session and agent getting its own database. Getting that model onto Turso took two steps:

Cloudflare Durable Objects. Each Durable Object comes with a small SQLite database attached, which matched Sauna's one-database-per-session model. The database itself worked well, but the team ran into problems with the hosting side of the platform and decided to move off it.
Cloudflare Containers with Litestream. Sauna moved to containers, kept SQLite and added Litestream for replication. Litestream turned out to be slow and expensive. The team wanted something just as familiar as SQLite that would perform better and cost less.
Turso. Turso was the technical fit, but per-database pricing had kept Sauna away: every active database carried a fixed monthly cost. When Turso removed the active database limit on every paid plan in May 2026, that barrier went away, and Sauna made the switch.

Today, Turso Sync powers most of Sauna, from chat histories to the synced copies of inboxes and calendars. With Sync, each database is a local file that sits next to the code using it. Reads and writes happen locally by default, and the application pushes its changes to Turso Cloud and pulls remote changes down when it chooses. If a pull arrives while local changes haven't been pushed yet, Turso does three things in one atomic step: it rolls the database back to the last synced state, applies the remote changes, and replays the local ones on top.

Because sync is part of the database engine, Sauna gets a two-way sync, unlike Litestream, which only streams changes out to storage. Matthias sums up what that means for Sauna: "We kind of get local speed, but we know that it is going to be replicated and stored remotely, such that if that goes down, we still have the data."

#What this looks like for Sauna users

Most of what Turso does for Sauna happens where users never see it. However, these benefits reach them directly:

Every conversation stays available. Idle databases cost little to keep, and there's no charge per database, so Sauna can keep every chat history instead of deciding which ones to delete. A conversation from months ago is as easy to search and pick up as one from this morning.
Sauna keeps working when a hosting provider doesn't. Turso holds the data separately from the compute, so when a hosting provider ran into problems, Sauna could move to another one without migrating any data. The team has since built a switch that moves between two providers, with Turso as the one constant underneath. For users, Sauna always stays up.
An always-on assistant at a reasonable cost. Sauna works in the background around the clock, and it can read data straight from Turso without spinning up compute to get at it. That keeps the cost of a proactive AI assistant under control.

As Matthias puts it:

"Because Turso is completely separate from our compute, it's been the one constant while we've moved between hosting providers, and our users never had to notice. We don't have to spin up any compute just to read someone's data, and keeping idle databases around is cheap, so we can hold on to every conversation people want to come back to. Every saving on our side turns into a better product for the people using Sauna."

All of this supports what users do with Sauna, both in complexity and reach. Sauna can build custom apps, ranging from Hyperhuman, a Superhuman-style email client built over your own Gmail, to Founder Desk, a founder's CRM with no data entry. Sauna works seamlessly wherever the user is, with most users also talking to Sauna over iMessage and WhatsApp. There it's the same assistant with the same memory and connected tools, so a voice note sent between meetings can come back as a drafted reply, a pulled number, or a finished doc.

#What's next for Sauna & Turso

Sauna is growing, and the team is hiring for a number of roles at its office in San Francisco.

On the database side, two things are on Sauna's list. The first is the file system. Today it runs on infrastructure the team built in-house, and moving it to Turso is something they're considering for the future.

The second is MVCC. By default, a Turso database lets one connection write at a time. With MVCC (multi-version concurrency control), several connections can write at once. Turso v0.8 made this much faster by adding group commit, which shares one disk flush across a batch of commits instead of paying for one per commit. Under concurrent writes, Turso now has up to 500x lower tail latency and 7x higher write throughput than SQLite. For an assistant where background agents and the people they work for may be writing to the same data at the same time, this is a natural next step. Sauna hasn't needed it yet, but Matthias expects the team will experiment with it.

Building agents that need a database for every session, user or connection? Get started with Turso Cloud today.