Hi all,
I have a client who wants a site that will have subscribed users - i.e., users will have to be registered on the site, and will need to be able to ‘login’ to access their account details and a restricted area. They expect to have around 5,000 users, perhaps more.
I was thinking of implementing the users as Pages - each user would have their own ‘page’, with info that would be editable by them on the frontend. But once I heard that we’re talking about 5,000 or more, I started to wonder whether it wouldn’t be more prudent to use a database - SQLite is already installed on their production server.
What do you guys recommend?
I agree that a database would make sense here. Although SQLite is again a bit limited performance-wise, so you should test performance before making the site live. If you have MySQL available, I’d prefer to use that.
Maybe off-topic (sorry, for that) - but if you really want a scalable, robust database-solution one can consider MongoDB.
https://www.mongodb.org/
It’s more flexible, powerfull than SQLite / MySQL (thanks to it’s database-layer model).
Once again, this has nothing to do with Kirby - so sorry for posting this in the “wrong” forum.
I would also opt for a database, but the community seems to agree on that anyway.
I just wanted to comment on two things:
You have to create really really big applications to hit the performance limits of SQLite. Your typical website with 5000 users will not be able to reach that limit. See the sqlite website for more details:
SQLite works great as the database engine for most low to medium traffic websites (which is to say, most websites). The amount of web traffic that SQLite can handle depends on how heavily the website uses its database. Generally speaking, any site that gets fewer than 100K hits/day should work fine with SQLite. The 100K hits/day figure is a conservative estimate, not a hard upper bound. SQLite has been demonstrated to work with 10 times that amount of traffic. The SQLite website (https://www.sqlite.org/) uses SQLite itself, of course, and as of this writing (2015) it handles about 400K to 500K HTTP requests per day, about 15-20% of which are dynamic pages touching the database. Each dynamic page does roughly 200 SQL statements. This setup runs on a single VM that shares a physical server with 23 others and yet still keeps the load average below 0.1 most of the time.
2… [quote=“1n3JgKl9pQ6cUMrW, post:3, topic:3864”]
It’s more flexible, powerfull than SQLite / noSQL / MySQL
[/quote]
I can agree on the more flexible part, at least when it comes to the database schema. But then again, is your database really going to grow so big that schema evolution in a RDBMS becomes impractical? [Besides, in most cases schema evolution can be avoided with some proper planning in the beginning.] And more powerful… that is highly dependent on the use case. I am not saying you should not use MongoDB, but you should at least consider the advantages and disadvantages of both approaches, and not just adopt any technology stack blindly.
Btw: MongoDB objects and collections are pretty far from being table structures… and MongoDB is a noSQL system.
2 Likes
You’re right - I typed too fast (and corrected it).
I mainly use MongoDB for some highend performance cases - they have about 500.000 unique entries a day (feedback management and insight programs cross-globe), so that’s why I choose for a scalable solution.
But I guess you can also use Kirby for about 5.000 clients; it’s not that many (when using ssd and caching).
But once again; I am no expert -sorry for that.
Thank you for the feedback, everyone! I’m glad to see that my initial assessment was correct, and that we should go with a database. I’m inclined to go with SQLite, because it’s already available in the client’s server, and I think it can comfortably handle the dataset and the traffic. If the site grows, we can always then upgrade to MySQL, if needed.
I love the idea of NoSQL databases, but haven’t yet found the time to learn one properly… Some new ones now offer ACID transactions, and an SQL-like language, which would make transitioning to them easier, if you’re coming from an SQL background.
Once again, thank you all for your input! 