There's been a lot written this year about document databases as the modern alternative to MySQL, so we took a serious look at whether any of our WordPress-and-PHP-based client work would actually benefit from the switch, rather than dismissing the conversation out of hand just because it's unfamiliar.
What the argument for switching actually claims
The pitch for document-oriented databases, as we understand it from the various articles and conference talks getting attention this year, centers on flexibility, storing data as flexible, nested documents rather than forcing everything into predefined rows and columns, and on horizontal scalability, spreading data across many servers more naturally than a traditional relational database typically does. Both of those are real, legitimate advantages for the right kind of problem, and we didn't want to dismiss the idea just because it's newer and less familiar than what we already know well.
What our actual client data looks like
For the kind of relational, structured content most small business sites deal with, pages, posts, products with fixed attributes, MySQL's rigidity is a feature, not a limitation. A product has a name, a price, a category, a description, the same shape every time, which is exactly the kind of data a relational schema handles well, and exactly the kind of data where a document database's flexible schema buys us nothing we actually need, while giving up things we do rely on, foreign key constraints, joins across related tables, transactions that guarantee related updates either all succeed or all fail together.
None of our current projects have the kind of unstructured, high-write, schema-shifting data that would make a document store a clear win, logging high volumes of loosely structured event data, say, or a content type whose shape genuinely varies unpredictably from record to record in ways a relational schema would struggle to represent cleanly.
The scaling argument, and why it doesn't apply to us yet
The horizontal scaling story is compelling on paper, but it's solving a problem we don't have. None of our client sites operate at a scale where a single, properly indexed MySQL server, even a modest one, is anywhere close to a bottleneck. Adopting a technology primarily for scaling characteristics we're nowhere near needing would be optimizing for a problem that doesn't exist yet, at the cost of real complexity that does exist right now, a new query language to learn, new operational knowledge for backups and monitoring, a smaller pool of hosting options familiar with running it well.
What we actually did to test this seriously
Rather than just reasoning about this in the abstract, we spent a weekend actually standing up a document database on a spare droplet and porting a small, real piece of one client's data over to see how it felt in practice, not to ship anything, purely to move past secondhand opinions and form our own. The experience wasn't bad, the query syntax was genuinely approachable, but modeling data that has clear relationships, a product belonging to a category, an order referencing multiple products, felt more awkward than natural, requiring either duplicating data across documents or manually managing references that a relational database's foreign keys and joins handle natively.
We're not closing the door on it
We're not closing the door on it for future projects with a genuinely different shape of data. If a client ever comes to us with something that's naturally document-shaped, a content type with wildly varying structure record to record, or something explicitly needing to scale in a way our current toolset doesn't comfortably support, we'd revisit this without the hesitation we might have had before actually testing it hands-on this year.
The honest conclusion
But for now, the honest conclusion is that MySQL, tuned properly with the right indexes, still does what our clients need, and switching to a less familiar technology to chase a scaling and flexibility story that doesn't match our actual problems would be trading a known, well-understood tool for an unfamiliar one, for benefits we wouldn't actually realize. Worth revisiting the question periodically as client work evolves, but not worth adopting reflexively just because it's the technology getting the most attention in the wider industry conversation this year.
What this exercise was actually worth
Even though we ended the weekend more or less confirming what we already suspected, the exercise wasn't wasted time. We now have a firsthand, specific sense of where a document database's tradeoffs would actually bite for our kind of data, rather than a secondhand impression assembled from other people's blog posts and conference talks. That's a meaningfully different, more defensible position to hold than "we're sticking with MySQL because it's familiar," and it means the next time a client or a curious junior developer asks why we haven't switched, we have a specific, grounded answer rather than an appeal to inertia.