August 2026 Summaries

Turso’s early-preview concurrent writes feature introduces `BEGIN CONCURRENT` for tursodb databases on Turso Cloud, using an optimistic MVCC model that lets multiple write transactions proceed simultaneously and detects row-level write conflicts at commit time rather than locking the entire database at transaction start. It is aimed at workloads where SQLite’s single-writer model becomes restrictive, including checkout flows with business logic, high-volume ingestion across distinct rows, stream materialization, and long-running data augmentation, while sequential and fast single-writer workloads may not benefit. The approach can improve throughput when transactions include computation or affect separate rows, but transactions that repeatedly update the same “hot” row still conflict and may require schema redesigns such as append-only delta tables or sharded counters. The post demonstrates TypeScript, Python, and Rust implementations, emphasizing bounded retries with exponential backoff and jitter for conflict errors. To use the feature, users must explicitly enable it, create a Turso-engine tursodb database, and issue `BEGIN CONCURRENT` transactions; current limitations include its preview status and lack of support for DDL operations such as `CREATE INDEX` within concurrent transactions.

AgentID is an OpenID Connect provider designed to give AI agents independent, verifiable identities that can be used to create and access Turso accounts without relying on human credentials, shared tokens, or browser-based approval. Built on AgentMail, it ties each agent to a live inbox and a P-256 signing key, allowing the agent to approve OIDC authorization requests through signed JWS assertions while keeping its private key under its own control. The integration separates the agent’s stable identity from its human owner and the infrastructure hosting it, enabling Turso to receive agent identity claims in an ID token and optional owner metadata through a userinfo endpoint. The associated AgentMail inbox also functions as a programmatic communication channel for account notifications, billing alerts, and security messages. AgentID uses standard OIDC discovery, ES256 token validation, PKCE, revocable signing credentials, and live authorization checks, while leaving Turso responsible for determining the permissions and resources granted to authenticated agents.

Poke, an iMessage-based personal assistant that can generate fully functional websites from text prompts, uses Turso to automatically provision a separate serverless database for each site it creates. The per-database design was chosen over a shared database model to isolate performance problems, limit security risks from user-generated code, and avoid paying for always-on capacity for inactive projects. When Poke builds a site, an AI agent creates the application and schema in a virtual machine, deploys the site to Vercel, and stores the new Turso database connection as a deployment environment variable, making the process invisible to users. This infrastructure supports features such as authentication, stored RSVPs, real-time multiplayer whiteboards, and browser games, while allowing users to update sites through additional messages. Poke evaluated alternatives including Neon, Supabase, Cloudflare, and PlanetScale, but selected Turso for its self-service provisioning, isolation model, and serverless pricing. After processing about 100 million messages in three months and creating roughly 10,000 databases, Poke has not yet needed to remove inactive databases, and it expects Turso to remain its default database platform for future user-generated projects.

Database-per-tenant architectures have traditionally been discouraged because server-based databases such as PostgreSQL and MySQL impose per-instance costs, connection-pooling limits, and substantial backup overhead, making thousands of isolated databases expensive to operate. The piece argues that file-based SQLite databases, particularly through Turso Cloud, change these economics by allowing inexpensive, programmatically created databases with no idle process or reserved memory, making individual tenant databases more practical. It highlights stronger inherent data isolation than tenant_id filtering and row-level security, along with potential benefits for compliance, encryption key management, regional data residency, data export, and deletion requests. The proposed implementation uses a central tenant registry, request routing to the appropriate database, and template-based provisioning for new tenants. However, the approach introduces challenges around coordinating schema migrations and producing cross-tenant analytics, which may require aggregation pipelines or a dedicated data warehouse. It is presented as most suitable for enterprise SaaS, regulated industries, residency-sensitive applications, and products requiring portable tenant data, while shared databases may remain preferable for massive consumer applications, real-time cross-tenant reporting, and mature systems already built around a shared schema.

SQLite has become a more viable production alternative to PostgreSQL and MySQL as modern SSDs, write-ahead logging, improved tuning practices, and platforms such as Turso reduce historical performance and operational limitations. It can be especially advantageous for read-heavy or moderate-write applications, local or multi-region read access, lightweight per-tenant databases, and teams seeking lower costs and less infrastructure complexity. Migration involves exporting schemas and data, converting incompatible SQL features and types, importing a WAL-configured SQLite file into Turso, and thoroughly testing query plans, load behavior, and concurrent write patterns. In exchange for simpler operations, lower hosting costs, file-based backups, and local synchronization capabilities, organizations may give up PostgreSQL’s stronger complex-join optimization, stored procedures, richer triggers, specialized types, extensions such as PostGIS, and built-in replication. The recommended approach is to begin with a non-critical workload and evaluate whether the application’s feature requirements, write concurrency, data size, and team expertise make SQLite an appropriate fit.

CTO.new, an Engine Labs platform that deploys teams of autonomous AI agents to handle engineering work, uses a separate Turso database for each customer project to coordinate agent tasks, status, and metadata outside the projects’ sandboxed compute environments. After previously reducing per-user infrastructure costs by replacing Supabase instances with Turso databases, the company returned to Turso when it needed a scalable, isolated, and continuously accessible store for agent state. The per-project databases act like shared task boards that agents can query and update without waking potentially costly sandboxes, while also limiting security and multi-tenant isolation risks. CTO.new reports operating tens of thousands of databases for more than 50,000 users at approximately $500 per month, with around 2,000 databases actively queried at peak, and says the resulting cost savings support its free tier. The company expects its database count to grow into the millions as demand expands.

Turso Cloud has introduced early access to concurrent writes, overcoming a traditional limitation of SQLite by allowing multiple transactions to proceed in parallel with the use of the BEGIN CONCURRENT command. Unlike the traditional SQLite model that locks during write transactions, Turso employs a multi-version concurrency control (MVCC) engine, allowing several writers to operate optimistically without immediate locking, thereby increasing throughput and reducing the need for backoff-and-retry loops. Conflicts are detected at the row level during commit, which minimizes false conflicts and enhances efficiency when transactions touch different rows. This development is part of Turso's larger effort to provide a high-performance, cost-effective database solution, particularly appealing for developers looking for scalable and reliable options. Turso's approach draws on the principles of Microsoft's Hekaton engine, adapting them to work seamlessly with SQLite's B-tree storage. The feature is available for early preview, and users must enable it in their Turso dashboard, utilizing either the CLI or the dashboard UI to create a Turso database for concurrent transactions.