Building a Scalable SaaS Backend in 10 Minutes

The SaaS Boilerplate Problem

If you have ever tried to build a multi-tenant application, you know the pain. Before you can write a single line of business logic, you have to make a dozen critical infrastructure decisions. Do you use a separate database for each customer? do you put everyone in one big table with a tenant_id column? How do you handle migrations without breaking the data for your biggest client?

This setup process usually takes weeks. With TenantsDB, we reduced it to minutes. In this tutorial, we will build the backend for a simple Project Management SaaS that is fully isolated and ready to scale from day one.

Step 1: Define Your Schema

We start by creating a single file named schema.oql. This will define the data structure for every tenant in your system. We will create a Project table and a Task table.

SQL

// schema.oql

:CREATE TABLE Project WITH
  id: UUID PRIMARY KEY,
  name: STRING UNIQUE,
  status: STRING DEFAULT "active",
  created_at: TIMESTAMP DEFAULT CURRENT_TIMESTAMP

:CREATE TABLE Task WITH
  id: UUID PRIMARY KEY,
  project_id: UUID REFERENCES Project(id),
  title: STRING NOT NULL,
  is_completed: BOOLEAN DEFAULT false

Notice that we are not writing SQL. We are writing OmniQL. This definition will automatically be compiled into PostgreSQL tables and indices when we deploy.

Step 2: Initialize the Platform

Next, we use the TenantsDB CLI to initialize our project. This creates the necessary configuration to connect your local environment to the cloud platform.

Bash

$ tdb init --name my-saas-app
> Project initialized. 
> Endpoint: https://api.tenantsdb.com/v1/my-saas-app

Step 3: Onboard Your First Customer

Now comes the magic. In a traditional setup, onboarding a new customer (Tenant) requires running scripts to create schemas or users. With TenantsDB, it is a simple API call.

Here is how you create a new workspace for a customer named "Acme Corp" using our Node.js SDK:

import { TenantsDB } from '@tenantsdb/sdk';

const client = new TenantsDB(process.env.API_KEY);

// This creates a dedicated, isolated database schema instantly
const workspace = await client.workspaces.create({
  slug: "acme_corp",
  tier: "standard"
});

console.log(`Created workspace: ${workspace.id}`);

Step 4: Read and Write Data

Once the workspace exists, you can interact with it immediately. The API automatically routes your queries to the correct isolated schema based on the workspace ID. You never have to worry about accidentally leaking data between customers.

// Switch context to Acme Corp
const db = client.use("acme_corp");

// Create a project for them
await db.execute(`
  :INSERT INTO Project VALUES (uuid(), "Website Redesign", "active", now())
`);

// Fetch their projects
const projects = await db.execute(`
  :SELECT * FROM Project WHERE status = "active"
`);

Conclusion

In less than fifty lines of code, we have deployed a fully sharded, multi-tenant backend. We did not have to configure Docker, we did not have to manage connection pools, and we did not have to write complex WHERE tenant_id = ? clauses in every query. TenantsDB handles the isolation and scaling, allowing you to focus entirely on building features.