How Turso built a transactional database using Amazon S3 Express One Zone

Turso is a transactional, cloud database platform built on SQLite, serving developers and enterprises that need lightweight, high-density databases at the edge and in the cloud. Because each database is just a file, a single Turso compute node can host millions of them with no cold start. Turso delivers these databases in a Bring Your Own Cloud (BYOC) model, where customer data resides entirely within their own AWS accounts.

Transactional databases traditionally rely on synchronous writes to local disk, shared storage arrays, or network-attached volumes, to provide durability. In a transactional database, a write is only considered completed after the data persists durably, so it can survive a server crash or power failure. This persistence creates a tight coupling between compute and storage. If a pod fails, data must be recovered before the database can resume. Containerized and BYOC environments are constrained by maintaining physical servers because the storage is embedded in them. Turso needed to decouple durable state from compute nodes so that pods become truly ephemeral. By replacing local disk with Amazon S3 Express One Zone as the durability layer, Turso achieved durable transactional writes at 6.4 milliseconds average latency, avoiding persistent volume management, and enabled instant pod recovery, all while keeping costs aligned with usage through batching writes across multiple tenants.

In this post, we walk through how Turso evaluated S3 Express One Zone for transactional durability, the multi-tenant batching strategy that optimizes costs, the final write-through architecture with S3 Express One Zone as the source of truth and local NVMe as a read cache, and the operational benefits that enable automated BYOC deployments.

The challenge: Stateful infrastructure in a BYOC world

Compliance requirements, data residency regulations, and security policies all push toward keeping data within organizational boundaries, while still wanting a fully managed database experience. In a BYOC model, the vendor must remotely manage persistent volumes, coordinate backups, and handle data migration in an account they might have limited access to.

For Turso, delivering managed databases inside customer accounts meant deploying stateful workloads on Kubernetes. Traditional database architectures store write-ahead log (WAL) entries on local disk before acknowledging transactions. This persistence step (called fsync) can take anywhere from microseconds on fast SSDs to several milliseconds on hard disks. Turso found fsync took approximately 2 milliseconds in their environment. This creates a hard dependency between compute pods and their storage, which means pods can’t move freely, the Kubernetes scheduler is constrained by data locality, and pod recovery requires coordinating between local WAL files and asynchronous backups.

Turso needed all durable state to live separated from the compute nodes, allowing pods to be truly ephemeral. The ideal solution would provide durability equivalent to local disk, with latency acceptable for transactional workloads, at a cost that scales with their multi-tenant model, which is where they looked at S3 Express One Zone.

Evaluating S3 Express One Zone for transactional durability

S3 Express One Zone is a high-performance, Single-AZ storage class purpose-built to deliver consistent single-digit millisecond data access for your most frequently accessed data and latency-sensitive applications. It delivers consistent, predictable performance with strong read-after-write consistency.

Turso evaluated S3 Express One Zone as a replacement for local storage in their transaction commit path. They ran benchmarks from an Amazon Elastic Compute Cloud (Amazon EC2) instance co-located in the same Availability Zone, testing 1,000 operations at typical database transaction sizes and observed the following results.

The following table summarizes S3 Express One Zone latencies as measured by Turso’s benchmarks (4 KB operations, same Availability Zone).

Two performance characteristics made S3 Express One Zone a perfect fit for transactional durability:

• Low PUT latency – At 6.4 milliseconds average for a 4 KB write to S3 Express One Zone, the total commit latency is well within acceptable bounds for majority application workloads where network roundtrips and application logic already contribute 10–100 milliseconds per request.
• Consistent tail latency – The P99 of 7 milliseconds means Turso could guarantee predictable transaction commit times to their customers without the tail-latency variability that disrupts real-time applications.

Optimizing costs with multi-tenant batching

Turso’s multi-tenant model hosts hundreds of databases per node, where per-database write rates vary widely. They needed a pricing model that aligns costs directly with actual usage rather than provisioned capacity. S3 Express One Zone’s pay-as-you-go model delivers exactly this, so Turso only pays for the writes they perform.

To maximize the value of this pricing model, Turso designed their platform to batch writes across databases. Their compute nodes host hundreds of active SQLite databases simultaneously. Rather than uploading each transaction individually, the platform accumulates WAL writes from dozens of databases over a few milliseconds, then uploads them together in a single PUT request. This batching adds only a few milliseconds of delay, which is acceptable because the total write path (including the S3 Express One Zone PUT itself) still completes well within the latency budget of most application workloads.

This batching approach introduces a trade-off between cost and latency. A longer batching window collects more transactions per PUT request (reducing cost per transaction) but adds latency to each individual commit. Turso addresses this by keeping the batching window short, typically a few milliseconds, which keeps total write latency within single-digit milliseconds while still capturing enough transactions to meaningfully amortize request costs. The result is that S3 Express One Zone request costs are amortized across many databases per PUT request. This approach is uniquely enabled by SQLite’s file-based architecture, which allows a single node to host hundreds of active databases and batch their writes together.

Final architecture: Write-through with S3 Express One Zone as the durability layer

Turso’s architecture uses S3 Express One Zone as the source of truth for all committed transactions, with local NVMe storage serving as a cache for read performance.

The write path consists of the following steps:

1. A transaction executes in memory on the compute node.
2. The platform waits a few milliseconds to batch WAL entries from multiple databases on the same node.
3. The batched WAL entries are uploaded to S3 Express One Zone using a single S3 PUT request.
4. After the PUT request returns a successful response, confirming the data is durably stored, the transactions are acknowledged to the clients.
5. The data is also written to local NVMe storage for fast subsequent reads.

The read path consists of the following steps:

1. The application reads from the local NVMe cache, avoiding the latency and cost of an S3 request for data that already lives on local NVMe.
2. On a cache miss, data is fetched from S3 Express One Zone (single-digit millisecond latency).
3. Fetched data is cached on local NVMe for future reads.

Every few minutes, the WAL is folded into the full database file through a checkpointing process. The resulting database file is then stored in S3 Standard for the long-term, benefiting from availability and durability across multiple Availability Zones. After checkpointing, the consolidated database file in S3 Standard serves as the long-term recovery baseline. Because S3 Standard has a lower storage cost and supports retaining previous versions using S3 Versioning, these checkpoints are retained at minimal additional cost.

The following diagram illustrates the architecture.

Operational benefits

The architecture with stateless compute transforms how Turso operates databases in customer accounts:

• Pod mobility and instant recovery – Because no durable state lives on the local node, Kubernetes can schedule, move, and replace pods freely. If a pod fails, a replacement pod starts serving reads immediately from S3 Express One Zone while streaming data into its local cache in the background. This means their customers no longer have to wait for backup restoration or data migration across disks when a pod fails. With all durable state in S3 Express One Zone and periodic checkpoints to S3 Standard, recovery comes inherently. Even if the entire compute tier is lost, the database can be reconstructed from Amazon S3.
• Simplified BYOC deployments – Deploying in a customer’s AWS account only requires creating an S3 Express One Zone directory bucket, launching compute pods, and configuring AWS Identity and Access Management (IAM) policies. This means persistent volumes or StatefulSets are no longer needed. The customer’s data resides entirely within their own S3 buckets, simplifying compliance and audit requirements.
• Elastic scaling – Adding compute capacity means launching new pods that immediately access all data in S3 Express One Zone. Scaling down means terminating pods without any data migration. Therefore, the architecture naturally adapts to workload changes without manual intervention.

Conclusion

Turso’s architecture demonstrates how they achieved durable writes and single-digit millisecond latency using Amazon S3 Express One Zone for transactional SQLite databases. By combining S3 Express One Zone’s consistent performance with multi-tenant batching, Turso built a database architecture that simplifies operations, enables automated BYOC deployments, and provides built-in recoverability. They replaced local disk fsync (approximately 2 milliseconds) with batched PUTs to S3 Express One Zone (approximately 6.4 milliseconds on average), trading a few milliseconds of additional write latency for stateless compute and operational simplicity. Total commit latency remains well within the latency budget that most applications can handle, while eliminating the tight coupling between pods and persistent volumes.

Before this change, pod recovery required coordinating between local WAL files and asynchronous backups, and BYOC deployments meant managing persistent volumes and StatefulSets in customer accounts. Now, pods are disposable. A failed pod is replaced almost instantly, with the new pod reading directly from S3 Express One Zone while warming its local cache in the background.

For database vendors and infrastructure builders, Turso’s architecture demonstrates a deployment model that trades a few milliseconds of additional write latency for operational simplicity, stateless compute, and automated BYOC deployments. The durable state lives entirely in Amazon S3, avoiding persistent volume management or data migration. For application developers, it means managed databases can run in their own AWS account without the overhead of persistent volumes or data migration.

To explore S3 Express One Zone as the durable cloud storage for your database workloads, refer to the S3 Express One Zone documentation. You can also go through the guidance for writing high transaction workloads on S3 Express One Zone. To estimate your costs, use the AWS Pricing Calculator. For more guidance, contact your AWS account team or visit the AWS Storage Blog for more customer stories and best practices.