Evening All.
I hope you’re all well.
I’m planning to build a multi tenant SaaS app and after much searching around there seem to be quite a few different options with varying buy in prices some with none and wanted to get some advice on what you have used, what you experienced and recommend?
The top ones I found are:-
The obvious is Spark but have read mixed reviews.
Hyn Tenant looks promising but requires a bit of groundwork to get going.
I’m a huge fan of Laravel and haven’t really done anything with Vue yet which puts me off Spark a wee bit as it’s very Vue focused from what I’ve heard. Not that it’s a bad thing in anyway, it’s just down to my lack of time and knowledge with Vue.
And then there’s database structures. Should I have individual databases for each tenant which seems the most logical choice or one db with multiple tables all belonging to the tenant?
Anyways opinions and recommendations are welcome. Thanks in advance all.
When I was deciding this I went with Spark and eventually ended up regretting it. It has a lot of opinionated design choices that I didn't love so eventually I stripped it out of my application. I'd recommend not going that route but that is just my experience.
Depending the depth of what you need, you can do some pretty simple things with Observers, Scopes, and Middleware to get multi-tenancy working. This is what I have setup now and it works well.
Thanks @mellymatt. Your opinion is inline with a lot of others I’ve read.
After reading more today, I like the idea of having separate databases for each tenant for further security and also to reduce the number of concurrent connections per database. however in theory I could end up with hundreds of databases so still torn as to which way to go.
Interesting point you made with the observers scopes & middleware. I’ve not done anything like this before so any advice would be greatly appreciated.
One of the things that concerns me with all of these tenancy packages is if they stop being supported for any reason, as Laravel progresses I could end up in a bit of a sticky situation so prefer the idea of creating my own un obtrusive tenant setup. Just not sure where to begin 😂
@oli_d111 I don’t get this fetish with having a database per customer when someone mentions “multi-tenant”.
If you have a thousand customers, are you really wanting to maintain/scale/migrate 1,001 databases…?
Hi @martinbean. Its not so much a fetish, more that it makes more sense from a security standpoint and a performance standpoint.
The app that i'm building could have thousands of records for each tenant. Times that by 1001 tenants and quickly the database will start seeing performance issues no?
Please correct me if i'm wrong though as this is my first SaaS app.
have a look at https://saasadventure.io/ currently 60% off at https://saasadventure.io/stayhome
Tony Lea is a very experienced trainer/developer
Regarding multi database / scoped single database, can you imagine managing migrations on 1000's of databases? It can be done, but I would only do it for really sensitive PCI or Health data
Other resources
https://docs.spatie.be/laravel-multitenancy/v1/introduction/
Mohammad Said: https://www.youtube.com/playlist?list=PLC7jp2b5k85IPcoOrb8T6dYK6zYTMIIui
Thanks @snapey. I hope you're well. Thank you for the links.
I see what you're saying regarding the 1000s of databases. I'm currently looking at this one... https://tenancyforlaravel.com which allows for automatic migrations as soon as a new tenant is created on a multi-database setup. Also offers single/multi-database setup etc.
Spatie looks quite nice. :)
My concern with a single database and please correct me if i'm wrong, is with 1000's of tenants and thousands of records per tenant, would there not be a significant performance decrease on a single DB? That being said, i would much prefer to use a single DB as it would make queries a lot easier.
I just don't want to go down one route and find out i've shot myself in the foot when i should have gone down another route.
My concern with a single database and please correct me if i'm wrong, is with 1000's of tenants and thousands of records per tenant, would there not be a significant performance decrease on a single DB? That being said, i would much prefer to use a single DB as it would make queries a lot easier.
In a word, no.
Get to tens of millions of rows and you might start to worry.
Single database with the correct indexing will be no different to multiple databases on the same database server. You still have one server with one pool of memory, you just moved the partitioning of the data up a level.
Far more important is the level of traffic on your database, which would ultimately cause you to have dedicated database server or splitting the use base up across multiple servers. There are multiple strategies for scaling up / scaling out and by the time you get to this issue you will be employing a DBA to guide you and will have reengineered your application multiple times.
Build what you need for now not for when you have 6 figure MRR
Much appreciated thanks @snapey. I think i'll go down the single DB route for now and scale accordingly when the time comes.
My concern with a single database and please correct me if i'm wrong, is with 1000's of tenants and thousands of records per tenant, would there not be a significant performance decrease on a single DB?
@oli_d111 No. Relational databases like MySQL and Postgres are mature. They’re capable of handling tens of millions of rows as long as you index your columns appropriately.
Having to manage thousands of databases because you made some premature optimisation decision is the definition of shooting yourself in the foot. Look into horizontal database scaling when you need it.
Please or to participate in this conversation.