Database · in regular use
MySQL agency in Nice
The most widespread database behind PHP sites and applications — so the one we most often meet on existing systems.
What we do with it
MySQL at our clients, concretely
It is above all a takeover skill: most of the PHP sites and applications handed to us run on it. We maintain them, put their backups back on a proper footing, and migrate when migrating is justified — rather than rewriting everything just to change engine.
The limits
When we recommend something else
On a new project we start from PostgreSQL: it covers the same needs, with stricter guarantees on the data.
Our work
Projects we delivered with MySQL
Paradigm
Platform for a Nice business centre: registered address, digitised mail, messaging and assistant.
MySQL: Platform database (MariaDB).
Read the Paradigm case studyHelioneo
Collective self-consumption platform: agreements, allocation keys, Enedis data and billing.
MySQL: Database of producers, consumers, readings and invoices (MariaDB).
Read the Helioneo case study
Method
How we bring MySQL into a project
On an application we take over, the first step is to bring the database into the project: we export its schema, version it in the repository and write every later change as a numbered migration, applied in the same order in development, staging and production. We then create separate MySQL accounts by purpose: one for the application, limited to the operations it needs, one for backups, one for administration. The single all-powerful account so common on inherited systems goes.
Developers work on a copy of the database with personal data replaced, running in a container on the same version as the server. The automated tests run against that real engine rather than a mocked database, because differences between MySQL versions, particularly around character sets and strict SQL mode, only surface that way.
In production we enable the binary log, which allows the database to be restored to a precise moment between two full backups. Handover includes an operations document: where the backups are, the restore command, and the list of accounts with the role of each.
For your business
What it changes in practice
For a business whose website or application already runs on MySQL, the main benefit is not starting from scratch. Your screens, habits and data stay where they are, and the work targets what leaves you exposed: a server nobody knows how to rebuild, structural changes made by hand with no record, one login shared by everyone. After a mass data-entry mistake or an accidental deletion, the database can be brought back to its state just before the incident rather than to the previous day.
MySQL also has a practical advantage: almost every hosting provider offers it and most PHP developers know it. A new provider finds in your repository the history of structural changes and the steps to bring the database back up, which shortens the period when nobody truly has the application in hand. If your hosting or software requires MySQL, you still end up with a sound database that can be handed on, without committing to a rebuild.
Our reading of it
What we take away from MySQL
MySQL is almost never a design choice in our work, it is a choice of context: it is the database available on every shared host, the one your current provider already knows, and the one sitting under the majority of existing sites. For a classic transactional need, it does the job without drama.
It is therefore the database we meet most often on takeover work, alongside a PHP application. Our reservations show up on complicated analytical queries and on type rigour, two areas where PostgreSQL is markedly stronger; we say so when the project allows it and the hosting can follow. Conversely, for documents with no stable shape, neither one fits and MongoDB is the more honest answer.
Decision guide
Should you choose MySQL?
Keep MySQL or move to PostgreSQL for our existing application?
Keep MySQL unless there is a specific reason not to. A PHP application that has run on MySQL for years has its code, queries and admin tooling shaped around that engine. Switching means retesting every query and often rewriting part of the data layer, for a gain users never see. We migrate when a concrete need calls for it: integrity constraints your case cannot enforce, a missing engine feature, or a rebuild that is already under way.
MySQL or PostgreSQL for a new project?
PostgreSQL. On a fresh project nothing ties you to MySQL, and PostgreSQL covers the same ground with stricter guarantees: tighter typing, richer constraints, better handling of JSON and complex queries. MySQL's case rests on compatibility, with shared hosting or a PHP package that requires it, as some CMSs do. If that describes your situation, MySQL is a perfectly sound choice; otherwise we start from PostgreSQL.
Our MySQL-backed site is slowing down: change engine or optimise?
Optimise first, almost every time. Slowness on a MySQL database usually comes from missing indexes, queries fired in loops by the PHP code, tables never cleaned out or a server configuration left at its defaults. Those causes travel unchanged to any other engine you migrate to. We go through the slow query log, fix indexes and expensive queries, then measure again. Changing engine is only worth discussing once that work is done.
Client questions
What clients ask us about MySQL
Our previous provider has vanished: can you take over our PHP site running on MySQL?
That is exactly where we meet MySQL most often. We first recover access to the hosting and the database, then take a full copy before touching anything. Next we check the state of the backups and the MySQL and PHP versions, which are frequently out of date. You get a clear picture of what works, what carries risk and what needs fixing first.
How can we tell whether our MySQL backups are reliable?
Until a restore has been tested, you cannot. We regularly find backups that stopped silently, sit on the same server as the database, or are incomplete. We set up automatic backups copied off the server, with a defined retention period, and periodically check that a restore genuinely completes on a test environment. That check is what turns a backup file into an actual safeguard.
Is an old MySQL version a security problem?
Yes, once it no longer receives patches. Vulnerabilities found after that point stay open, and a database reachable from the internet becomes a target. Upgrading is not trivial either: some queries behave differently from one version to the next. We test the application against the new version in a separate environment before switching production over, and we close direct network access to the database if it is still open.
Are MariaDB and MySQL the same thing?
Nearly, but no longer entirely. MariaDB grew out of MySQL and remains largely compatible, so much so that many hosting providers install it in MySQL's place without saying so clearly. The two engines have nonetheless diverged on certain functions and data types. Before an upgrade or a server move, we check which one you are actually running and test the application on the destination engine, so production holds no surprises.
Can we move from shared hosting to a dedicated server without losing data?
Yes, provided the switch is prepared. We install MySQL on the new server, import a copy of the database and check the application against it while the old site keeps running. On the day, we briefly pause changes, transfer the latest data, then point the site at the new server. The old hosting stays available as a fallback for a while. The new hosting is set up under your credentials, not ours.
Going further
MySQL sits within our Software development
A technology does not make a project. The method around it decides the outcome: scoping, prototypes, short cycles, and a clean way out.
Neighbouring technologies
A MySQL project in mind?
The first conversation is free. We will tell you plainly whether this technology is the right one, and if not, which is.
Updated on