Skip to content
AOZUMIDB
Sign inOpen AOZUMI DB

Experimental, by invite

The database that sleeps when your app does.

Every app gets its own SQLite database, served over HTTPS. Create it in a click and connect with the client you already use. When nobody's asking, it's just a file.

Open AOZUMI DBSee the code
Works with
  • @libsql/client
  • Drizzle
  • plain HTTP
Every drawer is one app's database. Closed, it's just a file. Click one to send it a query.

From a click to your first query.

AOZUMI DB speaks the same HTTP protocol as libSQL, so @libsql/client, Drizzle and anything built on them connect without changes.

  1. Create it

    In your app's Settings, open Databases and choose Create SQLite database.

  2. AOZUMI wires it up

    Production gets AOZUMI_DB_URL and AOZUMI_DB_TOKEN. The token opens this one database and nothing else.

  3. Deploy

    Redeploy, and your app is talking to its database.

import { createClient } from "@libsql/client";

const db = createClient({
  url: process.env.AOZUMI_DB_URL!,
  authToken: process.env.AOZUMI_DB_TOKEN,
});

await db.execute({
  sql: "insert into notes (body) values (?)",
  args: ["hello"],
});
const { rows } = await db.execute("select * from notes");

Writes wait their turn.

SQLite takes one write at a time. Plain SQLite turns the next writer away with “database is locked”. AOZUMI DB hands every write a number and runs them in order, while reads carry on.

Plain SQLiteOne writer gets in. The next gets an error, and your app has to try again.
AOZUMI DBEvery write takes a number and runs in order, and reads never stand in line.

In our benchmark, with 32 clients writing at the same time, AOZUMI DB turned no write away. A median write took 1.6 ms with 1,000 arriving every second.

37,000 reads a second, on a laptop.

We measure with YCSB, the standard benchmark for databases you reach over a network, on the kind of machine you have, not a tuned server.

  1. 37,436Reads onlyp99 2.0 ms
  2. 34,27295% readsp99 2.6 ms
  3. 30,442Newest rowsp99 4.7 ms
  4. 13,512Half updatesp99 9.3 ms
  5. 12,376Read, then updatep99 8.2 ms
  6. 4,592Short scansp99 17.8 ms
Bars in operations a second; one block is 2,500. Higher is better. YCSB on 26 October 2026: 100,000 rows, 32 clients, 10 seconds a workload, the median of two runs, clients and server sharing one 6-core laptop.

What comes with every database.

No instance to size, no connection pool to tune, no server to patch. Here's the whole list, the way SQLite would print it.

What comes with every AOZUMI DB database
featurewhat_you_get
limits256 MB, 5 s a statement, 100 requests a second
tokenseach one opens one database, nothing else
guard railsATTACH, VACUUM INTO and risky pragmas refused
when idlejust a file; no instance of yours to keep running
per workspaceup to 3 while it's experimental
backupsnot yet: point-in-time restore is in the server, not the console

Questions, answered.

How do I get it?

Sign in with your AOZUMI account and open AOZUMI DB. While it's experimental, a workspace asks for access there and we switch it on. Once it's on, you can create databases in AOZUMI DB, or for an app from its Settings, under Databases.

Is it really SQLite?

It speaks SQLite's SQL and keeps each database as a SQLite file. AOZUMI's own server, written in Rust, serves it over HTTPS.

Which clients work?

Anything that speaks libSQL's HTTP protocol: @libsql/client, Drizzle on top of it, or plain HTTP with a bearer token.

Is my data backed up?

Not yet. While it's experimental there are no backups, so keep a copy of anything you can't lose. Point-in-time restore is already built into the server and comes to the console later.

What happens when I delete my app?

Its databases are deleted with it, and so are the AOZUMI_DB_URL and AOZUMI_DB_TOKEN variables AOZUMI set.

Give your next app a database.

AOZUMI DB is experimental and by invite. Run this to sign in and ask for access for your workspace.

insert into early_access (workspace)
values ('your-workspace');Run it

Running it opens AOZUMI DB with your AOZUMI account.