> ## Documentation Index
> Fetch the complete documentation index at: https://docs.larksh.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Database routing

> One database by default, or many when you need them

Every Lark project starts with a single database called `default`. When your connection URL points at the project and nothing else, that's where your data goes. For most apps that's all you ever need, and it's how Firebase Realtime Database already works: one project, one database, one JSON tree.

## The default approach

Point your `databaseURL` at your project and you're talking to the `default` database:

```javascript theme={null}
const config = {
  databaseURL: 'https://your-project.larkdb.net'
};
const db = firebase.initializeApp(config).database();

db.ref('room-abc123/players/alice').set({ name: 'Alice' });
```

There's no database name in that URL, so Lark uses `default`. `https://your-project.larkdb.net` is identical to `https://default--your-project.larkdb.net`; the first is just shorthand for the second.

If you're migrating from Firebase, this is the whole story. Change `your-project.firebaseio.com` to `your-project.larkdb.net`, keep every path, rule, and query exactly as they were, and your data lands in one database the same way it did before. See [Migrating from Firebase](/firebase/migration) for the full walkthrough.

A single database handles a lot. If your app has one logical dataset, a moderate number of rooms, or write rates that one tree can absorb, leave it here.

## Multiple databases

Firebase Realtime Database caps you at a handful of database instances, so apps with many independent data silos (game rooms, workspaces, documents, sessions) end up packing them all into one database under path prefixes:

```
your-project.firebaseio.com/
  room-abc123/
    players/...
    chat/...
  room-def456/
    players/...
    chat/...
  ... (thousands more)
```

Every room then shares one database, one set of write locks, and one security rules tree. At scale, that contention becomes a bottleneck.

Lark removes the cap. With **Auto Create** enabled in your project settings, a database springs into existence the first time a client connects to it, so each room, workspace, or document can live in its own isolated database. You select the database by putting its name in the subdomain, ahead of your project ID and separated by `--`:

```
https://room-abc123--your-project.larkdb.net
```

The `room-abc123` before the `--` is the database name. Lark routes this connection to a database called `room-abc123` inside your project. Your client code keeps writing to the same paths:

```javascript theme={null}
const roomId = 'room-abc123';
const config = {
  databaseURL: `https://${roomId}--your-project.larkdb.net`
};
const db = firebase.initializeApp(config).database();

// Same paths as before, the room prefix is still there
db.ref(`${roomId}/players/alice`).set({ name: 'Alice' });
```

That makes the first path segment (`room-abc123`) redundant, since it matches the database name. Leaving it in costs you nothing and keeps your paths, security rules, and data model identical to what you ran on Firebase. The only thing that changes is the connection URL, usually one line where you build the config.

Inside the `room-abc123` database, the data looks like:

```
room-abc123/
  players/
    alice/...
  chat/...
```

Each room gets its own write locks and its own rules evaluation, with no cross-room contention. For apps with thousands of concurrent rooms and high write rates, that isolation is what keeps writes fast as you grow.

## Which one to use

Stay on the default database when one tree can hold everything comfortably. Move to multiple databases when you have many independent silos that would otherwise fight over the same locks, or when you want each tenant's data fully isolated.

You can switch incrementally. Create a few databases by hand in the dashboard, point test clients at their subdomain URLs, and confirm everything works before shifting production traffic over.

<Tip>
  Enable **Auto Create** in your project **Settings** before pointing clients at new database subdomains, so Lark provisions each one on first connection.
</Tip>