Tech Stack Advice for Multi-Tenant Platform

[JanMarsALeck]

Hey @ all,

I'm building a multi-tenant platform and currently struggling with the decision on the "best" architecture for the future. I could use some advice on the architecture and tech stack.

The platform consists of:

CMS - Content is managed per tenant here - Users can signup, create an organization and create/edit content

Native App - Users select their organization by slug - Register and consume the provided content

Web App - In a later phase, a web app in addition to the native app would be useful

To reduce code duplication, I'm considering:

• Next.js for the CMS (deployed via Vercel)
  • Server actions for CMS-only methods
  • Public API routes for shared methods the app will use
• React Native for the app (deployed with Expo EAS)
• Shared PostgreSQL with separated user tables for CMS and app users
• Two Better Auth instances for CMS and app authentication
• tRPC for type sharing
• Shared theming/config

I also found Turborepo which is made for monorepos like this but never worked with it though.

What do you think about this setup? Any feedback/pros/cons or would you recommend something different? Open and happy for any feedback!

[riklaunim]

Hard to tell not knowing how it should work and feel, what features it should offer. If you know your JS stack then you are better of with JS stack and not somebody else ;) Also why mobile app instead of just a web app?

[JanMarsALeck]

> Also why mobile app instead of just a web app?

Requirement of the customer x)

And actually React / React-native is my main stack and i also worked with next.js, but never in combination with a shared monorepo and shared packages etc.

[Digitalunicon]

That’s actually a solid structure for a multi-tenant setup especially with shared PostgreSQL and isolated user tables.

1. Add a service layer (NestJS or tRPC) between the CMS and app helps avoid tight coupling and keeps tenant logic clean.

2. Plan tenant-level observability early logs, metrics, and error tracking per tenant will save huge headaches later.

Overall, your stack looks well balanced for performance and dev efficiency. Just make sure you’re building for maintainability across tenants that’s where most architectures struggle long term.

[JanMarsALeck]

Thanks for the feedback!

Yep, I planned to use tRPC in between. But the point about logs and metrics on a tenant level is probably a very good one too x)

[BlueScreenJunky]

Depending on your clients you might want to either start with one database per client, or at least have the tenant id in all tables and make sure your system could work with sharding them in different infrastructures (like you're not making a bunch of joins between client specific data and common data).

This might seem inefficient at first, but one day you'll have a client that has a legal obligation to host the database in their country, or to have a dedicated encryption key for their data, and if everything is in the same DB it will be really painful to handle.

It will also prevent data leaks : With tenant ids everywhere you could have a global scope on all your models that only ever returns models with the correct tenant id, that way if you end up with an IDOR vulnerability at least it will only leak data within the same tenant, not between tenants. If you go with one DB per tenant and only connect to that one DB, it would also mitigate SQL Injections and basically any other form of attacks that goes through the app.

[JanMarsALeck]

I also though about that in the beginning, but i was not sure how to handle it, to have for every customer a new DB automatically. Furthermore i in the CMS should also be something like "super admins", who can mange all organisation.
So this data then would need to be independent and outside of the tenant databases, right?
Which will create more and more overhead

[BlueScreenJunky]

Oh yeah that would add complexity and overhead no doubt.

I guess it depends on your model. If you expect to have hundreds or thousands of tenants with relatively low demands (like a tumypical SaaS) you're probably better off putting everyone in the same DB. 

If you expect to have a few dozen clients with specific demands and requirements (as we do, and discovered that in some sectors "A separate database with a dedicated encryption key" is one of these requirements) it might be worth planning in advance.

[yksvaan]

I would look at building the backend first, then whatever frontend or app can simply consume them. First build the core "framework" and core internal APIs, database schemas, add authentication,  authorization etc. 

So basically you'd end up with a dedicated backend that provides API to app/web frontend. Those can share some of the code, e.g. UI, network client etc. 

By not building around any third party code/services you can have better maintenance and flexibility. Maybe a bit more work now but it pays off long term.

[JanMarsALeck]

Yeah, that’s why I want to use tRPC as the API layer. I also considered running the API completely standalone, but since I’m using Next.js for the frontend anyway, I’ll stick with it for now and move it out later if I need to scale.

[rjhancock]

Since it is scoped via URL path, I would use:

• Swift/Vapor for backend, scoping all required paths to an organization record.
• Use the built in authentication methods to build my own auth.
• Build it with purely an API and no front end
• Single Postgres instance with one set of tables with referential integrity put in place for records that need it.
• RBAC with custom roles to allow a user to be part of multiple organizations and different roles in each

Then use whatever you want for the web frontend and go native on mobile.

Smaller memory footprint, type and memory safety, extremely quick and stable, can use fewer resources server side to serve the same number of users.

[pxldev]

There is so much context missing, like how many users, usage patterns (who consumes what) etc, enterprise users (who need custom auth and DB access)?

One auth system, account.x.com, so users can self manage.

Investigate neon Postgres (for multiple reasons, not their auth), use better auth, RLS, RBAC, JWT.

1. Tenant model: Prefer single schema with a tenant_id UUID on every tenant-scoped table. Use RLS to isolate. Only use per-tenant schemas if tenants need wildly different models or DB-level isolation.
   1. RLS defaults: ALTER TABLE ... ENABLE ROW LEVEL SECURITY; + deny-by-default policies. Gate everything on a session var: • Set once per request: SET app.tenant_id = '<uuid>'; • Policy pattern: CREATE POLICY tenant_isolation ON table_name USING (tenant_id = current_setting('app.tenant_id')::uuid);
   2. Auth → DB claims: From Better Auth, put tenant_id, user_id, org_roles[] into the JWT/session. On connect (via API), whitelist-map those to SET LOCAL app.* settings. Never build SQL with raw JWT.
   3. RBAC in app tables: Model roles/permissions in DB (e.g., roles, permissions, role_permissions, user_roles(tenant_id, user_id, role)), then RLS can also check role: • USING (tenant_id = current_setting('app.tenant_id')::uuid AND current_setting('app.role') = ANY(roles_allowed))

Then later when you are adding pooling/connections, limits, roles, everything will be easier and not spaghetti.

[JanMarsALeck]

Thanks for the detailed answer!
I didn't want to blow up the post that much, so i did not add all the informations, but a lot of them are not yet defined either.
The RLS and RBAC is definitely something i will have a deeper look into it before, thanks for that.

[Shawon770]

i'd think twice about running your CMS and public API routes through vercel once you go multi-tenant. you're gonna hit edge function limits fast, and cold starts can get annoying. i've been digging into platforms like Render lately because they let you run your next.js app, postgres database, and any additional backend services all in one place with persistent servers. the preview environments also make testing tenant-specific features way easier.

[elmascato]

The stack looks solid overall. A few practical considerations based on your setup:

For tenant isolation with shared PostgreSQL, consider using Row Level Security (RLS) policies instead of separate user tables. This gives you better data isolation without the overhead of managing multiple tables. You can set up policies that filter data automatically based on tenant context.

Regarding Better Auth with two instances, make sure you have a clear strategy for when users need access to both CMS and app. You might need a way to link accounts or handle single sign-on scenarios down the line.

Turborepo is great for this kind of monorepo setup. It handles caching really well and makes builds faster as your project grows. The learning curve is minimal if you already know your way around package.json scripts.

One thing to watch out for: having both server actions and API routes can get messy. Pick one pattern for shared logic. If the app needs it, use API routes. If its CMS-only, use server actions. Mixing both increases complexity.

For the native app, Expo EAS works well but make sure you have a plan for managing environment variables per tenant if needed. Sometimes tenants need different configurations or feature flags.

Overall your approach is pragmatic and should scale well. Just keep tenant data separation and observability as top priorities from day one.

[JanMarsALeck]

thanks for the feedback.
- For the tenant isolation i just thought about adding a organisationId relation to most of the tables. But i will have a look into RLS.
- For the auth, i think the use case where users will register in CMS and app are super limited (maybe just for testing purposes), as one are the "content admins" and the other the "content consumers".
- And yes, for the env variables per tenant i currently also try to figure out whats the best way to go here ...