How Poke Gives Every User Their Own Database, Without Them Ever Knowing

Poke is a personal assistant that lives in your iMessage. You text it and it does things. One of those things is building you a fully functional website, complete with authentication, real-time multiplayer, and a live database. All from a single text prompt.

That last part is where Turso comes in.

#"OpenClaw for Normies"

That's how people on X apparently describe Poke. It's a personal assistant that runs in iMessage and other native messaging apps, and it's designed for people who don't think in API calls or deployment pipelines. You ask it to make a website...and it makes a website.

Samyok Nepal was the first engineering hire at Poke and has been involved in architectural decisions since the product launched. When the team decided to build out a website-generation feature, they needed a database solution that could scale to every user, stay cheap for the majority of sites that would never get much traffic, and never let one user's bad queries ruin someone else's experience.

The evaluation took just a few hours. They landed on Turso.

#The Problem: One Database Won't Cut It

The obvious solution to "users need databases" is to give all of them one. Poke already uses PlanetScale for its core system data: user accounts, agent state, and internal operations. It works well for that. But a central instance with tables scoped per user and connection pooling was a non-starter for user-generated websites.

Here's how Samyok put it:

"We knew that some user would create a website with really really bad database access patterns, and we knew that we did not want this one website to take down everyone else."

The concern was legitimate. Poke's users generate websites through an AI agent, and agents are not always going to produce optimal SQL. A query that hammers CPU on a shared database doesn't just slow down one website. It degrades the experience for everyone on the platform. And because the websites are public-facing, they can receive unexpected bursts of traffic at any time.

Beyond performance, there was a security dimension. User-generated code running against a shared database creates cross-contamination risk. If one user's site had a vulnerability, a centralized schema made data leakage a real concern. Individual databases meant that even in a worst case, the blast radius was contained to a single artifact.

Cost was the third factor. A large percentage of Poke websites are one-offs: someone builds a game for their Discord server, shares it around for a week, and then it sits idle. Allocating a persistent, always-on database for every one of those and paying for it indefinitely wasn't viable. Turso's serverless pricing meant Poke only pays for databases that are actually being used.

#How the Architecture Works

When a user texts Poke asking for a website, an agent spins up a small virtual machine and starts building. The site gets deployed to Vercel. A Turso database gets provisioned automatically, one per artifact, and the database URL is saved as an environment variable in the Vercel deployment.

That's it. From the user's perspective, they sent a text and got a website.

The provisioning is fast enough that it's never been a noticeable part of the experience. As Samyok put it: "I don't think we even benchmarked how long it takes to make a Turso database because it's unnoticeable." The model inference time required to actually build the site dwarfs any provisioning overhead.

The AI model handles schema creation entirely. It writes the DDL, sets up whatever tables the site needs, and scaffolds the application code around them. The Poke team has never had to audit the generated schemas, because the system just works. For type safety between the front-end and back-end, they use Handstack Start to keep endpoints in sync.

When a user wants to modify a site later, they just text Poke again. The agent goes back in and makes the changes, updating the schema if needed.

#What Users Actually Build

This is where the architecture starts to look interesting. A lot of the websites Poke generates are effectively static. But because there's a database available for every single one, the agent will use it whenever it adds value, even when the user didn't explicitly ask for it.

Someone asked for a whiteboard. Poke added multiplayer functionality, because it could.

Members of Poke's Discord community built a collection of games that other members could play: pool, poker, and a 3D first-person shooter running in the browser. The real-time game state runs through WebSockets on Vercel, backed by Turso.

The non-technical users who make up most of Poke's audience don't know any of this is happening. They don't think about databases. They think about whether Poke actually did what they asked. A login form that works, an RSVP that actually records, that's what registers. The database is invisible infrastructure that makes the experience feel complete.

#Choosing Turso Over the Alternatives

The team evaluated Neon, Supabase, Cloudflare, and PlanetScale before settling on Turso. The decision came down to a few things.

PlanetScale was already in the stack and trusted, but the centralized model didn't fit the isolation requirements. The serverless, per-database model Turso offered was a better match for the use case.

Onboarding was self-serve. The team signed up a few days before launch. Because they had a history of breaking infrastructure providers, hitting limits on major clouds and taking down database services with traffic spikes, they picked the highest-tier plan specifically because it came with a dedicated Slack channel.

The Slack channel has five messages in it. All of them are Glauber from Turso checking in to say congratulations and ask how things are going.

"Turso was one of the only vendors that we've had where our traffic did not bring down the platform... the Slack channel just never got used."

It turned out Turso just works, so it never became an issue.

#Scale and What Comes Next

Poke has processed roughly 100 million messages in a three month period and handled 10,000 databases created to date. The number of databases created scales with the number of websites generated, which scales with message volume. The number is not small.

The team hasn't built garbage collection yet. Databases for inactive sites just stay provisioned. That's partly a function of Turso's serverless pricing making it affordable to hold onto them, and partly a function of the team not needing to solve that problem yet.

Custom domains are free for any user to add. Rate limits exist on the number of websites a user can generate per day, but no features are paywalled. Content moderation is handled reactively: a support team takes down sites that violate terms of service when they're reported.

For future projects involving user-generated content, Turso is the default choice. As Samyok put it: "If there's any user-generated things that we end up doing in the future, Turso is almost certainly going to be the database of choice for anything user generated, roughly."

#The Broader Pattern

What Poke built is a good example of a use case Turso is specifically designed for: massive multi-tenancy where each tenant gets full isolation, provisioning is invisible, and the cost model holds up across a long tail of low-activity instances.

A centralized database with per-user schemas carries real fragility. One badly-written query can saturate the connection pool. A single vulnerability can expose data across user boundaries. Idle capacity accumulates cost. The per-database model sidesteps all of that before it becomes a problem.

The agent-generated DDL angle is also worth noting. The Poke team doesn't review schemas or write migrations. The model creates whatever structure the site needs, and Turso runs it. That's a pattern that's going to become more common as AI agents take on more of the implementation work, and it puts a premium on databases that are reliable enough that the humans in the loop don't have to babysit them.

As Samyok put it, "Turso just works. That's the whole story, really." For an infrastructure provider, it's probably the best thing a customer can say.

Interested in building something similar? Get started with Turso, the free tier supports up to 100 databases and you can be in production the same day.