The current wave of AI agents has moved beyond simple chat interfaces toward the creation of functional artifacts. Developers are now building systems that can spin up entire web applications on the fly, but this capability introduces a critical infrastructure bottleneck: state management. When an AI generates a thousand different websites for a thousand different users, the traditional approach of a single, multi-tenant database becomes a liability. The risk is no longer just about data leakage, but about system stability in an environment where the code—and the queries—are written by a non-deterministic model.

The Architecture of Ephemeral Data

Poke, an AI assistant operating via iMessage, solves this by treating the database not as a shared resource, but as a disposable asset. When a user requests a website, Poke executes the task within a virtual machine and deploys the resulting application to Vercel. Simultaneously, the system automatically provisions a dedicated Turso database—a serverless platform compatible with SQLite—for that specific site. This means every single AI-generated artifact possesses its own isolated data store.

Over the last three months, this pipeline has processed approximately 100 million messages, resulting in the creation of roughly 10,000 independent databases. To maintain operational stability, Poke employs a tiered storage strategy. Core operational data, including user account details, agent state values, and internal system logs, are housed in PlanetScale, a MySQL-compatible serverless database. Only the data generated by the AI-created websites is routed to the individual Turso instances. The unit of isolation is not the user, but the individual website or artifact.

The provisioning process is integrated directly into the deployment flow. Once the site is pushed to Vercel, the Turso DB is created, and its connection URL is automatically injected into the Vercel environment variables. This ensures the application can connect to its database immediately upon launch. Because the time required to provision a Turso DB is shorter than the inference time the model needs to generate the website code, the end user experiences no perceptible latency.

This automation extends to the database schema itself. The AI agent does not simply write frontend code; it designs the data structure, writes the Data Definition Language (DDL) to define tables, and configures the backend to match that schema. If a user requests a modification to the site, the agent intervenes again to perform the necessary schema migrations. This entire lifecycle operates as an automated pipeline between the agent and the platform, requiring no manual oversight from the Poke engineering team.

This approach allows Poke to move beyond static pages into complex, stateful applications. The agent can independently decide to implement authentication or data persistence features. In one instance, a request for a whiteboard application resulted in a real-time multiplayer experience combining Vercel WebSockets with a Turso DB. The system has also been used to deploy dynamic applications requiring persistent state, such as browser-based 3D FPS games, poker, and billiards.

Solving the Noisy Neighbor Problem

The decision to use Turso over other serverless options like Neon, Supabase, Cloudflare, or PlanetScale was driven by the inherent unpredictability of AI-generated code. In a standard multi-tenant architecture, a single inefficient SQL query can consume excessive CPU or exhaust the connection pool, degrading performance for every other user on the system. This is known as the noisy neighbor problem. By physically isolating each site into its own database instance, Poke ensures that a poorly optimized query in one AI-generated site cannot impact the performance of another.

Security is the second primary driver for this isolation. When an AI writes the code, there is an inherent risk of introducing vulnerabilities. Physical isolation prevents a security breach in one artifact from escalating into a cross-tenant data leak. If a specific site's database is compromised or corrupted due to a flaw in the AI's logic, the blast radius is limited to that single instance.

From a cost perspective, the serverless nature of Turso is essential for a service that generates a high volume of ephemeral sites. Traditional databases often require a constant connection pool or a running server process, which would be prohibitively expensive when managing 10,000 separate instances. Turso's architecture allows databases to remain idle without incurring constant execution costs, aligning perfectly with the usage patterns of AI artifacts, where many sites are created but only a fraction remain active over time. The only remaining operational gap is the lack of an automated garbage collection system to prune databases from sites that have become entirely inactive.

By shifting from a centralized multi-tenant model to an API-driven physical isolation model, Poke has effectively decoupled the risks of AI-generated code from the stability of its core infrastructure.

This transition transforms the database from a rigid piece of infrastructure into a flexible, programmable component of the AI's creative output.