I’m exploring whether Kirby would be suitable for a fairly large-scale e-commerce project and would love some input before committing to it.
The site would potentially involve:
Over 100 registered members (staff, contributors, or vendors)
Around 2000 product pages/SKUs
The possibility for customers to create their own accounts (for purchases, wishlists, etc.)
I know Kirby is file-based and not database-driven, so I’m wondering if anyone has experience with this kind of scale.
Specifically:
Would 4000+ product pages significantly impact performance (both in the Panel and frontend)?
Are there known limitations with managing a large number of users or accounts in Kirby?
Would integrating something like Merx or another e-commerce layer be feasible at this scale, or would a more database-based system (like Shopify or WooCommerce) make more sense?
Any insights, real-world examples, or technical considerations would be really appreciated.
my Kart plugin for e-commerce has built in caching and will be able to handle 4k products pages, their variants, filtering by category and tags with ease
I was wondering the very same question, thanks for bringing it up. I’ve also noticed that some Kirby calls are way more expensive than others, but with the right optimization a site of this size can definitely run smoothly.
For example, there’s this case here on the forum: 9000 articles website crashes. The site was actually based on my Tablog theme. The main issue there was simply that I hadn’t included pagination (my oversight—I didn’t expect someone to run 9000 articles on a blog ). Once pagination was added, the site has been running fine.
That said, I do have a related question for @aengustukel and @bnomei (or anyone with real-world experience at this scale): How do you usually handle storing orders? Do you rely on an external service like Snipcart, Stripe Checkout, etc.? Or do you keep them as regular Kirby pages?
I’m curious if you see potential bottlenecks or pitfalls with storing thousands of orders as content files, especially in an e-commerce setup like the one described here (4k+ products, user accounts, etc.).
Kart will store them as pages unless you disable orders entirely. retrieval via uuid is quick enough and a cache was added to group per user.
while having orders in kirby is useful your tax related books will most likely depend on your external service like Stripe to track refunds and such properly.
I’m still not a big fan of having all orders stored as regular Kirby pages. I know the Kirby team has done a lot to optimize performance, but in my opinion keeping thousands of orders in the content structure could pose both a security risk and an unnecessary performance overhead for a site with lots of traffic.
I’ve been experimenting with building a small e-commerce setup in Kirby, so let me bounce an idea I’ve been playing with:
Orders would be stored outside of /content, e.g. in a /data/ directory.
Each order is saved as a simple JSON file named [timestamp]-[customer-id].json, containing all relevant order details.
This way the filesystem keeps them naturally sorted.
By default, the children() of the “orders” page would just return an empty collection.
For admins, the children() method would check authentication and then expose the JSON files as virtual pages.
For customers, the same principle applies: just grep/filter files by their customer-id and attach them as virtual orders for the user’s order history.
This approach could easily be swapped out for SQLite, another database, or an external API if needed, but it keeps things lightweight and avoids bloating the Kirby content structure.
). Once pagination was added, the site has been running fine.
How do you usually handle storing orders? Do you rely on an external service like Snipcart, Stripe Checkout, etc.? Or do you keep them as regular Kirby pages?