DEV Community: Ashif E.K

Multi-Tenant SaaS: Creating a Schema Is Easy. Keeping Every Request in the Right One Is Hard.

Ashif E.K — Tue, 13 Oct 2026 07:45:47 +0000

When I started working on a multi-tenant SaaS architecture, one of the interesting challenges wasn't creating separate schemas in PostgreSQL.

It was making sure every request consistently used the correct tenant's data.

That sounds simple until you think about what happens when authentication, middleware, database sessions, and background jobs all need to agree on the same tenant context.

I'm working with a multi-service architecture in WorkPilot AI, using FastAPI and PostgreSQL with schema-based tenant isolation. Here's an architectural lesson I've come to appreciate.

Creating tenant schemas is only the beginning

Imagine a SaaS application serving two organizations:

Organization A uses tenant_alpha.
Organization B uses tenant_beta.

Both organizations share the same PostgreSQL database, but their application data lives in separate schemas.

The architecture might look like this:

Incoming Request
      |
      v
Authentication
      |
      v
Resolve Tenant
      |
      v
Validate Access
      |
      v
Set Database Context
      |
      v
Execute Tenant-Scoped Query

The important question isn't whether those schemas exist.

It's whether the entire request lifecycle consistently respects the tenant boundary.

Where things can go wrong

1. Trusting the wrong tenant identifier

A request might contain a tenant ID, a subdomain, or a tenant-related claim in a JWT.

But receiving a tenant identifier doesn't automatically make it trustworthy.

The application must validate the tenant against a trusted source and verify that the authenticated user is authorized to access it.

A client must never be able to access another organization's data simply by changing a request parameter.

2. Setting tenant context in middleware isn't enough

Middleware can resolve the tenant and make the context available to downstream code.

However, that context must also be applied correctly to the database session used for the request.

If a query executes against the wrong schema, tenant resolution may appear to work while data isolation fails.

This is why tenant resolution, authorization, and database session configuration should be treated as separate responsibilities.

3. Database connection pooling introduces another consideration

Applications commonly reuse database connections to avoid opening a new connection for every request.

That's useful for performance, but it means database session state deserves careful attention.

If tenant-specific session settings persist unexpectedly when a connection is reused, a later request could execute with the wrong context.

With PostgreSQL, transaction-scoped settings and properly managed transaction boundaries can help prevent this class of problem. The exact approach depends on the database driver, connection pool, and transaction management strategy.

4. Background jobs don't automatically inherit request context

Consider a task queued to Celery or another background worker.

The original HTTP request might have resolved the tenant correctly, but the worker runs in a separate execution context.

The job needs an explicit, validated tenant reference and must establish its own database context before accessing tenant-specific data.

Never assume that request middleware has configured a background worker's database session.

What I would focus on

For a schema-based multi-tenant system, I would pay particular attention to these boundaries:

Authentication: Establish who the user is.
Tenant resolution: Determine which organization the request targets.
Authorization: Verify that the user can access that organization.
Database isolation: Ensure queries execute within the intended tenant context.
Session lifecycle: Prevent tenant state from leaking across requests.
Background processing: Re-establish tenant context in workers.
Testing: Verify that one tenant cannot read or modify another tenant's records.

I'd also test failure cases deliberately: missing tenant context, invalid tenant identifiers, unauthorized organization access, and reused database connections.

A system that works for the happy path isn't necessarily a system that preserves tenant isolation under failure.

One distinction worth remembering

Schema-based multi-tenancy is an architectural strategy, not a complete security guarantee.

Separate schemas can improve logical separation and organization, but the application still needs reliable authorization, safe database configuration, controlled migrations, and tests that verify isolation.

The database structure alone doesn't enforce every security boundary.

My takeaway

The difficult part of multi-tenancy isn't creating a schema for every organization.

It's preserving the correct tenant context across every layer that touches the data.

Middleware, authentication, database sessions, connection pools, and background workers must work together. If even one layer assumes another layer has already handled tenant isolation, that assumption deserves to be tested.

I'm still learning from building these systems, and this is one of the areas where thinking beyond the happy path makes a real difference.

For developers building multi-tenant SaaS applications: how do you manage tenant context across database sessions and background jobs?

A Logged-In User Shouldn't Have to Introduce Themselves to Your Chatbot

Ashif E.K — Mon, 12 Oct 2026 17:20:26 +0000

While working on an employee management platform, I ran into a problem that looked small at first.

The user was already logged in.

The application knew who they were. Their role was available. Their session was active.

Yet, when they opened the AI assistant and asked about their attendance or leave, the assistant could still ask them to provide their employee ID or name.

Something wasn't connected properly.

The problem wasn't the chatbot's intelligence

My first instinct was to think about how to improve the assistant's instructions.

But the more useful question was: why does the assistant need to ask for information that the application already has?

A chatbot prompt can tell an AI how to behave. It cannot magically give the backend the correct identity, permissions, or database context.

If those things aren't connected properly, even a well-written prompt can produce a frustrating experience.

Three things I started separating

1. Identity: Who is making this request?

This should come from the authenticated session or a verified access token.

The user shouldn't need to introduce themselves every time they open a feature.

2. Authorization: What are they allowed to do?

Knowing someone's identity doesn't mean they can access every resource.

An employee might be allowed to view their own attendance, while an HR administrator may have permission to manage attendance records for multiple employees.

The backend must enforce these permissions. The AI should not decide them on its own.

3. Data scope: Which records should this request use?

Even after identifying the user and checking their permissions, the application must scope the database query correctly.

For example, an employee asking about their leave balance should get data associated with their authenticated employee record—not whichever employee ID happens to appear in a chat message.

These are separate responsibilities. Treating them as one problem creates confusing behavior and can introduce security vulnerabilities.

What the backend should do instead

A simplified version of the flow looks like this:

async def get_my_leave_balance(
    current_user,
    db,
):
    employee = await get_employee_for_user(
        db=db,
        user_id=current_user.id,
    )

    if employee is None:
        raise EmployeeNotFoundError()

    return await get_leave_balance(
        db=db,
        employee_id=employee.id,
    )

This is illustrative pseudocode; the helper functions and exception would need to be implemented in the actual application.

The important part is where employee.id comes from: a trusted relationship between the authenticated user and their employee record.

The client or chatbot shouldn't be able to choose another employee's identity just by supplying a different ID.

For administrative actions, the backend would also need to verify the user's role and the specific permission required for that operation.

The bigger lesson

Building AI features has made one thing particularly clear to me: adding an AI model doesn't remove the need for good backend architecture.

Authentication, authorization, data access, and business rules still need to work correctly.

The AI can help interpret a request. The application must determine whose request it is, what that person can access, and which data the answer should be based on.

That distinction matters even more when the assistant can do things rather than simply answer questions.

I'm still learning, building, and finding these gaps in real projects. And sometimes, the most useful engineering lesson comes from a feature that technically works but still behaves in a way that makes no sense to the user.

My takeaway: Don't ask the user to repeat information your system should already know. Pass the right context through the right layers, and enforce the important rules on the backend.

I'd be interested to hear how other developers handle authenticated user context in AI assistants, especially in applications with multiple roles and organizations.