# StarbaseDB: a SQLite database on Durable Objects, frozen since the acquisition > StarbaseDB put a real SQLite database behind an HTTP API on Cloudflare Durable Objects, with a Worker in front, a Studio interface, websockets, transactions and scale-to-zero. The README opens by saying the repository will not receive any further changes, because Outerbase was acquired by Cloudflare. **outerbase/starbasedb** — HTTP SQLite scale-to-zero database on the edge built on Cloudflare Durable Objects. - Repository: https://github.com/outerbase/starbasedb - Website: https://starbasedb.com - Stars: 1,169 · Forks: 193 - Language: TypeScript - License: AGPL-3.0 - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/outerbase-starbasedb ## The README opens with a caution, not a pitch The first thing in the StarbaseDB README is a caution block, and it is the most important line in the repository. Outerbase has been acquired by Cloudflare. This repository will not be receiving any additional changes. Everything else in the README is written in the present tense, which is what makes the caution read oddly, and the result is a project that describes a working product and tells you at the same time that the code is frozen. The recent releases are v0.1.4 from 2025-01-15, v0.1.3 from 2024-12-21 and v0.1.2 from 2024-12-09, and the last push to the repository was on 2026-06-22, so the branch still moves, but the published versions stopped in January 2025 and there is no more release planned. The project itself is an open-source, scale-to-zero, HTTP SQLite database built on top of Cloudflare Durable Objects. The description is unusually short for a database product, and each phrase in it is a design decision. HTTP means there is a client that speaks it, whatever language the client is written in. SQLite means the storage is a real relational engine with a file, rather than a key and value store pretending to be one. Scale-to-zero means an idle database costs nothing, because the Durable Object holding it is not running. And Durable Objects means the unit of isolation and the unit of state are the same thing, which is the trick the whole product is built on. The licence is AGPL-3.0, the primary language is TypeScript, the default branch is `main`, and the homepage is starbasedb.com. The code in the repository is published under the `@outerbase` scope on npm, as `@outerbase/starbasedb`. ## A Worker in front, a Durable Object holding the file The deployment section explains the architecture in two sentences, and they are the whole design. Deploying a new SQLite database instance to a Cloudflare Durable Object can be done via a single command, and the command creates two new resources in your Cloudflare account, a Worker and a Durable Object. Your Worker is what clients make network requests to for fetching data from your database, and the Durable Object itself is the SQLite storage. That split is what makes the product possible. A Durable Object is a single-threaded compute instance with its own storage, and a SQLite file lives inside it, and a database is therefore one object with one writer and no lock contention to reason about. The Worker in front is the part that speaks HTTP, so the client never talks to the Durable Object directly and the protocol handling lives in code that can be changed without touching the data. The cost of that model is the platform requirement, and the installation script is blunt about it. If you do not have a paid Cloudflare account, your deployment will fail, and the console output says it in capitals: you must have a paid Cloudflare account to use SQLite in Durable Objects. It is not a soft requirement, because SQLite in Durable Objects is a feature of the paid plan. Scale-to-zero compute is listed among the features as a way to reduce costs when the database is not in use, and it follows from the same architecture. A database that is not being queried has no object running, so it is not billed, and the trade is a cold start when the next request arrives. The rest of the feature list is what a database user expects to find, and the entries are more specific than the marketing usually is. Transactions support exists for executing interdependent collections of queries, so a multi statement change is one unit rather than several. There are web socket connections to query the database with low-latency web sockets. A REST API is automatically included for interacting with your tables, which means the rows are reachable without writing SQL for the common case. And a database interface is included out of the box, deployed with the Worker, which is the Studio page you log into after installation. ## One command, and a default password you should change The installation is a piped shell script, which is the fastest possible start and also the thing a reviewer should think about for a moment. ```bash curl https://starbasedb.com/install.sh | bash ``` The script clones the repository, asks for the Cloudflare account id, from `wrangler whoami` or the Cloudflare dashboard, and deploys the Worker. The console output it produces is worth reading in full, because it states the terms of the deployment: ```text ========================================== Welcome to the StarbaseDB installation script! This script will deploy a Cloudflare Worker and create an Outerbase Starlink session. If you don't have a paid Cloudflare account, your deployment will fail. IMPORTANT: You _MUST_ have a paid Cloudflare account to use SQLite in Durable Objects. ========================================== ``` After the deployment the Worker is at a URL of the form `https://starbasedb.{YOUR-IDENTIFIER}.workers.dev`, and the script creates a Studio user account for it: ```text Outerbase Studio user account created! Use the following URL to view your database: https://starbasedb.{YOUR-IDENTIFIER}.workers.dev/studio Username: admin Password: password NOTE: You can change your Outerbase Studio password in the wrangler.toml file and redeploy. ``` The default credentials and the note about where to change them are both in the output, which is a sensible level of honesty for a development-oriented tool. The change is made in `wrangler.toml` and requires a redeploy, so the password lives in configuration rather than in a database, and the file is in the repository root next to the `wrangler.toml` and the `worker-configuration.d.ts` that the Cloudflare type generation produces. ## Querying over HTTP, over websockets, and through the Studio The query interface is a POST to the `/query` endpoint with a JSON body, and the documented example creates a table: ```bash curl --location --request POST 'https://starbasedb.YOUR-ID-HERE.workers.dev/query' \ --header 'Content-Type: application/json' \ --header 'Authorization: Bearer ABC123' \ --data-raw '{ "sql": "CREATE TABLE IF NOT EXISTS artist(artistid INTEGER PRIMARY KEY, artistname TEXT);" }' ``` Three things about that request are the API. The path is a query endpoint rather than a table endpoint, so the client sends SQL. The body is a JSON document with a `sql` field, which means the transport is a generic command channel rather than a set of table endpoints. And the authorization is a bearer token, so the same token pattern as any other HTTP API. The alternatives are documented beside it. The web socket connections are for low-latency querying, the REST API support is automatically included for interacting with the tables, and the Studio interface is the graphical side of the same database. So a client can be a script, a web application, or a person in a browser, and all three talk to the same object. The data handling around the database is in the feature list as well. Import and export is supported, with the schema and data extracted into a local `.sql`, `.json` or `.csv` file, which is the difference between a database and a demo: a `.sql` dump is how you move the data to something else when you decide to leave. The package metadata shows the implementation choices behind the API. The web framework is Hono at `^4.6.14`, there is a `@libsql/client` dependency for the SQLite side, a `pg` and a `mysql2` and a `mongodb` dependency for the external database connections, `jose` for JSON web token work, `node-sql-parser` for parsing SQL, and `cron-parser` for the scheduled task support. The build is Vite in two passes, one for the client and one for the worker, and the tests are Vitest. ## Templates, external databases, and the roadmap of what was missing Two features make the product more than a database, and the roadmap is a list of what it did not have. The first is bindable microservices via templates, to kickstart development and own the logic, with user authentication given as the example. The `templates/` directory in the repository is where that lives, and the roadmap names two more templates in the same spirit, a JWT authentication template for quickly allowing user auth flows and a row level security template for preventing data access on unauthorized rows. The second is connecting to external databases such as Postgres and MySQL and accessing them with the methods above, which is the escape hatch. A team that already has a Postgres cluster can put the same HTTP interface in front of it and keep the rest of the application unchanged. The roadmap lists, among other things, migrations for applying schema updates in safe sequential order, point in time rollbacks for rolling back the database to any minute in the past 30 days, data replication to scale reads beyond the 1,000 RPS limitation, data syncing between a local source and the database, and scheduled cron tasks to execute code at desired intervals. The read limit is the number to hold on to. A single Durable Object is the unit of both state and writes, and the roadmap acknowledges that reads have to be scaled beyond 1,000 requests per second by replicating, which is the design constraint that any team evaluating this would have to solve. The 30 day point in time rollback is a promise about storage that the roadmap treats as future work rather than as a shipped feature, and the schema migration story, which is the thing every application needs on day two, is in the same list. The README is careful to frame the list as not exhaustive, and it invites bug reports and feature requests through the issue tracker, each of which it says will be reviewed. ## Where StarbaseDB is the wrong tool The limits are structural, and the acquisition makes the first one permanent. The first is that the project is frozen. A repository that will not receive additional changes is fine as a reference and wrong as a dependency. An application built on it inherits the code, the deployment script and the platform coupling, and the first three problems it will hit, migrations, a read limit and a missing backup story, are exactly the ones the roadmap never finished. Adopting it now means becoming its maintainer. The second is the platform. A paid Cloudflare account is required, the Durable Object is the database, and the SQLite file lives inside it. A team that wants a database it can run anywhere, or that has a contractual requirement about where its data lives, is ruled out by the architecture rather than by the cost. The third is the scaling model. One object, one writer, one file, 1,000 requests per second of reads before the roadmap says to replicate. That is a reasonable shape for an application, a service, a small product, and it is a ceiling for anything with a burst of traffic or a large read workload. The alternative is the boring one, and it is worth stating because the temptation with a novel database is to treat the novelty as the point. A conventional Postgres or MySQL server, reachable over the network, has none of these limits and costs an operator. The StarbaseDB approach is interesting where a server is the problem, where the application is small and the team does not want to run a database, and where paying for a managed platform is acceptable. The difference in approach is that StarbaseDB is a product with a fixed shape, an opinionated interface and a roadmap, while a managed relational database is a component with a contract, and the second one is what a team should reach for unless the first one's specific shape is the requirement. ## Conclusion StarbaseDB is worth reading as a design reference, because it shows one coherent answer to a question many teams ask, which is how to put a real relational database behind an HTTP interface without running a server, with the Durable Object holding the file and the Worker holding the protocol. It is the wrong thing to adopt today, since the README states that the repository will not receive any additional changes, so a deployment inherits an unmaintained codebase, and it is the wrong thing for a team that needs a supported path, because the paid Cloudflare account requirement and the platform coupling are not negotiable. If you are evaluating it, read `wrangler.toml` and the `templates/` directory first, because the configuration and the template mechanism are the parts that carried the design, and check the 1,000 RPS read limit on the roadmap, since a data replication plan was never finished. ## FAQ ### How do I deploy a StarbaseDB instance? With `curl https://starbasedb.com/install.sh | bash`, which creates two resources in your Cloudflare account, a Worker and a Durable Object. The Worker serves the network requests and the Durable Object is the SQLite storage, and a paid Cloudflare account is required because SQLite in Durable Objects is not available on the free plan. ### Is StarbaseDB still maintained? No. The README opens with a caution that Outerbase has been acquired by Cloudflare and that the repository will not receive any additional changes. The last release was v0.1.4 on 2025-01-15, and the last push to the repository was on 2026-06-22. ### How do I query a StarbaseDB database? Over HTTPS with a POST to the /query endpoint, a JSON body containing the sql field, and an Authorization: Bearer header. The same database can also be queried over web sockets for lower latency, and a REST API for the tables is included automatically, along with a Studio interface for a browser. ### What does StarbaseDB not do yet? The roadmap lists migrations for schema updates in safe sequential order, a JWT authentication template, a row level security template, point in time rollbacks for the past 30 days, data replication to scale reads beyond the 1,000 RPS limitation, data syncing with a local source, and scheduled cron tasks. ## Sources - [License: AGPL-3.0](https://github.com/outerbase/starbasedb/blob/main/LICENSE) - [outerbase/starbasedb on GitHub](https://github.com/outerbase/starbasedb) - [Project website](https://starbasedb.com) - [README](https://github.com/outerbase/starbasedb/blob/main/README.md) - [Releases](https://github.com/outerbase/starbasedb/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/outerbase-starbasedb