How PHP Upgrades Affect Direct Database Connectivity (MySQL, SQL Server, Oracle and PostgreSQL)

Home › Blog › How PHP Upgrades Affect Direct Database Connectivity (MySQL, SQL Server, Oracle and PostgreSQL)

By the DESSS Team | Updated November 2026

When a PHP upgrade goes wrong, the first thing that usually breaks isn't the homepage. It's the database connection. One minute your application is running, the next it's showing "could not find driver" or "authentication method unknown to the client".

That's because PHP talks to your database through extensions and drivers that are tied to a specific PHP version. Change PHP, and every one of those pieces has to line up again. With the PHP2Shell security fixes (October 21, 2026) and PHP 8.2's end of life (December 31, 2026) pushing many teams to upgrade, here's what to expect for each major database, and how to keep your data flowing. The background is in our news summary PHP Upgrade 2026: What Just Happened.

Why the database is the first thing to break

Your PHP application usually connects to its database directly, through one of these:

• mysqli or PDO_MySQL for MySQL and MariaDB
• sqlsrv or PDO_SQLSRV for Microsoft SQL Server
• OCI8 or PDO_OCI for Oracle
• pgsql or PDO_PGSQL for PostgreSQL
• ODBC for everything else

Each of these is compiled for a specific PHP version. Upgrade PHP without installing the matching driver, and the connection simply fails. On top of that, newer PHP versions change how drivers report errors, and newer databases drop older login methods.

There's a security angle too

PHP2Shell (CVE-2026-109618 and CVE-2026-109619) lets an attacker run code on your web server. Once they're on that server, your database is next.

So patching PHP isn't just about the website. It's about protecting customer records, orders and anything else in your database. If you suspect a server was exposed before it was patched, rotate your database passwords.

MySQL and MariaDB

Authentication changes

MySQL has been phasing out its old login method, mysql_native_password:

• MySQL 8.4 no longer loads it by default.
• MySQL 9.0 removed it entirely.

PHP supports the newer caching_sha2_password from PHP 7.4 onward. Older PHP (7.3 and below) simply can't log in to MySQL 9. If you upgrade MySQL and see "Plugin 'mysql_native_password' is not loaded", switch the user to the new method:

ALTER USER 'app_user'@'%' IDENTIFIED WITH caching_sha2_password BY 'new-password';

Errors now throw exceptions

Since PHP 8.1, mysqli throws exceptions on errors by default instead of quietly returning false. Older code that checks if (!$result) never reaches that check. Instead, users see a fatal error. Wrap database calls in try/catch and log the error.

Deprecations to clean up

• PHP 8.5 deprecates the PDO::MYSQL_ATTR_* constants.
• PHP 8.6 deprecates mysqli_stmt_init().
• The original mysql_* functions were removed back in PHP 7.0. If an old app still uses mysql_connect(), it needs a rewrite to mysqli or PDO before any modern upgrade.

Microsoft SQL Server

SQL Server connectivity is the most common blocker we see on Windows, and it trips up Linux servers too.

• Driver versions matter. Microsoft Drivers for PHP for SQL Server 5.13 (released March 2026) support PHP 8.3, 8.4 and 8.5, and dropped PHP 8.1 and 8.2. Version 5.13.1 (April 2026) fixed a security issue where access tokens could leak between pooled connections.
• The ODBC driver is required. The PHP drivers sit on top of Microsoft ODBC Driver 17 or 18 for SQL Server. Install it first.
• Certificate errors on ODBC 18. ODBC Driver 18 encrypts connections by default. If your SQL Server uses a self-signed certificate, connections fail with a certificate trust error. The right fix is a trusted certificate. TrustServerCertificate=yes works as a short-term workaround on internal networks only.
• Windows DLLs must match exactly. php_sqlsrv and php_pdo_sqlsrv DLLs must match your PHP version, NTS or TS build, and x64 or x86.
• Older operating systems are out. The 5.13 drivers no longer support Windows Server 2012 and 2012 R2.

Oracle

Since PHP 8.4, the OCI8 and PDO_OCI extensions are no longer bundled with PHP.

Both need the Oracle Instant Client installed on the web server. If you upgrade to PHP 8.4 or later and Oracle connections suddenly fail with "call to undefined function oci_connect()", this is why. Plan the Instant Client and extension build as part of the upgrade.

PostgreSQL

PostgreSQL is usually the smoothest. Install the matching package for your new version (for example php8.4-pgsql) and you're mostly done. PHP 8.4 introduced driver-specific PDO classes such as Pdo\Pgsql and Pdo\Mysql, plus a new PDO::connect() method.

Quick reference

How DESSS helps

Database connectivity is where our PHP and database teams work side by side. Our Database Administration (DBA) and Oracle DBA specialists, together with our PHP developers, can:

• Audit your PHP-to-database connections, drivers and credentials
• Upgrade MySQL, SQL Server, Oracle and PostgreSQL drivers alongside PHP
• Update legacy code (including old mysql_* functions) to mysqli or PDO
• Secure connections with least-privilege accounts, TLS and firewall rules through our Cybersecurity team
• Handle full application migrations and system integration when an upgrade turns into a modernization

Request a customized quote

Tell us which databases your PHP applications use, your current PHP and database versions, and where they're hosted. We'll come back with a plan and a quote tailored to your environment.

Request your customized PHP and database upgrade quote

Disclaimer

The information in this article is provided for general informational and educational purposes only. It reflects publicly available information as of November 4, 2026. PHP versions, support dates, security advisories and third-party software change often, so always confirm details with official sources such as php.net and your software vendors before making changes.

This article is not professional, legal or security advice, and following these steps does not guarantee protection against every vulnerability or compatibility issue. Always back up your systems and test upgrades in a staging environment before applying them to production. DESSS, Inc. is not liable for any loss, damage or downtime resulting from the use of this information.

Product names and trademarks mentioned (including PHP, Microsoft, Windows, IIS, SQL Server, Oracle, MySQL, MariaDB, PostgreSQL, Ubuntu, Debian, Red Hat, cPanel and Plesk) belong to their respective owners and are used for identification only. Links to third-party sources do not imply endorsement. Please also see the DESSS Disclaimer and Privacy Policy.