Hi all,
I’m developing a web app that I intend on trying to sell as SaaS
(Software as a Service (ie Basecamp)).
-
The first thought on my head would be to use one single database,
and create columns to indicate which client was the owner of that row.
The main table will be getting somewhere around 50 rows everyday for
each client. This gives me near 1k rows per month, per client
(considering only business days + rounding). Considering that I hope I
can reach say 100 clients, I will be getting 100k rows per month. In
one year, thats more than 1m rows. I believe that queries on tables
with 1m rows have a significant slowdown. -
So the next thought was to create one database per client. Then I
would have 100 databases in one server, which does not sound that bad.
To be able to do this and still keep only one codebase, I would need
to store the database connection parameters in different files. Then
when someone requires data from xxxx client, xxxx_dbs.yml is used. Any
thoughts on that? -
Also, I could create a mix of both options, where I would have
client groups (creating groups for every, say, 10 clients), then
having only 1/10th of the configuration files and 1/10th of the
databases, but requiring a column on each database to differentiate
between clients (this sounds hard to implement on app level).
At this point, option number 2 sounds like the best one. Considering
that my app actually gets useful and sells a lot, reaching, say, 5000
clients, will the option for 100 clients still be the best one for 5k
clients?
Do you know how 37signals works regarding this situation?
Thanks!