My old CMS has sadly lost some support and I’m moving on. Have to say I’m very impressed with what Kirby has to offer. The only difference is my old CMS was a traditional MySQl and PHP based system. Typical thinking is that those combinations can handle some pretty large data sets.
Because Kirby is a flat file system what kinds or limits or applications might NOT be applicable for a site built on this platform? I’m trying to get a handle on Kirby’s limits to understand when to recmmend it to solve a client’s problems vs a different system.
I think it has its limit for bigger projects with a lot of pages/data and/or with a couple of editors. The issue with file based systems always is that once you store and call a lot of data, they’re not really great performers. Also, since they’re file-based and not a structured, optimized system like a database, they’re not that good in terms of building data relationships and data collections.
For normal websites I usually don’t see any drawbacks and I’ve seen even big projects being developed in Kirby but they were on the limits and for some it’d have been better to use something else instead. Think of about 100k content files/pages and relational data for these examples.
So it’s perfect for everything that isn’t dealing with lots of dynamic content/data (user data, service platform stuff or similar). Hope that helps a bit.
I would not fully subscribe to that. A good and deliberately organized filesystem structure is better than a poorly designed database. A database just does not make things better of its own. With a database, you are adding another layer of complexity in terms of realization, maintenance and security. If you already have the resources for that, it is fine, if not, you might run into trouble.
i have done a lot of projects beyond 20k content pages and kirby did not even break a sweat. it really depends on how much data you load in a single request. but even then anything up to 500 content files in a single request should be no issue at all.
if you want to build very complex relations via a id based taxonomy and lots of relations then you might run into issues with kirbys panel and un-cached blueprint resolution. think of having multiple tag fields and multiple related pages per page… not a typical website at all. even with a database ORM you need to do lazy loading then.
but all of these are solvable issues once you know what is going on and the forum staff and other members will always be there to help you.
Sure. You have to setup every system properly and database structure is its own complexity, too. But that’s the case for bigger Kirby setups as well. I totally agree that for many projects, Kirby would be in advance for its simplicity.
However, thinking about services with products and users I think it’s where Kirby isn’t necessarily the best option anymore. And while a small yoga studio or similar may be better using Kirby with a small shop to sell the courses, a large online shop would be better using a different software that’s made for this use case.
All big Kirby projects I was part of needed quite some special code, custom plugins or controllers, workarounds and optimizations that aren’t built-in. The I/O speed certainly is an issue with all the files being called on the server if you have lot of traffic and you have to optimize that. You can also scale better with a database layer than a filesystem with edge nodes.
Discussing it I realise how hard it is to answer the question without knowing some scope or goal. It depends on the project itself, its complexity, the developers building the site and the scale and cost of it…
I would also cast a bit of shade over this. Of course, it is very dependent on the use case but a sweeping statement like those in bold are not helpful or accurate.
It is all about how you structure and query. You can do it the wrong way in MySQL and Kirby which will affect performance just as much as doing it the right way in both.
I have a site that queries upwards of 500 pages, for example, it’s as fast as MySQL, yes I have compared. Kirby can be structured and optimized without the needs for anything beyond it’s base setup.
Now, of course, there are advantages and disadvantages in every ‘solution’ but you need to know enough to understand what they are and whether something like Kirby would be better than say Laravel and others.
If you store data like images in a blob format in databases a filesystem will be faster. Using Kirby’s defaults, you’ll either not have perfectly structured data in complex systems or slow performance. As bnomei says there are workarounds e.g. by using his plugins or custom code but the defaults aren’t enough anymore. The bits highlighted in strong I would still fully support as I wrote them, nothing written in this thread yet really invalidates it so far.
I even heard security being a discussion point which I find interesting because most filesystems are more prone to a hacking attack than a database where the minimum security is easy to achieve while permissions on file systems are hard when you want to really secure it. That’s why I meant once you deal with a lot of secure data like user data or payment data you probably want to think about a database layer. Store a password in a database or in a text file. Which one is more secure, both using only default methods? …
If you don’t have a great caching and abstraction method in place, a filesystem will be slower and the hardware will be used much more than using a database layer in project with lots of traffic due to the way they both were built. Filesystems weren’t built for concurrent access while databases were. The file system lock arbiter will get crazy while DMBS handles mostly fine still.
Databases index objects, filesystems index files. That’s the easiest explanation why per-se a database is usually faster once you reach that level of traffic and size of a website where you get some data from here, some from there, not everything from one file.
Finally a database migration is easy to rollback and still guarantees data integrity, a file system migration isn’t easy to build with an included rollback while guaranteeing integrity. Data redundancy would need to be managed by the application using the filesystem while otherwise the database layer itself could take care.
I’m just listing the limits of a Kirby by default, as requested. I’m showing the difference between the defaults of both methods.
As I said before, this doesn’t mean that there are database systems out there that aren’t that great (some are mentioned in this thread), CMS out there which don’t use databases efficiently or are slow by itself/the app code. And it doesn’t mean I don’t like Kirby. I just have made the experience that it has its limits and isn’t the best fit for every project out there.
Everyone is making some good points and honestly the limits are what i anticipated. I think for the vast majority of my clients it will be perfectly suited.
on a side note: i created a plugin called boost that makes kirby a good choice even when one needs to read a lot of content files in a single request. it pushes all content into a cache (php, apcu, redis, sqlite,…) and loads from that.
In my experience, unless you want to either model “many to many” relationships, do “searches” or “sort items by attributes”, a purely filebased CMS will normally outperform databases.
If you want to do one of those, it comes down to the number of items you want to do it on, the better performance you get from database indices needs to justify the latency you add for creating a connection to the db (often on another machine), parse queries, serialize, transmit and unserialize the data.
About security, from the little I have seen, I doubt a database offers better security compared to files, simply because you normally store database credentials in those files. This means: if people get access to your code, they also get access to your database.
On the other hand, databases are normally exposed to the network, while simple files are not. What I mean by this is that databases add to the attack surface, they don’t reduce it.
If the hosting is correctly set up, that means even shared hosting that effectively use suEXEC, you can set all your files to mode 600 and it won’t get much more secure.
That being said, I personally see Kirby as a framework, not so much as a “I’ll just install a bought theme CMS” and there’s no reason to not use a database with Kirby if it really gives you better performance. I always have “custom code” with Kirby, and I like the fact that it doesn’t get in my way.
Thanks, it’s one of the project I was referring to in prior comments. A lot is possible with Kirby but it’s not using built-in database functionality and instead a lot of custom code to make this work. Doable but I wouldn’t call it an out-of-the box solution… in other words: For this project you could use Kirby or any other system. The work is the same as the code is in any way a custom code to make this work together.
