Glauber Costa from Turso
Turso founder Glauber Costa explains how a fast pivot turned SQLite into a production platform, why one file per database changes the economics of multitenancy, and how constraints produced a CLI that became the product rather than an afterthought.
Glauber Costa founded Turso, a managed database platform built on libSQL, the company’s fork of SQLite. The service adds the infrastructure needed to use SQLite’s familiar model in production web applications.
Glauber recounts the evidence that drove a company-wide pivot, the architecture behind thousands of databases per customer, the split between free usage and paid organizational value, and the ruthless scoping that let a very young product move unusually fast.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
What does “SQLite for production” mean?
SQLite is trusted, embedded almost everywhere and capable of handling far more than its “Lite” name suggests as hardware improves. Web workloads still need networking, replication and managed operations around the file. Turso supplies that layer through libSQL and a hosted service, making the simplicity and efficiency of SQLite practical for production applications that do not need petabyte-scale machinery.
How did database-per-user become Turso’s defining use case?
The early service mapped a customer’s virtual machine to one SQLite file and offered a few databases. Users repeatedly asked why a file-based system could not create thousands. Turso changed routing so each database name addressed its own file, raised the free allowance to hundreds and paid plans to thousands, and saw weekly active users grow dramatically. The community exposed the stronger use case after launch.
Why can Turso offer so many databases?
An idle SQLite database is simply a file and consumes no active compute. A web server can hold many files and open only the one receiving a request; idle virtual machines can also sleep and wake on demand. That efficiency avoids a large always-on cluster per database and lets Turso pass lower costs into generous limits, even though the architecture can become more efficient still.
What encourages a free user to choose a paid plan?
Usage limits are only one boundary. A side project may fit comfortably in the free tier, while a real organization needs teammates to manage the database, stronger support and assurances such as compliance. Customers pay for collaboration and the vendor relationship as much as raw requests. That preserves a broad developer community while creating higher-margin plans for workloads whose operational consequences have become serious.
Why did Turso invest so heavily in its CLI?
The founders had spent years in the Linux kernel and database infrastructure, so command-line tools were native to them. After pivoting, difficult funding conditions made a polished web interface too slow to build. The company chose a CLI-only launch and therefore had to bring onboarding, discovery, feedback and every core workflow into it. Constraint removed the option to treat the CLI as a thin automation layer.
How does “the CLI is the product” change its design?
Creating replicas, leaving feedback and even booking a meeting had to work from the command line, with browser handoffs only where something such as card entry demanded it. API-first architecture kept those flows composable because the CLI mostly calls the same public platform operations. New capabilities can launch in the CLI, gather feedback quickly and reach the web interface after the interaction is understood.
Why did the company pivot from its previous product?
The original product offered global persistence from TypeScript and had a polished interface but weak adoption after a year. libSQL, released as a supporting fork, surpassed that project’s GitHub attention within weeks. With limited runway and a difficult market, the team treated the stronger signal as decisive, accepted that prior UI investment was sunk cost and rebuilt the company around the database developers were already asking for.
What does moving fast look like beyond saying it?
Before launch, Turso planned usage limits but lacked backend metering and enforcement. Building them threatened the date, so the team asked what would happen if it did nothing. Customers would not complain about receiving more reads than promised, and the CLI could report client-side usage cheaply. Removing enforcement preserved the launch and let real demand choose subsequent work. Even the “minimum” scope usually contains another removable layer.
How can speed improve rather than reduce product quality?
Time pressure forced Turso to find a polished path that did not require the conventional polished artifact. A focused CLI could be excellent sooner than a complete web dashboard. Once the service reached users, requests for database-per-user architecture replaced speculative work with clear priorities. Fast shipping is not permission for a careless experience; it is a search for the smallest coherent experience that starts the learning loop.