Almost nobody chooses MySQL. They inherit it, and then it has to be looked after.
If your software was built in PHP or Laravel, or a vendor set it up on shared hosting some years ago, the database under it is probably MySQL. Nobody asked you. It came with the stack.
So the question on this page is rarely whether to pick MySQL. It is whether the MySQL database you already run is in a fit state, and who can work on it. The other question is what it would take to stop the reports timing out.
MySQL is a relational database. Your records live in tables with columns, the way a stock register or a customer list would, and other software asks it questions in SQL. It sits under a great deal of the business software already running in India, particularly anything written in PHP, and under WordPress.
Where it earns its place.
What it does well, once somebody looks after it
- The ordinary work of a business application: customers, orders, invoices, stock
- Being understood, because a developer who can read your schema is easy to find
- Sitting under Laravel, WordPress and older PHP systems with nothing to configure
- Read replicas, so reporting can be moved off the server that takes the orders
How we usually meet it
Rarely on day one of a new build. Usually on the day somebody sends us a login and asks why the month-end report has started failing.
- A system another vendor built and no longer supports
- A Laravel or PHP application we have been asked to maintain
- A database being moved off shared hosting onto a real server
- A business that wants an app added to software it already runs
What we usually find on an inherited MySQL database
Not a list of complaints. These are the five we look for before quoting, because they turn up again and again.
- Backups configured on the same machine, or never restored to check
- No indexes, or an index on every column, which is its own problem
- Dates, amounts and phone numbers all stored as text
- latin1 tables, so a customer name in Kannada or an emoji in a WhatsApp reply arrives as rubbish
- The application connecting as the root user, so every bug has full power
Most of these are a few days of careful work rather than a rebuild. The order matters: a tested backup comes before anybody touches a table.
What we actually do on a MySQL database
- Audit
- Backups
- Indexes
- Schema
- Queries
- Monitoring
- Reading the schema and writing down what it actually means
- Backups off the machine, with a restore somebody has watched
- Finding the slow queries and fixing the two that matter
- Migrations that can be run again without breaking anything
- Moving reporting onto a replica so billing stays quick
- Moving from shared hosting to a server we maintain
MySQL or PostgreSQL for something new
Either will carry an ordinary business application without complaining. What decides it is usually not the database at all.
- What you already run, and who maintains it after us
- Whether the reporting is going to be heavy and awkward
- Whether semantic search across your documents is coming, which pulls towards pgvector
Where MySQL is already in place and doing its job, the useful money goes on indexes and reports, not on a move.
When this is the right choice.
- You already run MySQL and want it looked after properly
- The application is PHP, Laravel or WordPress and the team knows that world
- The work is ordinary business records rather than heavy analysis
- You want the reporting moved off the server that handles orders
- You are moving off shared hosting and want the same database, better run
When it is not.
- Year-on-year analysis running on the same server that takes the payments, unless a replica is added first
- A new build where semantic search has to sit beside the records, which pgvector does inside PostgreSQL
- Data you intend to store as JSON and then query in detail, which PostgreSQL handles more honestly
- A business on shared hosting where nobody can change settings or take a real backup off the machine
Questions we are asked about it.
Should we move from MySQL to PostgreSQL?
Only when you can point at what it fixes. Wanting a more current database is not that thing. A month-end report nobody can run any more would be. Otherwise the money buys you the same records, in a different place, with a fortnight of risk attached.
Our MySQL has become slow. Does that mean we have outgrown it?
Almost never. In nearly every case we look at, it is one or two queries missing an index, or a report running against the live database at the busiest hour. The size of the data is rarely the thing that changed.
Can you work on a database another vendor built?
Yes. We start by reading the schema and writing down what each table really holds, because the names often stopped matching the meaning years ago. Then backups, then the slow queries. Nothing gets restructured before that.
Is MySQL safe for financial records?
With InnoDB tables and proper constraints, yes, and plenty of accounting software runs on it. The risk in practice is not the database but the schema: amounts kept as text, no foreign keys, and one shared login for every part of the system.
What about MariaDB?
It began as a copy of MySQL and for most business applications the difference does not reach you. We work with both. Which one you have matters mainly for hosting, tooling and the upgrade path, so we check before recommending anything.
Can our MySQL data be moved into a new system?
Yes, and that is a normal piece of work. The hard part is never the export. It is deciding what a duplicate customer is, which of three phone number columns is current, and what to do with rows nobody has touched since 2017.
Services that use it.
What it sits with.
Not sure MySQL is the right choice?
Tell us what the software has to do and who opens it. If something else fits better, we will say so, and say why.
- No obligation
- We reply the same working day
- Your details stay private