Scaling WooCommerce: Insights on High-Performance Order Storage (HPOS)

Marcel:
Well, hello everyone. Welcome to another episode of Woo Have Chat. Today with me, the one and only Mike. Hello, Mike. I was trying to think of a fancy way to introduce you today, but…

Mike:
That’s what you think.

Marcel:
That’s as fancy as I can get. Yes. How are you doing, man? All good?

Mike:
I’m good, I’m good. Monday morning. Got to do some work today using New Relic to troubleshoot WooCommerce. So maybe there’ll be some stuff to talk about with that.

Marcel:
Oh wow. Alright, today’s a very special episode. We are excited to introduce Vedanshu Jain. He’s a senior software engineer and a key contributor to the WooCommerce project at Automattic. I guess for the last six years, but he’ll correct me if I did the math correctly. Lately, he has been concentrating on scaling and performance. He plays a pivotal role in leading the HPOS project. Also, we did talk about the pronunciation of HPOS, if that’s the correct way to pronounce it or not. We’re going to be corrected in a minute. He’s also worked on numerous performance enhancements and has helped many merchants fine-tune their sites to handle greater scale. So let’s dive into his insights. Welcome to the show.

Vedanshu:
Hello, hello. Very happy to be here. So yeah, I have been working for six years now at Automattic, which is more than half a decade. So yeah, that’s a lot. HPOS, I guess I pronounce it HPOS, but I do not think we have an official pronunciation. So I suppose as long as we can communicate, it’s fine, but it can get a little bit hard to figure out what you’re talking about. H-P-O-S, it’s all the same. No problem.

Marcel:
Right? Well, there are many ways to pronounce it, and most of the people we talk to about HPOS or HPOS, they go and say, “What is that?” Regardless of the way that you pronounce it. So I guess you’re right, we need to explain to people what that is. Would you mind explaining very quickly? I know we did an episode about this previously, but there might be some people who don’t know what we’re talking about and have the exact same response to HPOS: What the hell is that?

Vedanshu:
Yeah, so HPOS is basically High Performance Order Storage. What we did with that project is that WooCommerce by default used to store order data in posts and post meta tables using custom post types, which is a feature in WordPress. It’s a great feature, and we have been quite successful users of that feature, like WooCommerce and many other plugins in general. But orders specifically can grow really fast. For a successful site, you can have hundreds, thousands, and millions of orders, and then storing them all in posts and post meta tables means that different operations on the site are going to compete with all this bulk of orders for all their normal operations, right?

Because it’s the same table, it’s the same data storage. So what HPOS does is it stores just the order data in different tables so that your posts and post meta tables are free to serve your post content, to serve the site’s content, products, attributes, and all those other things. So in a sense, it makes your site faster, but maybe that’s not a super accurate way to say it. I think a more accurate way to say it is that it’ll make your site more scalable. So when you’re receiving this bulk of orders, your site will not be slowed down just because there are millions of entries in the post meta table due to orders or just because of the orders that you’re receiving. So it sets your site up for easier scaling for your growth, and yeah, that’s what the whole project is about.

Marcel:
Great. Do you think this is for all merchants out there using WooCommerce? Is this for just people who have a hundred thousand orders? Is this for people who are just starting out and need to activate this no matter what? What is your recommendation?

Vedanshu:
So if you are starting out, I 100% recommend that you start with HPOS because you are going to hit growth—or at least you want to hit growth—or at least we hope that you’re going to hit that growth, and then you will need it. So it doesn’t make sense when you’re starting out to not start with HPOS because everything else is the same; everything else is equivalent. You will have very similar interfaces; you have all the major plugins already providing support with HPOS, so you have the same experience. So for the shops that are starting out, I highly recommend starting with HPOS, which is also the default. If you set up a new site with WooCommerce now, you will start on HPOS. Additionally, for shops that are hitting growth or shops that are already using custom post types because they have been in business for some time now, I do recommend that you consider switching to HPOS whenever you can because if you don’t—or let’s say you don’t have time now—then when you hit growth, you would want to do it, and then you would do it in a bit of a stressful situation because orders are coming in, the site is slowing down, and now you want to start planning it. It would be a bit more stressful.

So if you can plan it early, that’s really great because that’s what we are trying to get everyone towards, which is just an HPOS-based future. We do want people to scale well. We do want people to have great experiences with WooCommerce at any stage of growth. So yeah, I recommend HPOS if you start out, but also if you already have a shop that’s on custom post types, plan your migration when you can plan it without stress.

Marcel:
Right. Most people don’t have HPOS activated by default, I guess I would say. And most people are also afraid to activate it if they already have a store and it’s a big store. I didn’t want to talk too much about this, but I think it’s a good way just again to remind people about how great of a feature this is. Would you still recommend people to invest a small amount of time in activating it? And would you say it is hard or very easy to activate HPOS?

Vedanshu:
We do understand the complexity involved in it. So you’re basically on a live site, you’re basically replacing one of the key components of that site. You’re basically replacing where very critical data is being stored live. Understandably, it’s a bit daunting and intimidating. The good thing is we have in-built rollback mechanisms, which means that you can switch to HPOS, you can try it out, you can verify if it works fine. In a situation where it does not work fine, the rollback is possible. So from the interface itself, you can switch back to post tables, and then everything would be as it was before. So we do have some safeguards. We do have some fail-safe mechanisms, which basically mean that even if you found some issue or even if you find that you do not have the time anymore or even if you—or for whatever reason—want to switch back, you can.

The main thing is that you do try to make some time here and give it a shot. So we also have a guide on the WooCommerce blog which tells you some steps that, if you’re running a high-volume site, what you can do or the series of steps that you can perform, some basic testing, some testing on staging, and then how you disable. So when you switch to HPOS for the first time from a shop that is using post storage, we would be writing data to both post and HPOS tables. So there is a series of steps that you can disable this sync methodologically. So this way, basically, you would have some ramp from post to HPOS, and if something goes wrong, you can go back to post again, and that guide will detail all that—what you can do, what you should do, what you should test for, and what you should expect.

Marcel:
Actually, the reason why we got to Vedanshu in the first place was a very interesting one because Mike had this client who had this very particular use case, and he was asking me, “Do you know somebody?” And I did know somebody else that works at Automattic and managed a lot of the WooCommerce-related projects. It was very interesting to ask Darren about, “Hey, we have this particular issue. Mike has this client. We would like to talk to somebody who can give us an answer, or at least a very comforting answer, about the way that we can solve this particular problem.” Mike, do you want to share a little bit about this story?

Mike:
Yeah, we mentioned it briefly in the first podcast, and it’s a Shark Tank client who gets a lot of orders. They had moved to HPOS but still had the backward compatibility thing enabled. I was doing… They wanted a backend troubleshooting project done, and they were having weird delays, and I noticed this consistent query that was showing up that was taking 40 seconds. I remember asking you on the way to go play squash, Marcel, and you were like, “Oh yeah, those are the HPOS tables. They shouldn’t be taking that long.” And I was like, “Yeah, the whole benefit of introducing HPOS was that search queries and things like that were supposed to get way faster.” I think you had a client as well who had a similar challenge, and we were trying to gather data. I tried rewriting the queries to make them more precise

so they weren’t using likes or wildcards and that kind of stuff, and it still didn’t really make that much of a difference.

So then we went on this adventure to figure out who can help us answer this. This is not what was supposed to happen. Then we met Vedanshu at the WooCommerce party in Turin, and you said, “Oh, there’s this new feature with these indexes that we are adding in WooCommerce 9.00 beta 2, which should speed that up significantly.” I think a week or two later, I managed to get it tested, and the same queries ended up taking a hundred milliseconds, and I was like, “Ha, it works!” And Vedanshu was so confident at the party—I don’t know if you remember—he was like, “Yeah, yeah, just install this. It should be way better.”

Marcel:
I do remember, yeah.

Mike:
Marcel and I were both a little bit skeptical, we’re not going to lie, because we were like, “How is it going to go from 40 seconds to anything acceptable? There’s a long way down to two or three seconds.” So yeah, we were very pleasantly surprised to see that it made things significantly faster. We were curious about how you go into researching, developing, proposing, and sort of testing. That’s a major change because building a separate index for all of the order emails and stuff like that so it’s basically instant—that doesn’t sound like it’s something you just snap your fingers and it magically gets done. So I’m curious what that process is like.

Vedanshu:
So I think for the context, you’re talking about the HPOS text search, which is basically full-text search in MySQL. This is something that we wanted to do for a long time, even before HPOS, but the structure, but our way of storing data where we would store data in the post meta tables, was a blocker for us to do it because you cannot add this index on the entirety of the post meta table because it would make your space requirements for the database or RAM requirements go way up. So I guess for research, even before HPOS, one of the things that we researched is what would be possible because just changing the database structure without leveraging the features of that structure is not going to just speed up the site. But what you would get with this sort of architecture change is basically collateral gains, which means that even just by changing that data structure, nothing happens by default. You would need to write those queries, you would need to build those in, and you would need to do some work on top of it to actually take advantage of this new structure.

So with that in mind, we decided to have this addressable separately so that we can apply an FTS index on it. So yeah, I guess it depends on doing some planning ahead on what you want to do with this feature once it’s out, once it’s built. This is something that a normalized structure would allow you to do, is that you can add more indexes, you can add very specific indexes on the data structure or on the query requirements that you have. FTS is one example, but there are some more. For example, for many shops, they might be querying some specific column more often than the other ones. Even if WooCommerce does not provide a default index on that column specifically, the merchant can add it, or the developers can add it. So for research, we take a look at what we can do right now, what are the things that are blocking.

So even with post meta, you can scale a site quite well. You have been in business for quite a while, and you would know that even with posts and post meta, you would have experienced that you can scale a site quite well. It’s just that there are some things where this structure would start becoming a blocker. There are some features that you cannot explore anymore. You can still work around it. For example, you could stream the order data to Elasticsearch and provide the search from there. You could do many workarounds, but it’s not straightforward, it’s not simple enough, it’s not something that works out of the box. So this is that we actually did figure out what we wanted. Even if you see the issue—like the issue for the FTS index—it opened two years back when HPOS was still in planning.

We opened the issue then that this is something that we would do once HPOS has rolled out. There are some more enhancements that we still have in mind, and hopefully, we would be able to roll those out soon enough. But yeah, we try to look at what is currently possible, what is currently not possible with the existing structure, what are the blockers, and try to figure out how we go from there. But FTS and index is something that’s been on our mind for a bit now. I think for the WordPress core project too, they also have an issue open to add FTS indexes for post content and the main post table so that you are able to search post content way more faster than you can right now. But yeah…

Marcel:
How would you test something like that? So let’s say, for example, you get your team together and you decide, “Oh, let’s do these indexes, this full-text index thing, and we have now a new table, and we’re going to turn this on,” and now you go, “Yeah, but first to make a decision, I would imagine that you have to base it on results, and you have to have some data that will back up the decision about activating or proposing for everybody to activate this.” I know how well most people probably have their MySQL database settings set up in a way that it’s possible to use it, but how would you go about measuring the success of something like this and say with confidence now for everybody that this is going to benefit everyone?

Vedanshu:
So for testing, the primary testbed is some of the test sites that we have, that we host on. So basically they’re hosted on WordPress.com. Some of those sites have about 1 million orders or 600,000 orders, and we primarily test against… So that’s the first step in feature development. We would build these queries, we would manually create these indexes using direct MySQL queries, try to run queries, compare the differences, and see if it’s something that’s worthwhile to pursue. If it is, then we would try to build it into a feature, and then we would do this testing that we are doing right now. So currently, FTS indexes are marked as experimental. One of the things that currently actually blocks it from graduating, or sort of graduating away from experimental to enable by default, is that in some specific versions, we find that the results are inconsistent.

So I do not recall exactly, but anyway, I think from MySQL version 8.2.0.24 to 8.2.0.31, you will see that the site will be unable to create this index because of a MySQL bug, which was then fixed in 8.2.0.35. Okay, so this is something we learned. Once we have this package, once we have this in experimental, we do not know how it’ll go. We got these reports that this person is not able to create this index on the site, we go and try to debug, and then we find out that okay, this is some MySQL bug, and you have to upgrade a MySQL version to actually have this working. So once you put a feature in experimental, we try to make some noise about it or try to have more people use it. Some people would have great experiences like you have, and then some people will find out some edge cases and report them back to us.

So we would eventually graduate the feature when we are confident that we have resolved most of the edge cases. We know that this feature will not break sites just on upgrading. We know that this feature will not break sites just on enabling it. So this is the same process we followed for HPOS. We had an experimental mode for quite a long time. We made a lot of noise about it. We requested people to try it out. Some people had great experiences, some people reported bugs, and we tried to fix them as much as we can. Eventually, you’ll see that once you release something as experimental, you get a lot of bug reports soon. Depending on how big the feature is, you will get bug reports very soon, and then they will start to drop off. Once they sort of stabilize, once you have fixed all the high-priority bugs, you can mark that feature as stable. This is something that we did for HPOS; this is something that we are doing for FTS indexes. But actually, FTS indexes are quite stable. There are some edge cases—there is another edge case around phone numbers, which it is not able to search properly, which is something that I actually have on my list to look into today. But other than that, it seems quite stable. Hopefully, we will be able to graduate it soon.

Marcel:
I guess also indexes are a feature of the database engine. It’s not something or some code that you guys wrote and are experimenting with like it is with HPOS, right? You sort of trust the engineers who created the database engine on it working as it should be, as it was created for. I imagine it would be kind of easier to make the decision in terms of activating that as opposed to HPOS, which is—or HPOS, I’m going to call it HPOS for the rest of the podcast—just shorter. It’s shorter. It’s the way that we’ve been talking about it the whole time, so it’s very hard for me to change it. Where you have this synchronization

going on, you have important data copying. I imagine that is a much harder update to do than just the index, right? Let’s imagine the following: You were sitting down in front of a computer, you were talking to some friends, and somebody came up and said, “Hey, I have this great idea to build something for WordPress that is an e-commerce platform, and let’s call it, for example, WooCommerce.” What would you architect differently in terms of the database in comparison to today? So if you were to be able to, at day zero, decide on the architecture of the database, what would you do differently?

Vedanshu:
Okay, so that’s a very interesting question. I also wanted to talk a little bit about what you said earlier about the FTS indexes. So FTS index is one of MySQL’s features. You can do a CREATE INDEX statement and have it enabled, but it’s a little bit more complex because it has a lot of tuning parameters. For example, you can specify… Right now we have configured it to work on natural language, so it would split words based on spaces, apostrophes, and all the natural language separators. But you can also create just trigrams or n-grams. You can configure it to behave more similar to Elasticsearch. So there are some configuration parameters that you can play around with depending on the use case of your site. So this experimental time is also meant for us to figure out what the optimized state of tuning for that feature is, which we may end up changing based on the feedback that we get.

But otherwise, it’s much more stable than HPOS because we trust the developers of MySQL very much. It’s an extremely great piece of software. Right, okay. So if you think about the journey of WooCommerce, the CPT integration with custom post types gave it, in my opinion, a much-needed lift when it needed it. Developers understand custom post types; developers understand playing around with it, extending it, modifying its API. So integrating it with custom post types rather than building a new table from the start I think was a good decision—or at least in my opinion—because it allows you to, first of all, build it really quickly because then you do not have to create all these custom queries. You do not have to manage the caching around it. You do not have to do a lot of things. WordPress will do the heavy lifting.

In fact, you don’t even need to create an admin interface. You don’t even need to worry about access controls, security, performance, and so many things that are just taken care of for you, including the programmatic API to access it. So it’s extremely powerful, and I think at that point, using custom post types even for orders was the right choice. For a new project, for everything new, if I were sitting in a friend circle—maybe we were at a campfire roasting some marshmallows—if someone tells me that we are doing this new thing, I would use as much existing functionality as I can, or at least… So depending on who you ask, depending on what developer you ask, this is probably going to change. I think for any product, there is no singular success path. For every product, it’s going to be different, and you can make a product work using all parts, or a product will not work even if you have the best architecture—it’s implementation details.

But I don’t know, in my opinion, I would use WordPress features as much as I can and build custom functionality when I have to. But when you see this scale, unless WordPress starts coming in the way, I don’t think that I would engineer a feature to work around it or to bypass it. The other case is if the philosophy of what WordPress provides is completely different from what the feature intends to do, which it kind of is in the case of orders because they’re never going to be published to the world—the post is eventually supposed to be published to the world, an order will not. So it diverges from the philosophy a little bit, but then I would try to use as many WordPress features as I can because it would allow our team to start quickly, prototype directly on top of it, and then once the product is successful, then we can worry about scale. We can worry about what we want to do exactly—or, well, not what we want to do, but what’s the best structure for it and how do we support our customers who are growing very well, how do we support our clients who are doing very well, and we should not get in the way of their growth just for our growth.

Marcel:
The biggest challenge we have with databases is their size, I would say. Right? How big of a deal is it to have gigantic table sizes? I don’t know. We deal with 4 million rows, 6 million rows in post meta sometimes. Is that a big deal? Is that not so much? What would you say?

Vedanshu:
So disk storage is not that much of a concern as big of a concern as memory is—like available memory is. MySQL will try to load everything into memory. It’ll try to load all the indexes into memory, and if allowed, it would load everything, which is fine, which works great for the case that MySQL does for us. As a database designer, it means that our indexes are smart. We are not normalizing data too much. For example, in post meta, you have this meta key and meta value. This meta key is repeated thousands of times because every order is going to have the same meta keys, right? By converting it to columns, you’re reducing the amount that MySQL needs to load because—this is kind of oversimplifying—but it doesn’t need to load that string anymore. It knows that this is this column; it knows that this column is called whatever, and it knows all the values that belong to this column.

So the amount of data that MySQL will put into RAM decreases with this denormalization—it comes into play. I wouldn’t say that it doesn’t matter. I wouldn’t say that the space doesn’t matter, or I wouldn’t say that the size of the database doesn’t matter. It does matter. So first, with a bigger database, MySQL needs to have… With a denormalized database such as post meta, it would need to put more data into the RAM. But then also when it queries the data, it needs to scan through more rows; it needs to filter through more rows. So that also slows different parts of your site down. It’s a concern, but you can solve it in the sense that… One option is you can throw money at the server, but at some point, it gets tricky because there’s some limit to it, or that limit can hit really fast, really soon when the data explodes. So it’s a concern, but it’s not a concern when you’re starting up, when you’re developing this new product—or this is just my very subjective opinion. Many people will disagree with that—but it’ll definitely be a concern as you grow. It’ll definitely be a concern as you start to grow, as you start to acquire more customers or more data. And yeah, it would be a problem eventually.

Mike:
Hopefully… In Danish, we call those luxury problems. Hopefully, if you’re making that many orders, you’re also making money, and hopefully enough of that is profit to be able to allocate to solving this issue. So I’m curious, how much extra RAM is necessary for the FTS indexes on a site with a million orders? Is there any calculation or preparation people should do to make sure MySQL won’t crash because it runs out of memory?

Vedanshu:
I actually tried to measure it during my testing, but I wasn’t able to. MySQL would always use the same amount of RAM, but I think that’s because of the testing conditions that I wanted. That’s mostly because I wasn’t able to create this testing condition where it would load more data. Maybe it was doing something behind the scenes that wasn’t observable, but I suppose that it would definitely need more RAM. It cannot… Even though just because I wasn’t able to observe it doesn’t mean that it’s not loading more RAM, but what it internally does is that it creates these words. For example, in your address, if you have, say, “221B Baker Street,” then it’ll have this row “221B,” it’ll have this row “Baker,” it would have this row “Street,” and then in each of these rows, it would store IDs of all the different order IDs where “221B,” “Baker,” or “Street” come in. So it’s not inefficient, it’s actually… It’s quite a good data structure, as we trust the developers of MySQL. It’s a pretty good data structure. It should have some additional RAM requirements, but I do not know what that is, or at least in my testing or in my research that I did, I wasn’t able to find this exact number that I can point out that this is what it’s going to need.

Mike:
If you were testing on WordPress.com too, that would make it more challenging—a big multisite, right? The database is shared?

Vedanshu:
No, so for the RAM, I was actually testing it on my local setup to actually see how much the requirement increases so that I can actually figure out the memory used by that exact process. So that’s why I said that it should have some additional RAM requirements, but I wasn’t able to actually establish how much. I hope that MySQL would have some documentation somewhere that tells you this, but it would also really depend on how different your database is. For example, if all the customers live on Baker

Street, it’s not going to be a lot because it would find those repetitions. If your customers live all across the world with different addresses, the natural language… If it’s not able to index those words properly, if everything is different, then it would have a lot more requirement than it would by just when the addresses are more normalized. So maybe the RAM requirements cannot be as straightforwardly established as we can do it for other data structures, but it’s efficient, I hope. I guess, all that we have seen.

Marcel:
Ideally, if you have a database that is two gigabytes, you have two gigabytes of RAM, right? Just load everything into memory, it’ll work.

Vedanshu:
But then, Mike, you did test it out, right? Did you notice anything about how much additional requirement it imposed on your server?

Mike:
So on this particular server, it’s huge—64 gigs of RAM—and there’s a lot of it allocated. I think over 30 gigs of RAM is allocated to MySQL, so we didn’t need to make any adjustments basically. One of the reasons I moved them to that host was so that they had plenty of room for growth because they get so many orders per day, and their live site and staging site share the same server. So I would’ve had to get them to buy an extra airplane because it’s a dedicated physical server. It’s a bit more complicated than just spinning up an extra instance. But I’m having a meeting with them actually this week, so if I get any… When I told them I was going to speak with you, they were really excited because stores at this level… When they don’t want to move away to something like Shopify or something else, when things are working, their team is well-versed in WooCommerce and is trained in it now. So they don’t want to migrate away. Having someone who is very much working inside of core and knows what new developments are on the horizon helps give them a lot of confidence that WooCommerce can scale and can handle their multimillion-dollar business. Those are probably the kind of customers WooCommerce wants to keep happy, you would think, for the benefits of keeping the project alive for the very long term, so that it fits customers of all sizes—just starting out and those who have the luxury problem of that kind of growth and success.

Marcel:
Do you see a future where WooCommerce would be a standalone version of WordPress?

Vedanshu:
Currently, I think it’s too coupled. So anything can happen in the future—I won’t say that nothing is impossible—but I think currently WooCommerce is too coupled with WordPress to be standalone anytime soon, at least. We rely on WordPress to… For example, the product relies on WordPress a lot because they are a post type that does get published. But then we rely on WordPress for role-based access control. We rely on WordPress for the whole admin backend. We rely on WordPress for a lot of things. I think there is a very nice future for WooCommerce within the WordPress ecosystem and for the WordPress ecosystem itself. But I would not say that there would be a standalone WooCommerce soon enough, although I do not see it immediately, at least.

Marcel:
Yeah, the reason I ask has to do with what we were talking about and having these bigger clients come in. It’s hard for us as freelancers, for example, to come up with a big client and say to them why they wouldn’t migrate away from WooCommerce because they know that the concept of WooCommerce is… It is a plugin that is for WordPress, and WordPress is content management software that is more for… Well, it’s kind of strange to say that it is for blog posts and for running a blog, but it’s for so many things right now. But basically, what people understand when they have to make a decision is that they have these dedicated platforms that are just solely there for the purpose of having an online store. And then you have something that you attach to another thing, and that enables you to sell your products online as well. So it kind of makes it a little bit harder for us to sell the idea. Although honestly, WooCommerce is so popular right now that most of these big ones don’t even ask those questions anymore. But there are some numbers that say that WooCommerce is mostly spread in smaller stores than in bigger stores. So for people to make the jump and to decide about WooCommerce, wouldn’t it be better if you would be saying that you are installing WooCommerce and not WordPress? You know what I mean?

Vedanshu:
So this is something for the marketing team to really answer, but I don’t know. I’ve always seen WordPress as an asset because I understand that even for a person who is primarily here for commerce, who primarily wants to use WooCommerce for commerce, they would eventually want to publish their product. They would eventually want to have… Or maybe not everyone, but in a majority of cases, they would want to publish their products. They would want to do SEO on them. They would want to have good SEO for their site. They would want to have their site look beautiful, use nice themes. They would want to have a membership area, have customers’ accounts, my account pages, and all of those things. They are something that we derive from WordPress. Even if you take a look at a WooCommerce and WordPress installation as WooCommerce first, there are a lot of things that are essential for a commerce shop that we derive from WordPress.

The features that WooCommerce uses from WordPress are not small; it’s huge. We pretty much use almost all the functionality that WordPress has to offer. An e-commerce site will pretty much use all the functionality that WordPress has to offer. I think that’s an asset, right? Because not just the functionality, but it also means that there are more experts in the ecosystem. There is more knowledge in the ecosystem, there is a bigger community. There is so much that we gain from WordPress. If we had to make WooCommerce standalone, we would have to implement all these things again that we currently just get from WordPress.

Marcel:
It would have to be a fork of WordPress and then put WooCommerce on top of it, right?

Vedanshu:
Yep, yep. Something like that.

Marcel:
I like to ask these questions that are challenging, that you haven’t had time to think about them before. I think that’s the most fun about it. If you had a magic wand, what would you change in WooCommerce?

Vedanshu:
That’s an interesting one. So I do not have a magic wand—I really wish I did. As someone working on performance, I feel that currently people have to understand the platform a bit as they grow. For example, they would change servers, maybe they would migrate to different machines, they would integrate different technologies. There are some milestones that happen as you grow. This is the same, right? Migrating to a different server or a bigger server, integrating Elasticsearch, integrating some different technologies, figuring out if you’re at a stage where you want to look into horizontal scaling, and things like that. If I had a magic wand, I think I would make this super clear or I would have it done magically that, “Okay, now I need this,” so this just happens. “I need this,” this just happens. So again, this is with a caveat that this is my limited perspective, but I think people are not that worried about additional cost as they grow because as Mike says, it’s a luxury problem. You want to have these problems, but having to replatform is annoying. It’s a distraction away from your main business. It’s something… It’s a chore. So I wish that we had something that just scales you up as you go, figures out where you want to go, and just takes you there and everything is just perfect all the time.

Marcel:
Some notices appearing on the dashboard saying, “Now that you have a thousand customers, this would be advisable,” or… Well, who knows? Maybe AI will come in and help some of these clients scale a little bit better because some of these issues are repeatable, so they’re all the same for all clients. It’s kind of like there should already be some tool out there that allows us to give some automatic tips on how to improve the store and stuff like that.

Vedanshu:
Maybe you just click on a button and you are now on the server that you need at that point in your growth journey.

Marcel:
Well, to my defense, I would say we need two, but one is an automatic one and the other is “hire an expert.”

Mike:
For the “hire an expert.”

Do you find that clients take for granted the technological resource portion of running a store? I find in my own experience that it’s like buying a car. They buy the car and they’re like, “This should just run forever, no matter how many people I’m putting in it, how much crap I want to transport.” And when things stop working, they get very confused. They’re like, “What do you mean?” And I say, “Well, you’ve got to maintain the thing. If your family has doubled in size, maybe you want to get a bigger car.” It’s something that I find that non-technical store owners just… It’s like a shock for them. Some elasticity is required in growth and rebuilding and stuff. I was wondering if you found something similar.

Vedanshu:
I can understand that as a customer or as a user of the product, you may think that way. But as you mentioned, it’s not that simple. In India, there’s this thing called—we call it Chota

Hathi. It’s basically a small pickup truck, the miniature version of a pickup truck, and you can use it to haul and carry stuff from your warehouse to your frontend stores or whatever it is. When you start, you buy this Chota Hathi, and then you can outgrow it as you grow. Suddenly it’s not enough. You have to make too many rounds; you cannot carry that much stuff anymore, or you need to carry much more stuff. So you need to buy a bigger one. You need to buy a proper pickup truck. You need to eventually buy a fleet of them when you get super successful. It’s the same with WooCommerce as well. You can start with a very small investment, and then you can grow it as much as you can or as much as you want to. This is something that we are actually trying to… So we actually just published a blog post on, I think, Friday. It’s called “Scaling with WooCommerce,” which helps you with this path that when you start out, the principle of WooCommerce is that you can run it on a very small basic server, but it’ll take you to wherever you need to go with the help of magic wands, which we call experts in the community. That’s the main principle. This engine and this truck bed, that’s all you need, and you can add more of these if you need it. You can buy a bigger one, or… All sorts of vertical scaling, horizontal scaling, integrating other technologies, or whatever milestones there are, you can do that. That’s the focus from our side. But that said, I also understand that, “I buy a small truck and I expect it to carry everything for me forever.” The difference is that in a physical shop, it’s easy to see that you cannot fit more than 400 kgs or some unit of it more than that on this small truck. So you need to buy a new one, or you need to buy a bigger one, or you need to buy more of them. It’s not super clear in software because, in software, you click and something happens. So that’s something that is a perception that we want to tackle, but you will see that as you grow, even if you want a bigger truck or even if you want a fleet, it’ll give you a very nice return. You will be in charge of everything, and it’ll give you a much better return on your investment as you grow your business because these are the things that you are using to grow the business. So we are trying to change the perception of it. But yeah, I do understand that with software… Someone at least, even me, I just download it and it should take me to the moon, but that’s going to need a bit more work than that.

Marcel:
That’s awesome. We do have a lot of experience with customers like that, who just expect things to work. And also the other way around—they don’t expect to pay that much because they thought it should work in the first place. Sometimes we go in and say, “Yeah, but this needs fine-tuning and this and that.” And they say, “Yeah, but then I have to spend money, and it doesn’t make any sense.” Well, it does make a lot of sense. In the blog post you were just talking about, “Scaling with WooCommerce,” it’s really about that. It’s about different ways you can scale and how your growth and how the profit that you have… How much you should spend some of that into scaling well. It’s a very hard lesson to give to people, and that’s why case studies are so important—to show people how others did and how directly relatable it is for websites that run faster, how it converts better.

And that’s measurable. That’s something that, for example, Mike also has on his website—a tool to calculate that. So it’s very obvious to us that this is relatable, but it’s sometimes hard to explain that to other people. Do you think WooCommerce needs to have more case studies of the bigger clients where we can really point to them and say, “Look, WooCommerce is used in this million-dollar company, it’s used on that website”? Because with WordPress, we do this a little bit—we do tell people who are the big institutions and companies who use WordPress. I personally think WooCommerce misses that a little bit. Do you think that’s the case as well? And I know this is more marketing than performance, but it’s sort of related, right? It’s like, “Look, this is a website that has a thousand orders a day; you can do it as well. So your decision with having five orders a day today is a good one because you can scale it to a thousand a day.”

Vedanshu:
I think it would be helpful, yeah. So this is, as you said, marketing, but we do have customers that use WooCommerce on some crazy scales, and it could make a lot of sense to document their journey if they’re fine with it and tell people that they’re using it. Tell people what scale they have, how they’re managing it, what their average request times are, what their conversion is, and things like that. I think it would be helpful. Let me see if I can ask some people inside to see if we can do this sort of marketing.

Marcel:
Yeah, I think it’s very important, and this is the first thing people ask us: “Yeah, but do you have any examples?” and all of that. Obviously, Mike, being an expert, is more oriented toward this performance tuning part of the business. Mike does a very great job in writing case studies and almost automatically selling the idea that if you increase performance, you gain in sales. And yeah, I think that’s a very important part, and WooCommerce, I think, misses that a little bit, which we should definitely be investing more in—talking about these clients that I’m talking about. I’ve worked with some of them as well, and some of them… WooCommerce coming over to Codeable and asking for freelancers to work on these bigger clients because they have these bigger challenges. I was surprised to know, “Oh, this business? I know this business,” and I’m not living in the USA, right?

So I’m not supposed to know all the small, medium businesses and names that they have over there that have ads on the television and all of that. So there’s a culture around the businesses that is more US-oriented than in the rest of the world. But there are some other names who come over to this side of the world, and they get their brands and names over here. Some of them I say, “Oh, this website runs WooCommerce? Oh, that website runs WooCommerce?” So it’s kind of a surprise for me, and I question… It shouldn’t be a surprise for me as it shouldn’t be a surprise for anybody else. I think there’s something that needs to be done in terms of telling everybody, like all the other competing platforms do, right? They do announce who the brands are that are using them. I think it’s very beneficial if they would do that.

Mike:
I’ve found the challenge is often that… With the Shark Tank client, they made me sign an NDA. They don’t want me to publicize who they are because once it’s a business, there’s money involved, there’s competition, and people are always looking for a technical edge or a way to… “How are they doing it?” If you keep your competitors stuck on trying to figure out the technical puzzle, it takes away their resources from being able to compete in other areas that might be challenging for you to keep up with. So I think part of it, unfortunately, is just business and the nature of it, and trying to keep things competitive and keep your profit margins and your market share. It’s way easier for me to get people who just use WordPress for the blog or the content production… They’re happy to brag about how many visits they’re getting and how much things got better.

But as soon as they’re selling a product, it becomes… Yeah, they seem way more hesitant. So maybe giving them incentives might help. I think that making this connection with the WooCommerce core team helps provide a… Like, “Hey, we’d like to share your story. You’ll still be anonymous, but we’d like to get some numbers out there.” It helps build some trust, I think, and confidence in WooCommerce as a product for the long term. We’ll see if we can help make something like that happen. I don’t know if you experience that as well, Marcel, with… If you want to write a case study or publish things that… They’re like, “Hey, you can say…” I change the names, and I usually don’t use the company name unless they say it’s okay. And it’s very rare that they say yes.

Marcel:
Yeah, there’s this concern about giving away some critical information that they took months or years to accumulate. Then simply there’s another developer who comes in and just talks about all the tricks and all the things that… Sometimes, Mike, they don’t even want to tell that it is you who worked on this particular feature because then other companies and competitors will come to you and say, “Hey, but I’ll pay double if you do the same thing for me,” and stuff like that. I understand that, but at the same time, WooCommerce is also a business, I would say, because they want advertising in terms of what clients use, what companies use WooCommerce. Two businesses talk to each other, and as you said, Mike, they will compensate for giving away that information to each other. I think there’s… Yeah, it’s a challenge.

We have obviously this challenge,

and we have NDAs, and we are more strict about talking about it because we know the nitty-gritty, and we know all the tricks, and we know what we did with the website. It would help immensely others who are struggling to scale their online shops to know how the others did it, right? That’s the whole secret about maintaining a business: “How are those guys selling ten times more than we are? What are they doing? Why is it that their website is loading in 200 milliseconds and mine is two seconds?” Yeah, I understand how challenging that can be, for sure.

Vedanshu:
Especially if you talk about scale—how many orders you are getting—it gives your competitor a direct idea of the exact revenue that you’re making, right? Or it at least gives them a ballpark, which is pretty sensitive to give away.

Mike:
And what Marcel was saying too, that there are clients that don’t want me to even announce which industry they are working in because they’re like, “You’re my secret sauce. You’re my competitive advantage, and I don’t want other people to know that you’re helping me.” Then they’re going to offer you money—double, triple, or whatever—to do the same stuff. It’s tricky. It’s very flattering; it’s a very nice compliment. But at the same time, I think when you get into freelancing and helping WooCommerce stores with performance and user experience and all of that, you’re interested in making the internet a more enjoyable place for people to shop and do stuff. If you’re sort of restricted to doing that for fewer people, it feels weird—it doesn’t feel like you’re fulfilling your mission, I guess, in the same way as you’d ideally like to.

Marcel:
100%, definitely. Vedanshu, we would have a thousand more questions to ask you. We would probably get much more technical in our questions than our audience would like us to get. But we would like to thank you very much for participating in today’s episode. It was a pleasure having you. We’re definitely going to keep in contact because, yeah, this is what we love to do. We love to have these connections with people who are, first of all, smarter than we are; secondly, who know about what’s coming in the future and what’s happening with WooCommerce; and thirdly, because you’re very friendly and very helpful in answering our questions. This is something that we all benefit from, and therefore we thank you for your participation today. It was a pleasure having you on the episode.

Vedanshu:
Thank you so much. The pleasure was all mine. I wouldn’t say anything on the “smarter” bit because I think you’re all much smarter than me. But yeah, it was a pleasure being here, talking to you, and you’re all friendly too, so yeah, it makes for a nice time. Thank you.

Marcel:
Alright, thank you so much for listening. This is our first guest that we are bringing on this new edition of Woo Have Chat. We’re going to have other guests coming up. Yeah, this is just the beginning of it, right, Mike?

Mike:
Warm-up? Yeah, yeah. During this recording, I was thinking that Vedanshu is like a performance hero. He’s helping speed up WooCommerce across countless stores, and I think we need to have more friendly, approachable, passionate performance heroes on the show and have them share their experience and stuff. So I hope you’re okay with that title. We can get you a cape if you want.

Vedanshu:
Please, please. I would go and buy a cape right now.

Mike:
What color should it be? Purple? WooCommerce purple?

Marcel:
Probably, yeah, probably. Alright, we want to thank you so much for listening, and we’ll see you in the next episode.