For years, multi-tenant applications have largely followed the same pattern:
One database. Many customers. One giant collection of tables.
Every query carries a tenant_id. Every table needs isolation logic. Every developer has to remember to scope every query correctly.
It works.
But what if the database itself could become the tenant boundary?
That’s one of the architectures we’re exploring with DCubix SQLite.
A database for every user, workspace, or resource
Say you have:
- 100,000 users
- 10,000 workspaces
- thousands of projects
Instead of putting everything into one database:
PostgreSQL
├── users
├── workspaces
├── projects
├── orders
└── ...
you could provision an isolated SQLite database for each independent unit:
Workspace A → SQLite A
Workspace B → SQLite B
Workspace C → SQLite C
Workspace D → SQLite D
Authentication can remain completely centralized.
Auth
│
▼
Identify workspace
│
▼
Database ID
┌────┼────┐
▼ ▼ ▼
DB A DB B DB C
Once the request is authorized, subsequent database operations can go directly to that workspace’s isolated database.
No tenant_id required. No accidental cross-tenant joins. No enormous shared tenant table.
The database itself becomes part of your isolation model.
And the application doesn’t need to run on our DCubix Cloud
Your application can run wherever you want:
- AWS
- GCP
- Azure
- A VPS
- Cloudflare Workers
- Your own infrastructure
And your application simply connects to its database over HTTPS.
There is no database connection pool to maintain. No persistent database connections. No database driver running inside every serverless invocation. No need to manage networking between your compute and database. A request can simply arrive, execute its SQL query, and disappear.
For applications already running at the edge, this can make the database access path particularly attractive: compute and database access can stay close to Cloudflare’s network rather than requiring every request to traverse the public internet to a centralized database server.
The result is a database architecture designed for the way modern applications are increasingly being built: serverless, distributed and highly dynamic.
What this enables
1. Database-per-workspace
A project management application could give every workspace its own database. Each workspace gets its own data boundary.
2. Database-per-user
For applications where users don’t share data, you could go even further.
User A → DB A
User B → DB B
User C → DB C
This could be particularly interesting for:
- personal productivity apps
- AI agents
- personal CRMs
- research tools
- knowledge management
- user-specific application state
3. Database-per-project
You don’t even have to think in terms of users. A database could represent a resource.
Organization
│
├── Project A → DB A
├── Project B → DB B
├── Project C → DB C
└── Project D → DB D
The database becomes a natural lifecycle boundary.
Create resource → create database.
Delete resource → delete database.
The surprising part: you don’t pay per database
This is one of the things we really like about this architecture.
With DCubix, creating an additional isolated database doesn’t introduce a separate per-database charge. Our pricing is based on actual usage: data stored + rows read + rows written + HTTP requests.
So if an application has 1 database, or 10,000 small databases, the architectural decision to isolate data doesn’t itself become a line item. You pay for the data and work you’re actually using. That changes the economics of multi-tenancy.
Instead of asking:
“Can we afford a database for every workspace?”
you can start asking:
“Would a separate database make the application better?”
Security becomes simpler
This doesn’t eliminate the need for proper authorization. But it gives developers a much stronger primitive.
Consider a traditional multi-tenant query:
SELECT *
FROM orders
WHERE tenant_id = ?
Every query needs to be correctly scoped.
With database-per-tenant:
SELECT * FROM orders;
There simply aren’t other tenants’ orders in that database.
The application still needs to authenticate the user and authorize access to the database. But once the database has been selected, the data boundary sits at the database level rather than being merely another column in a shared table.
Performance isolation becomes possible too
A noisy tenant in a shared database can compete for resources with everyone else.
With independent databases:
Tenant A → DB A
Tenant B → DB B
their workloads are separated at the database level.
For applications where tenants are naturally independent, this creates an attractive architecture: small data sets + isolated databases + independent workloads.
SQLite is particularly interesting here because you don’t need a heavyweight database server for every tenant.
Data residency becomes an architectural primitive
There’s another direction this can take.
If different databases can have different placement or residency requirements, provisioning can become part of your application’s architecture.
Conceptually:
Workspace A → EU database
Workspace B → US database
Your authentication layer remains global. Your application remains global. But the actual data can be associated with the appropriate database configuration.
And this is why we’re building SQLite over HTTP
We’re not trying to convince everyone to replace PostgreSQL. That’s not the point.
The interesting question is:
What kinds of applications become possible when a database can be created as easily as an API resource?
A database shouldn’t always have to be a giant shared piece of infrastructure.
Sometimes the natural architecture is:
User → Database
Workspace → Database
Project → Database
Agent → Database
Resource → Database
And if that database can be accessed through HTTP, your compute and your data don’t need to live in the same infrastructure.
We’re still early
DCubix SQLite is currently in beta.
We’re still building the platform, testing the limits, and figuring out where this architecture creates the most value.
But we think database-per-tenant, database-per-workspace, and database-per-resource could become a powerful alternative to the traditional shared-database model.
And we’re only getting started.
Follow us on LinkedIn to stay updated as we build.
For a better world. For a better future.