Skip to main content
Firebase Realtime Database limits you to a handful of database instances. If you’re building something with thousands of independent data silos — game rooms, workspaces, documents, sessions — you end up stuffing them all into one giant database under different path prefixes. 
your-project.firebaseio.com/
  room-abc123/
    players/...
    chat/...
  room-def456/
    players/...
    chat/...
  room-ghi789/
    players/...
    chat/...
  ... (thousands more)
This works, but it means every room shares the same database, the same write locks, and the same security rules tree. As you scale, this becomes a bottleneck. Lark can create databases on the fly. With Auto Create enabled, a new database spins up the moment a client connects to it — no provisioning, no limits on how many you can have. Each game room, workspace, or document can live in its own isolated database. The question is: how do you get there from your existing Firebase setup? You have three options.

​
Option 1: Database-in-subdomain routing

Change your connection URL to put the room/workspace ID in the subdomain. This tells Lark to route each connection to its own database — but your client code and security rules stay exactly the same. Firebase (before): 
https://your-project.firebaseio.com
Lark (after): 
https://room-abc123--your-project.larkdb.net
The room-abc123-- prefix before -- 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: 
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('room-abc123/players/alice').set({ name: 'Alice' });
The first path segment (room-abc123) is technically redundant — it matches the database name — but that’s the point. Your paths, your security rules, your entire data model stays identical. The only change is the connection URL. Inside the room-abc123 database, the data looks like: 
room-abc123/
  players/
    alice/...
  chat/...
Yes, there’s a “wasted” level in the tree. That’s the tradeoff for zero code and rule changes. When to use this: When you want separate databases with no changes to your client code paths or security rules. You just need to vary the connection URL per room, which typically means one line of code where you construct the Firebase config.

​
Option 2: Use first path segment as database

If you don’t want to change your connection URLs at all, enable Use First Path as Database in your project settings. Lark will look at the first segment of every path and route it to a database with that name — and strip that segment from the path. Your connection URL points at the project, just like Firebase: 
const config = {
  databaseURL: 'https://your-project.larkdb.net'
};
const db = firebase.initializeApp(config).database();

// Client writes to 'room-abc123/players/alice' — same as before
db.ref('room-abc123/players/alice').set({ name: 'Alice' });
Lark strips the first path segment (room-abc123) and uses it as the database name. The write lands at /players/alice in a database called room-abc123. Your client code stays identical to what you had on Firebase. No connection URL changes, no path changes. The routing happens transparently on the server. When to use this: When you want the benefits of separate databases without changing any client code or connection URLs. This is the fastest migration path.
Because the first path segment is stripped, your security rules need to be adjusted. A rule that was at rules/$roomId/players/$uid becomes rules/players/$uid — the $roomId level is gone because each database gets its own copy of the rules, scoped to the data inside it.

​
Option 3: Keep everything in one database

You don’t have to split anything. Lark is happy to run a single large database with all your data in it, just like Firebase did. 
const config = {
  databaseURL: 'https://your-project.larkdb.net'
};
const db = firebase.initializeApp(config).database();

// Same paths as Firebase, same database, same everything
db.ref('room-abc123/players/alice').set({ name: 'Alice' });
No code changes, no rule changes, no routing to think about. Your data layout stays exactly as it was on Firebase. When to use this: When you’re migrating from Firebase and want zero changes beyond the connection URL. This works fine and is a perfectly valid approach.

​
Comparing the three options

Option 1: SubdomainOption 2: First pathOption 3: One database
Connection URL changesYes — include room ID in subdomainNoNo
Client code changesNo — same pathsNo — same pathsNo
Security rules changesNo — same structureYes — remove the top-level wildcardNo
Separate databasesYesYesNo
Write contentionPer-room (isolated)Per-room (isolated)Shared across all rooms
Data structureRedundant first segmentClean (first segment stripped)Same as Firebase
For apps with a small number of rooms or low write frequency, a single database (Option 3) works fine. For apps with thousands of concurrent rooms and high write rates, separate databases (Options 1 or 2) give you better performance and cleaner isolation.

​
Setting it up

  1. In the Lark dashboard, go to your project’s Settings.
  2. Enable Auto Create so databases are created on first connection.
  3. If using Option 2, enable Use First Path as Database.
  4. If using Option 1, update your client code to include the database name in the subdomain.
  5. If using Option 2, update your security rules to remove the top-level path segment.
You can test this incrementally. Create a few databases manually in the dashboard, point some test clients at them, and verify everything works before enabling Auto Create for production traffic.