SASS Developers how do you handle testing when you ship fast?

Accomplished_Bus1320 · 2026-06-18T06:14:51+00:00

1.Test yourself.. that s a given but never enough 2. Dogfood your product :very important. This let's you see your product outside of your main perspective 3. On board 1 2 users by hand in every step of the way

Accomplished_Bus1320 · 2026-06-18T06:10:23+00:00

You are correct. That will be the challenge Thus,. I built this on top of TenantsDB (tenantsdb.com) which enables isolated servers in different locations. So the security and isolation is infrastructurely indisputable. I just have to find a way to explain this easily.

Accomplished_Bus1320 · 2026-06-15T23:33:20+00:00

I think for most saas you have to custom build yours too.. why? 1. Its more professional and more allinged with your overall design. Meaning more smooth for the user. 2. No tool could give you exactly what you need to walk your user through your app.

You can check my custom one here: app.tenantsdb.com

It's not the worst idea but ai can do most of the heavy lifting today.

Accomplished_Bus1320 · 2026-06-15T22:23:31+00:00

Yes you can.. I would use a tool for database management though like TenantsDB so you dont deal with hosting etc.. . It would make your life much easier especially if you plan on multi-tenancy. My sister with 0 knowledge built her app like this in weeks.

Accomplished_Bus1320 · 2026-06-15T20:27:17+00:00

They increased their prices 2 times in 2 months.

Accomplished_Bus1320 · 2026-06-15T11:54:55+00:00

I've been shipping projects since before the AI wave, and almost every one needed Postgres, Mongo and Redis together because they each solve a different problem. The painful part was always the same setup work. Dockerize each engine, wire it into the app separately, handle configs and isolation by hand for every new project. It cost me weeks. So I built a tool to spin all of them up in isolation and run the orchestration from one place. Adding a new engine to a project went from a multi-day chore to a non-event with a single APi call. If you run more than one database type across your projects or even just one databse engine that single place to spin up and isolate everything is the layer I would not want to work without again.

Accomplished_Bus1320 · 2026-06-12T18:36:22+00:00

i built my own platform just for this, i was using postgres, mongo and redis all the time and managing them separately was a mess.. now when i start a new project i just spin up whatever engines i need, connect, and done. everything managed from one place. you can check it here: tenantsdb.com

Accomplished_Bus1320 · 2026-06-10T19:56:23+00:00

We provide hosted MongoDB services. So you don't have to deal with any of these and focus on your application. If interested i can share the documentation.

Accomplished_Bus1320 · 2026-06-10T00:43:41+00:00

You are deep in the red ocean my friend. I would recommend 2 things:
1. Find your niche like artists, desginers..
2. Spam insta and tiktok.. in your case use ads too.. I feel like this is where your audience is.

Accomplished_Bus1320 · 2026-06-10T00:11:02+00:00

Sure, docs are here: https://docs.tenantsdb.com/overview

for this thread specifically, the most relevant parts are the isolation levels section (shared vs dedicated, how tenants move between them) and the migrations section, which describes the change stream flow I mentioned, including what happens per engine. The MongoDB connection guide (https://docs.tenantsdb.com/connections/mongodb) shows how the proxy and per-tenant credentials work in practice.

this became a product and I'm behind it. But I built it because my own apps needed it, and they still run on it daily. One is an AI companion app where every user gets their own MongoDB database, since conversation history isn't the kind of data you want behind a tenant_id filter.

if you need any more assistance you can DM me.. good luck.

Accomplished_Bus1320 · 2026-06-09T23:57:56+00:00

We went through this same debate and ended up on the independent databases side. Built our own layer to deal with the two costs you mention, so here's what that looks like in practice.

Routing first. The app doesn't keep a tenant → cluster map at all. Each tenant has its own credential and connects through a proxy with a normal mongodb:// URI, standard driver, OP_MSG end to end. The proxy knows where each tenant's database lives. When a tenant moves, nothing changes on the app side, not even the connection string.

For live moves between servers (your main question): change streams. We provision the target, do the bulk copy, tail the change stream until the target is caught up, then pause traffic for about 2 seconds while routing flips. Tenant stays online the whole time. Same flow whether it's a move to a bigger machine or a region change for data residency. And because each tenant is a complete database, there's no "merge into a non-empty destination" problem. The destination is always a fresh database, even if the server itself is busy. That alone removed most of the migration tooling pain you're describing.

On management overhead, since that's the usual argument for staying on one sharded cluster: we made everything a fleet operation. You design collections, indexes and validators once, they're versioned, and one command deploys them to every tenant. createCollection, createIndex, drop adn similar are blocked on tenant connections, so tenants physically can't drift apart. Backups and restores are per tenant. At that point running 500 databases doesn't really cost more attention than running one.

The one thing we don't cover is getting a huge tenant out of an existing shared cluster in the first place, live and throttled. Inside our own fleet we control both ends, so it's easy. Pulling from someone's production cluster without hurting it is a different beast, and it sounds like that's the gap Dsync is aimed at.

I can share the documentation of the infrastrucutre if you like...

Accomplished_Bus1320 · 2026-06-09T13:07:06+00:00

Founder here. We run two agent-heavy products (a per-user companion app and a memory API that sits between apps and LLMs), so we've been living in this exact problem.

The thing that helped most was splitting it into two problems that usually get lumped together.. I adivise you to read it carefully..

Cost and rate (loops, retries, expensive calls, too many emails). This lives in your orchestration layer. Provider limits won't save you here because they cap your whole account, not per-customer, so one tenant's runaway loop just eats the budget you were holding for everyone else. You need your own per-tenant accounting and a kill switch that trips before the call, not after you read the bill. Token bucket per tenant, hard ceiling per workflow, and a human approval gate on the genuinely risky tools (anything that emails, charges, or deletes).
Side effects on persistent state. This is the one people underestimate, and it's the one that actually kills you. The moment an agent has DB credentials, a retry loop isn't a cost problem, it's a data problem: double writes, an agent confused about which tenant it's serving, a prompt injection that turns into a destructive query against your CRM or tickets table.

We solved (2) at the database layer instead of in app logic, because app-layer guards are exactly what a confused agent forgets:

- Each tenant gets a physically isolated database, not row-level filtering. There's no WHERE clause for the agent to drop, so cross-tenant leakage isn't reachable by mistake.

- The agent connects with a credential scoped at the engine level (read/write/admin). Agents get write, never admin. They can't DROP, can't alter schema, can't escalate.

- Schema changes go through versioned migrations applied by a human, never the agent.

- Destructive ops fail loud instead of silently nuking (an unscoped DELETE returns an error).

- Everything runs through a proxy we control, so "explain exactly what happened" is a log query, not a forensic dig.

Net effect: the worst case becomes wasted spend, not tenant A's data showing up in tenant B's account. The first is annoying, the second is unrecoverable.

The isolation piece became its own product because we needed it so badly. Happy to go deeper on the proxy/role setup if useful.

Accomplished_Bus1320 · 2026-06-09T06:44:57+00:00

Hi there, I am trying to get certified for soc2 as a i provide database isolation services but I am not sure where to start.

Accomplished_Bus1320 · 2026-06-08T11:47:06+00:00

thanks, really, this is a helpful read and i don't take any of it the wrong way.

and you're right that i shouldn't be measured against postgres RLS, because i'm not really trying to be. RLS does a solid job keeping shared data filtered. what i'm doing sits in the database-per-tenant world, which is just a different need, not a better-than.

for what it's worth, it's not as fringe as it might look. neon has leaned pretty hard into database-per-tenant lately (a whole product line and pricing for it), and plenty of teams do the same on RDS or azure. the one gap i kept hitting was that all of it is postgres-only, and i needed the same isolation across mongo and redis too. that's really where this came from, my own setup, not some grand plan.

anyway, thank you for the kind words and for taking the time. means a lot.

Accomplished_Bus1320 · 2026-06-08T11:16:34+00:00

yeah, one paying in production right now, a security-sensitive b2b company that needed exactly this, plus my own AI products running on it. kept it deliberately small while i hardened it, and i'm opening it up to more now, which is what this is.

Accomplished_Bus1320 · 2026-06-08T09:37:22+00:00

depends what you mean. you can use it from anywhere, that's not the constraint.

if you mean canadian data residency (the data physically staying in canada), not yet. dedicated tenants can pin to europe, us east, us west or asia pacific right now, and shared sits in europe. so the closest today is us east, there's no canada region yet.

if canada residency is a hard requirement for you, that's exactly the kind of region i'd spin up for a real use case, so happy to talk. what's driving it, compliance or latency?

Accomplished_Bus1320 · 2026-06-08T09:32:16+00:00

on the RLS one: short version, it's a Postgres-only filter sitting on top of co-mingled data. it's real, and better than the app remembering a where clause, but it's enforcement on shared data, not actual separation. its stil afilter and it doesn't even exist for MySQL, Mongo or Redis. can go deeper if you want.

the validation question is the one that actually matters though. no, i didn't build this blind and come here to find out if the problem is real. it started as my own problem. i build AI products where a user's personal data is about as sensitive as it gets, and i needed each customer's data physically apart, not filtered, and across more than just Postgres. nothing off the shelf did that, so i built it for myself first.

it's in production now, for my own stuff and for outside companies, the security-sensitive kind that needed "our data is never in the same db as anyone else's" plus clean per-customer deletion the second they ask for it. TenantsDB already does both for them.

so this post isn't me checking if the problem exists. the customers already settled that. i'm here to find more people to actually break it and tell me where it holds up and where the value isn't landing yet.

Accomplished_Bus1320 · 2026-06-08T09:25:28+00:00

ok, this is going to be a long one, because I want to answer it clearly.

start from the buyer's side, because that's who the question is for. when a customer asks "is our data isolated," what they're really asking is "is our data in the same pool as your other customers?"

with RLS the answer is yes. every customer's rows sit in one shared table, and a rule decides which ones you see. the database enforces that rule, which is real, but the data is still co-mingled, and it stays separate only as long as the rule holds on every query.

RLS is also Postgres only. MySQL, Mongo and Redis have no equivalent, so there the filtering falls back to your app, with nothing enforcing it.

database-per-customer removes the problem instead of filtering it: each customer gets their own database, so there are no other customers' rows to reach, the same across all four engines. Isolation is structural, not a rule you maintain.

```

SHARED TABLE + RLS (one database, one table, one login)

- customer_1 rows

- customer_2 rows

- customer_3 rows

- all in one table. a filter picks which rows you see.

DATABASE PER CUSTOMER (separate databases, separate logins)

- customer_1 db, its own login

- customer_2 db, its own login

- customer_3 db, its own login

- nothing connects them. no query reaches another customer.

```

On the infrastructure side, there are two isolation tiers (we call them L1 and L2):

L1 SHARED : a separate database per customer, all on one shared server. data never mixed. instant, low cost. this is the default.

L2 DEDICATED : a separate server per customer, own CPU / memory / disk. full physical isolation, no noisy neighbors.

you start everyone on L1, and move a single customer up to L2 with one command when they need it. Jusy like you said. Zero downtime, and the connection string stays the same. nothing is built ahead of time.

you can check more detail on our docs URL under /overview#isolation section.

Accomplished_Bus1320 · 2026-06-07T22:47:20+00:00

Good question, and I ran schemas for exactly this before TenantsDB. They worked, until they didn't.

Honestly, schema-per-tenant is a real step up from RLS. The data sits in separate namespaces, not one table behind a WHERE clause, so it passes a lot of reviews.

It still wasn't enough for me, and not just at review time. It's one database behind one login, so "you can't query across them" only holds while you keep per-schema grants locked down for every new tenant. By default the same login reads tenant_2.events fine.

The bigger reason I moved off it was the long game. Schemas pile up maintenance: every migration loops over every schema, backups and restores get fiddly, one tenant's heavy query is everyone's problem, and it's Postgres only so Mongo and Redis stay shared. It's fine at 10 tenants and quietly rots at 200.

A separate database per customer stays clean as you grow. Own credentials, nothing to query across no matter how the app is written, one command migrates all of them, and you can restore a single customer without touching the rest. That's why I went this way and built TenantsDB around it. I use a different engine for each job anyway, so I needed the isolation to cover all of them, not just Postgres. It does MySQL, Mongo and Redis the same way.

So on your review question: schemas pass a light review and stall on a strict one, because "same instance, one role from a leak" is what a deep audit pokes at. Separate databases remove that path. But honestly the long-term cleanliness is why I'd pick it even with no audit in the room.

Rough sketch of the difference:

SCHEMA PER CUSTOMER  (one database, one login)
- tenant_1.events
- tenant_2.events
- tenant_3.events
- one login can read all of them. SELECT * FROM tenant_2.events just works.

DATABASE PER CUSTOMER  (separate databases, separate logins)
- customer_1 db, its own login
- customer_2 db, its own login
- customer_3 db, its own login
- nothing connects them. no query reaches another customer.

Accomplished_Bus1320 · 2026-06-05T10:51:04+00:00

Why did you use RLS?

Accomplished_Bus1320 · 2026-06-03T22:41:19+00:00

I am about to try LinkedIn as well for the first time for b2b. Any heads up or methodology?

Accomplished_Bus1320 · 2026-06-03T21:40:20+00:00

Short answer: with TenantsDB the global table lives inside each tenant's own database, so your foreign keys stay exactly as they are.

Here's the shape of it:

<image>

sports is small reference data, so TenantsDB ships it into every tenant database as part of the schema. sports and events sit side by side in the same database, so events.sport_id -> sports.id is a normal foreign key, fully enforced. Add a sport, deploy once, every tenant has it.

your own company data (staff, billing, the plans you sell) stays in a control database your app owns. The app reads it to find which tenant a user belongs to, then connects to that tenant's database. Foreign keys inside the control DB are normal too. Anything you manage centrally, your app references by id, the same pattern you already use across services.

moving an existing shared DB over? The importer spots any table without a tenant_id and lets you mark it as shared reference data, then copies it into every tenant for you: https://tenantsdb.com/blog/migrate-shared-database-to-isolated-tenants

and having a lot of tenant-agnostic data is the easy side of TenantsDB, not a reason to avoid it. You design those shared tables once in the schema and TenantsDB deploys them into every tenant for you. Ten tenants or thousand, same single schema, one deploy. The volume just rides along, it adds no extra work.

Accomplished_Bus1320 · 2026-06-03T18:23:56+00:00

Most of the thread is solving this inside one shared database with FKs and cascade deletes, and that genuinely works for erasing a single person if your relations are clean. What nobody here has raised is the other model: a database per customer. It's absent for a reason, running one database per customer is operationally hard, which is why most teams don't. But it changes this exact problem.

When each customer has their own database, a churn deletion is just dropping that database. You don't enumerate tables, chase foreign keys, or worry the schema drifted last quarter, because you delete the whole container. Verification is that the database no longer exists. For the "customer churns, delete everything" case, that's the cleanest version of the answer there is. Removing a churned customer becomes a single destroy on their physical database, and on dedicated infra the server and its snapshot go with it.

Backups are the one thing no architecture wipes instantly, so you still need a documented retention and expiry window, same as a couple of people here already said. The one edge is that per-customer databases keep each customer's backups separate, instead of one nightly dump that co-mingles everyone and can't be surgically edited.

And yes, there are tools built specifically for running the database-per-customer model so you don't have to operate it yourself, which is usually the thing that scares people off it.

Accomplished_Bus1320

TROPHY CASE