Nuffing.com

A PCI-DSS audit lives or dies on what your database logs, encrypts, and restricts, not on what your firewall does. This guide walks through the exact sequence to get a MySQL, PostgreSQL, MongoDB, or MariaDB environment audit-ready before a QSA shows up in 2026.

TL;DR

• How to prepare a database for a PCI-DSS audit in 2026 starts with scoping the CDE, not encryption.
• Requirement 10 logging failures cause more audit findings than missing patches; centralize logs 90 days before the assessment.
• PCI-DSS certified database audits catch scope creep and weak access control before the QSA does.
• Skip native DB password policies for production PCI systems in 2026; enforce RBAC with unique service accounts instead.

Why this matters

Database findings account for a disproportionate share of failed PCI-DSS assessments, and the pattern repeats every cycle: teams harden the network perimeter and forget that Requirement 3 (protect stored cardholder data), Requirement 8 (unique IDs and access control), and Requirement 10 (log and monitor access) all point straight at the database layer. A QSA doesn’t ask if you have a firewall. They ask for a list of every database user with SELECT access to the cardholder data environment (CDE), and they want 90 days of audit log history to prove it.

If your database team has never sat through a PCI-DSS assessment, the gaps show up in access control and logging, not encryption. Most teams over-invest in TDE and under-invest in Requirement 10. Mydbops runs PCI-DSS and ISO certified PCI-DSS database services for fintech for exactly this reason: audit prep is a database engineering problem before it’s a compliance paperwork problem.

What you’ll need

• A complete CDE inventory – every table, schema, replica, backup, and log stream that stores, processes, or transmits PAN, track data, or CVV. Missing a read replica is the single most common scoping mistake in 2026 audits.
• Config file access – my.cnf, postgresql.conf, mongod.conf, or equivalent, plus current audit/log plugin settings.
• An audit date – from your QSA engagement letter or internal compliance calendar. Work backward from it; most fixes below need 4 to 6 weeks of lead time.
• Encryption documentation – key rotation schedule, TDE or column-level encryption config, and who holds the keys.
• A DBA who can change production config without downtime – access control and audit logging changes touch live systems; this is where a database consulting services engagement usually gets pulled in.

The steps

1. Scope the cardholder data environment (CDE) first

Scoping tells you which databases the rest of PCI-DSS even applies to. Get it wrong and you either over-engineer systems that don’t touch cardholder data or, worse, miss one that does.

List every primary, replica, and backup instance that stores PAN, track data, or CVV, plus any staging or analytics database that receives a copy through ETL. In 2026, the most common scoping failure on compliance-heavy audits isn’t a production database, it’s a forgotten reporting replica or a QA environment seeded with production data.

Expected outcome: a signed-off CDE diagram with every database instance, replica, and backup location labeled in-scope or out-of-scope, reviewed by whoever owns the QSA relationship.

Common mistake: treating "out of scope" as a one-time label instead of re-verifying it after every schema change or new replica.

2. Encrypt cardholder data at rest and in transit

Requirement 3.4 and 4.2 require PAN to be unreadable wherever it’s stored and encrypted in transit between the application and the database.

Turn on TDE at the storage engine level for MySQL InnoDB, or use PostgreSQL’s pgcrypto or pg_tde, and enforce TLS 1.2 or higher on every connection string, including replication traffic between primary and replica. Truncate or tokenize PAN wherever full card numbers aren’t operationally necessary; most databases only need the last four digits for display.

Expected outcome: zero plaintext PAN in table dumps, query logs, or replication streams, with TLS enforced on 100% of client and inter-node connections.

Common mistake: encrypting the primary database and forgetting the same setting on read replicas, backups, or a disaster-recovery instance in another region.

3. Enforce least-privilege access control (Requirement 8)

Requirement 8.2.3 and 7.2 require unique IDs per user and access restricted to what a role actually needs. Shared "app_user" accounts with blanket SELECT and UPDATE across every table fail this every time.

Audit every database account, remove shared credentials, and map each remaining account to a named individual or service with the minimum grants that job requires. For fintech platforms in particular, database security audit services engagements usually start here, because payment schemas accumulate broad grants over years of ad-hoc fixes.

Expected outcome: a role matrix where every account is traceable to a person or a service, with no account holding write access to tables it doesn’t touch in production.

Common mistake: fixing application-layer roles but leaving DBA and monitoring tooling accounts with god-mode grants.

4. Turn on and centralize Requirement 10 audit logging

Requirement 10 needs a record of every access to cardholder data, available for at least 12 months, with the most recent 3 months immediately accessible.

Enable the MySQL Enterprise Audit plugin, Percona’s audit_log, pgAudit for PostgreSQL, or MongoDB’s native auditing, and ship logs to a central, tamper-evident store outside the database host itself. Set retention to 12 months minimum, and test that you can pull a 90-day log slice for a specific table in under an hour.

Expected outcome: centralized, queryable audit logs covering every SELECT, INSERT, UPDATE, and DELETE against CDE tables, retained for the full 12-month window.

Common mistake: enabling audit logging two weeks before the audit. You need 90 days of continuous history by the time the QSA asks for it, which makes this the step with the longest lead time on the list.

5. Patch and harden the database engine (Requirement 6)

Requirement 6.3.3 in PCI-DSS 4.0 requires critical and high-severity vulnerabilities patched within a defined window, and an unpatched CVE on a database engine is one of the fastest ways to fail a technical review.

Check the current version of MySQL, PostgreSQL, MongoDB, or MariaDB against the vendor’s security advisory list, patch anything flagged critical, and disable default accounts, sample databases, and unused stored procedures. Restrict network exposure so the database only accepts connections from the application and ProxySQL or PgBouncer tiers, never directly from the internet.

Expected outcome: no database instance running an end-of-life version or carrying an unpatched critical CVE.

Common mistake: patching production but skipping a staging or DR replica running an older engine version; QSAs check both.

6. Validate backup encryption and retention (Requirement 3.4, 9.5)

Encryption and retention rules extend to backups, not just live databases. An unencrypted backup file sitting on a shared drive is a full-scope finding on its own.

Confirm every backup job encrypts the output, verify the encryption key isn’t stored next to the backup, and check retention against your data retention policy rather than just your recovery-point objective. Restore-test at least one backup before the audit; a backup that can’t restore doesn’t count as a control.

Expected outcome: every backup, including cross-region and cold-storage copies, encrypted with keys managed separately from the storage location.

Common mistake: encrypting nightly backups but leaving an old manual export from a migration project sitting unencrypted on a file share.

7. Run a pre-audit vulnerability and configuration scan (Requirement 11.3)

Requirement 11.3 requires quarterly internal vulnerability scans and an annual penetration test. Running one against the database tier before the QSA does is the cheapest way to fix findings on your own terms.

Scan for default ports, weak TLS ciphers, missing patches, and misconfigured grants, then re-run the scan after remediation to confirm a clean pass. Budget one to two weeks between the scan and the audit date to fix what it finds.

Expected outcome: a documented scan report with zero open critical or high findings on any in-scope database.

Common mistake: scanning the production database but skipping the ProxySQL, HAProxy, or connection-pooling layer in front of it; that layer gets audited too.

8. Document everything the QSA will ask for

A QSA works from evidence, not intent. A control that isn’t documented with a timestamp and an owner might as well not exist during the interview.

Assemble the CDE diagram, access control matrix, audit log samples, patch records, encryption key management policy, and backup test results into one package before the assessment starts. Assign one owner who can answer follow-up questions on each document without pulling in three other people.

Expected outcome: a single evidence folder that maps one-to-one to the PCI-DSS requirements being tested.

Common mistake: having the right controls in place with no paper trail proving when they were implemented; QSAs test for "since when," not just "does it exist."

Troubleshooting

• Audit logs are eating disk space fast. Ship logs off the database host to a log aggregator or object storage with lifecycle rules. Don’t disable logging to save space; that’s a bigger finding than the storage cost.
• A legacy MySQL 5.7 instance is past end-of-life and can’t be patched. Isolate it behind stricter network controls immediately and put a migration date in the audit evidence package. QSAs accept a documented remediation plan more readily than silence.
• A shared database mixes CDE and non-CDE data. Segment by schema or move non-PCI workloads to a separate instance. Mixing scope inflates the audit and increases the chance of a finding bleeding across systems.
• Native database password policies don’t meet Requirement 8.3.6 (12+ characters, complexity). Enforce policy at the identity provider or connection layer instead of relying on database-native password rules, which are inconsistent across MySQL, PostgreSQL, and MongoDB.
• A connection pooler sits between the app and database and isn’t covered by any audit log. Add logging at the proxy layer too; QSAs increasingly ask for the full connection path, not just the database engine.
• Backup encryption keys are stored in the same bucket as the backups. Move keys to a separate KMS or vault; co-located keys and backups fail Requirement 3.4 on inspection.

Tools and resources

• MySQL Enterprise Audit plugin or Percona’s audit_log plugin for MySQL and MariaDB installations
• pgAudit for PostgreSQL, tuned to log DML on CDE tables specifically to avoid log bloat
• ProxySQL or PgBouncer configured with connection-level logging in front of the database tier
• pt-query-digest and Percona Toolkit for auditing query patterns against CDE tables before the scan
• E-commerce platforms processing card payments directly on the database layer carry particular scoping risk; see the MySQL RDS audit-log retention guide for a practical retention and archival pattern that supports PCI-DSS logging without unnecessary storage cost

What to do next

Once the database-specific controls above are in place, audit prep expands to application-layer tokenization, network segmentation, and vendor risk management, all dependent on the CDE inventory built in step one. Teams operating high-volume MySQL RDS workloads can review the Swiggy AWS DMS RDS case study; the same audit-prep principle applies: nail the CDE map before anything else.

FAQ

What is PCI-DSS Requirement 10 for databases?

Requirement 10 requires you to log and monitor every access to cardholder data, including who accessed it and when. For databases this means audit logging on every SELECT, INSERT, UPDATE, and DELETE against CDE tables, retained for at least 12 months with 3 months immediately accessible.

How long must database audit logs be retained for PCI-DSS?

PCI-DSS Requirement 10 requires 12 months of audit log history, with the most recent 3 months available for immediate analysis. Logs older than 3 months can move to colder storage as long as they’re retrievable within a reasonable window.

Does encryption at rest satisfy PCI-DSS Requirement 3?

Encryption at rest covers part of Requirement 3, but you also need key management separate from the encrypted data, truncation or tokenization where full PAN isn’t needed, and encryption extended to backups and replicas, not just the primary database.

Can a shared database pass a PCI-DSS audit?

A database mixing cardholder data with unrelated workloads can pass, but only if access controls and logging are scoped to the CDE tables specifically. Most teams find it faster to segment the CDE into its own schema or instance than to prove isolation inside a shared one.

How much does a PCI-DSS database audit cost in 2026?

Cost depends on the number of in-scope database instances, the QSA’s scope, and how much remediation is needed before the assessment starts. Check current pricing directly with your QSA or compliance partner rather than assuming a flat rate.

What database engines are PCI-DSS compliant?

PCI-DSS doesn’t certify specific database engines. MySQL, PostgreSQL, MongoDB, MariaDB, and MSSQL can all pass an audit when configured with encryption, access control, and Requirement 10 logging in place. Compliance is a configuration and process outcome, not a feature of the engine itself.

How long does PCI-DSS database audit prep take?

Most database audit prep takes 4 to 6 weeks minimum, driven mainly by the 90-day audit log history Requirement 10 expects to see by assessment time. Scoping and access control cleanup can move faster, but logging history can’t be backfilled.

Is MongoDB PCI-DSS compliant?

MongoDB can support a PCI-DSS compliant deployment when native auditing, field-level encryption, and role-based access control are configured correctly. The database itself isn’t compliant out of the box; the configuration and monitoring around it determines the audit outcome.

One last thing

The finding that kills most database audits isn’t encryption, it’s Requirement 10 logging turned on too late. Teams spend weeks hardening TDE and TLS, then discover during the audit that centralized audit logs only cover the last 3 weeks instead of the 90 days a QSA expects. Turn on logging the day audit prep starts in 2026, not the week before the assessment.

Need a PCI-DSS ready database review?

PCI-DSS and ISO certified audits across MySQL, PostgreSQL, and MongoDB.

Most teams believe they have a solid backup strategy. In practice, many have a backup process they set up once, have not tested recently, and would discover is broken only when they actually needed it most. 

This guide covers how to build a MySQL backup strategy that works reliably — not just in theory, but when it counts.

The One Rule That Matters Most

An untested backup is not a backup. It is a file you hope works. 

Before anything else, commit to testing your restore process at least once a month. Everything in this guide supports that goal.

Your Three Backup Options

Logical backup (mysqldump) exports your database as SQL statements. It is portable, straightforward, and easy to restore individual tables or databases from. Use –single transaction with InnoDB tables to avoid locking:

mysqldump –single-transaction mydb > mydb_backup.sql

Physical backup copies the raw database files. Faster for large databases, but must be restored to the same MySQL version and platform. Minimal locking, supports incremental backups. 

Binary log backup records every change to the database continuously. Combined with a full backup, binary logs let you restore to any point in time — not just the last full backup snapshot.

Designing Your Strategy

Three questions define your backup strategy: 

RPO and RTO Explained

Know both numbers before an incident, not during one. If restoring a full backup takes 6 hours and your RTO is 2 hours, you have a problem to solve before it becomes an emergency.

Automate Your Backups

Manual backups fail when people are sick, busy, or on vacation. Automation removes the dependency on memory.

Linux Automation 

A basic automated backup script using cron and mysqldump:

#!/bin/bash 
DATE=$(date +%F) 
mysqldump –single-transaction –all-databases \ 
| gzip > /backups/mysql/backup_$DATE.sql.gz 
if [ $? -ne 0 ]; then 
echo “Backup failed on $(hostname)” \ 
| mail -s “ALERT: MySQL Backup Failed” [email protected] 
fi

Scheduled via cron to run nightly at 2 AM:

0 2 * * * /usr/local/bin/mysql_backup.sh

Windows Automation with SQLyog

On Windows, SQLyog provides built-in backup scheduling with no scripting required. Configure the databases, output location, and schedule through the GUI. SQLyog handles execution and can send email notifications on completion or failure.

Compress and Protect Backups

Compress every backup before storing it. SQL dumps compress extremely well — typically 70–90% size reduction. Pipe mysqldump output through gzip:

mysqldump mydb | gzip > mydb_backup.sql.gz

For backups stored offsite or in cloud storage, encrypt them. A backup file containing sensitive data is a liability if storage access is ever misconfigured.

The Backup Checklist

Monitor Backup Health

Automated backups still need oversight. Common failure modes to watch for:

MONyog can alert you when disk space on monitored servers approaches a critical threshold — catching the “disk full” failure mode before your next backup runs.

Want to automate MySQL backups without writing scripts? Try SQLyog free and set up your first scheduled backup in minutes.

Frequently Asked Questions

In May we hosted the first MySQL Contributor Summit 2026. We arrange such Summits every quarter, and it’s a forum where contributors come together and make proposals, and then discuss them, on what they wish to work on, or see someone else work on, in future MySQL versions. 

All of the presentations are now published as well, so you can follow the discussion even if you weren’t at the summit yourself. 

Proposed features were categorized into 4 work streams, and you can now find each of them on the MySQL Community Roadmap project board on GitHub. 

Why is this important? 

Nurturing an active contributor community is an important factor in the success of the MySQL open-source project. There are many ways and reasons you can contribute to MySQL:  

1. To avoid having to maintain a patch, which fixes some problem you had with MySQL 

2. To increase your career market value and professional development

3. To get feedback and users for your ideas and projects, as MySQL is the most wide-spread open source database 

Regardless of your reasons, MySQL thrives off of your contributions. With your contributions:  

• Bugs get fixed faster and more efficiently,  

• Users can gain custom features that were requested by users, but that would never have been developed if the only option was to wait for the MySQL engineering team at Oracle to do it, 

• MySQL can be a platform that helps you and your ideas reach and collaborate directly with a much larger user community 

• Can grow a larger base of developers, who over time grow into senior MySQL or database developers 

Where can you participate? 

To follow what’s happening , or better yet, if you want to participate in the planning and development of the next version of MySQL , the best place to start is MySQL Community GitHub Discussions . These GitHub discussion threads are the central point for discussions related to actually writing code that goes into MySQL Server. But the discussion is not just about code, rather also including technical topics, proposals, roadmap feedback, and contribution process related questions.  

The MySQL Community Slack is a popular space for general community discussions and engagement. In other words, this is a good place for general discussions related to using MySQL as your database. 

Depending on your intended level of involvement, you should also sign up for a centralized Oracle user account, which gives you access to the discussion forums, the MySQL bug database, and other MySQL services. We keep maintaining the good old bugs database, and it will remain relevant but we will use GitHub issues for new development of features.   

And last but not least, more static information is found on the MySQL Community project’s Wiki. Here you can find the new MySQL Governance Model, the Developer Guide, The developer guide takes you through the whole process of submitting a Feature Request or Proposal, and all the way to a Pull Request. 

More resources about contributing to the MySQL community are also available in the Developer Zone on mysql.com. 

Early Access releases and Monthly Code Drops 

As reported on June 25, we now have a documented governance process, that is based on the assumption that there will be contributors, committers and project leads from various employers, and hopefully also some participating as their individual self. 

We have made two Early Access releases, 9.7.0 Early Access and 26.7.0 Early Access. Work is already underway to match those releases with a monthly code drop. This is of course essential for anyone who wants to work on some code contribution, to have a relatively recent snapshot of the MySQL source. A lot of work is also going into setting up all the workflow automation into the mysql-server github repository. 

Only when all of that is done, and operating somewhat smoothly, is it time for the open development of the MySQL development work to happen working live in the public mysql-server repo. This is scheduled to happen later this year in Phase 3 of the Community Engagement Plan. But for now we are already in good shape to receive pull requests from the MySQL community as part of Phase 2! 

From talks to action! 

So what is actually happening on the development frontier, now that we know where to look? Let me give you a quick summary of where each of those work streams are, at this moment in time. 

But first…MySQL 26.7. is out, and we are excited to report that the first improvement arising out of the May Contributor Summit, (Bug #119222 ) is already merged and will be part of the 26.7. release. The patch is a performance improvement for how MySQL returns data back to mysqlsh after a mysqlsh util.dumpInstance() call. In case of composite primary keys, it now uses all the primary key columns to break the result set into a smoother, more evenly distributed sequence of chunks. 

The authors of this first patch to make it into a release, are Sveta Smirnova and Kamil Holubicki from Percona! 

Percona – as most readers will know – have over the years already contributed many bug fixes and features to MySQL Server. So it is perhaps no surprise that they were quick to do one also in this new era of community contributions! 

Thank you Percona! And we hope to see many more contributions, small and large, as we continue to develop new versions of MySQL, together and in the open. 

AI and Cloud 

Most of the focus here is on bringing full featured vector indexes, distance functions and search, to MySQL. There were several alternatives on the table in the past months, that have been discussed back and forth. So far there seems to be consensus on the direction that this should be implemented natively, as a builtin index type that is a first class citizen both as far as extending the SQL syntax and parser, and the query optimizer are concerned. 

The design phase is still ongoing, and the team is looking into different vector index structures and algorithms in the field. In addition the the widely used HNSW (Hierarchical Navigable Small World) algorithm, there’s considerable interest in an algorithm developed at Google and known as ScaNN (Scalable Nearest Neighbor). Following the syntax design discussion, it also is looking increasingly likely that the team is thinking of supporting multiple different index  types. 

Notably there also exists a project by Alkin Teyzusal called MyVector, that is implemented as a MySQL Plugin and User Defined Function. We’ll take a closer look at both of these vector indexing algorithms and implementations in the next blog post. 

With vector support clearly leading the way as a high priority work item, there’s also a second projectin this category: Official MCP Server for  MySQL. 

This will allow various LLM based assistants and coding agents to access and explore MySQL in a standard way. The first version will be “read-only” in the sense that it is focused on exposing metrics for observability and on the other hand allowing the AI agents to discover the schema and query the data. 

Performance and Observability 

Performance improvements remain a constant topic of interest in the MySQL user community. As we have met with many of you both individually and at events like the contributor summit, often the leading topic are various performance improvements. 

Currently in the GitHub backlog there are a range of sub-components of the MySQL Server, ranging from InnoDB B+Tree performance to Replication, where contributors proposed performance improvements. But hhere are a couple of interesting themes I thought are worth highlighting: 

As a former sales engineer it warms my heart to see proposal from AWS separate performance improvements into “real issues”, that actually happen and cause problems in production, and “perceived problems”, that aren’t really a big problem in production, but cause the database to perform poorly in benchmarks.  (In this case, HammerDB.) So with that introduction, you might be thinking the proposal wanted us to focus on the issues that make production slower. But no, the whole point was that users evaluate databases with benchmarks, or at the very least they read about others who did run a benchmark. And this makes the “perceived” problem a very real problem, because it may cause the user to choose some other database, and then they won’t run MySQL in production at all! 

And what is it that promises not just 2x or even 4x improvement in HammerDB  results just like that: the RETURNING Clause. More specifically this is an extension to DELETE and UPDATE. If you add the RETURNING clause to a DML command, then you will be able select the column who’s values are returned to the caller. In practice this means you avoid doing a separate SELECT, since you can get the result within the single UPDATE or DELETE statement. Single roundtrip instead of many! 

In #24 InnoDB-based binary log Vinicius Grippa from ReadySet, presented a proposal to move the entire binary log inside of InnoDB. The main point of this move would be that for the typical MySQL transaction, both the tables and the binlog are now inside and managed by InnoDB, without the need for coordinating an XA-transaction between 2 separate subsystems. And in particular, removing the need for each of those subsystems doing their own fsync to disk. This ticket is one of the most active ones, with engineers from Oracle, Google and Alibaba discussing different approaches. 

The Hypergraph optimizer continues to receive a lot of attention. On the one hand there are improvements to the explain output and other observability improvements. Ultimately the goal is to make this optimizer strictly faster than the old MySQL optimizer for every conceivable use case. 

Issue #34 describes a service that should monitor also system events, such as disk or memory utilization. At first sight this appears to be an unnecessary feature, since there are already plenty of tools available that know how to monitor the Operating System. But it turns out that a) when you are diagnosing a database, in production, the server may not have the tools installed that you are used to working with, nor is it possible to easily install them either, and b) it’s just really convenient to have system level performance metrics available through the same channel where you get your database performance metrics from too. A single source for all your dashboards and performance comparisons. 

Developer and DBA Experience 

MySQL Workbench work falls under the Developer and DBA Experience bucket and issue #10 covers various updates needed to this popular GUI tool. 

Issue #12 captures a long standing topic that was also brought up at the Contributor Summit: In MySQL the keyword BOOL and BOOLEAN are really just aliases for TINYINT(1). It also proposes to add ARRAY and UUID as native data types. 

There’s a built-in tension in that discussion, since generally we encourage new datatypes to be developed as components! But for very primitive types like booleans and arrays, there’s still an argument they should be always available and therefore in the native set. 

A very interesting feature in this category is the proposal to add System versioned tables to MySQL. This means the capability to define snapshots in time of a table, and makes it possible to query past snapshots of the table. The proposal is to implement this as defined in the SQL:2011 standard. 

Extensibility and tooling 

A well designed modular architecture is important for any software project, but doubly so for popular open source projects. The MySQL Component framework is what allows contributors to create new data types, functions, and of course even entire storage engines, in a relatively independent fashion. To ensure that we can scale MySQL as an open source project, we will have to continue to evolve the MySQL Component Framework. 

MySQL was always modular 

Over its 30 year history, MySQL has introduced several frameworks that allow new functionality to be developed in a modular way. Most famously of course MySQL gave us the concept of pluggable storage engines, which has allowed developers of different database engines to benefit from MySQL providing the standard SQL user interface and functionality, and MySQL and MySQL users in turn benefited from having a rich collection of database engines packaged into a familiar user experience, yet allowing them to choose the best tool for each job.  

Another extension framework that’s been around for a long time is the API for adding User Defined Functions. UDFs allow users, or open source contributors, to extend the set of functions – both scalar and aggregate functions – from the default / built in set.  

MySQL 5.1 introduced the Plugin API, which made it possible to distribute and install features separately from the MySQL Server itself.  

MySQL Component Framework 

And finally from MySQL 8.0 onwards we have introduced the MySQL Component Framework, and since then every major version has added APIs to various aspects of MySQL Server functionality, that can be extended with components. For example various methods for password validation, or logging and auditing, have been implemented as components.  

The main improvement that components bring to the table: a well defined and enforced API. While for example the storage engine API is well defined in the sense that a storage engine needs to implement and provide certain things, it’s nevertheless the case that a storage engine plugin or a UDF plugin are loaded and live in the same address space as the rest of mysql-server. In principle there’s nothing stopping a plugin from calling any function and accessing any data it wants to. 

Components on the other hand do operate against an API, and these client components can only use the methods made available through that API. Of course, there are a couple hundred different such APIs – called services – so a component could call many of those APIs to do what it needs to do. 

Doubling down on the MySQL Component Framework 

Following the contributor summit, the focus has been on doubling down on the MySQL Component Framework as the mechanism to write extensions to the core MySQL server. There are still areas of the MySQL Server that aren’t yet available through MCF APIs. A big one is the query optimizer (#22).   

But what contributors have focused their efforts on so far is a feature that at the same time is much more basic and fundamental, and on the other hand is actually quite sweeping: User Defined Types (#674). The goal here is not just to allow end users to define new custom types for their use cases, but the goal is to make this API so complete and useful, that also built in (aka “native”) types could be implemented as components, without loss of functionality. 

For example the Vector data type has been mentioned as an example: The work to add Vector support is implementing it as a native or built in type, because it is such an important and widely requested feature. But this should not be a choice we need to make. In the future, there should not be any downsides to adding a type via the Component Framework. 

A vision for MySQL extensibility 

While current work is mostly focused on extending the “surface area” of MySQL Component Framework, we are also aware that this is nowhere near the full scope of what we need to build in the coming years. 

The ultimate power of the Component Framework is not just its use as a healthy way to practice good, modular, software architecture. The real goal is to unleash a mode of contributing to MySQL Server in a way where a majority of new code and features needn’t be contributed to the core MySQL server at all. In the future, a typical MySQL “contribution”: 

• Should be possible to create and develop independently, without needing to coordinate or get “permission” with anyone employed at Oracle 

• (In fact…) Should be possible and quite okay for two contributors to both implement the same feature, in slightly different ways, and let the users decide which one they want to use 

• Should be possible for such extensions to clearly declare which component APIs they need to use, which they implement, and which versions they are compatible with 

• And probably we need to have a way for one component to express the fact that it needs another component to be present. (dependencies) 

• Finally, it should be possible for the independent 3rd party developer to publish their extension to MySQL functionality, and for end users to discover and install the extension, pretty much just as easily as they had installed core MySQL itself. 

A great example of a project that is showing us the way is MyVector, by Alkin Tezuysal. Alkin presented a talk on his experience implementing HNSW based vector indexing in MySQL, using the MySQL Component Framework. 

Utilities are extensions too 

But the above is not yet all: MySQL Server can also be extended by software that is completely separate from the MySQL Server. A great example are the different *SQL Proxy products that have provided us with so many powerful features from thread pooling to encryption.  

Tools used for observability, schema design, querying, reporting, dashboards… Various shells and clients… All of these are arguably “components” that extend and add value in the MySQL Ecossystem. 

And Storage Engines! 

While most of the development focus in the extensibility track is on extending the MySQL Component Framework, we shouldn’t forget that MySQL already has the tried and trusted framework that gave us so much cool database innovation over many decades already, The Storage Engine API. 

Our efforts to open up MySQL development to community contributions would not be complete without someone proposing to add a new storage engine. And we couldn’t be more excited about the fact that in the past weeks we’ve added not just one, but two, rather powerful and very state of the art engines to our roadmap dashboard: DuckDB (proposed by Alibaba), the database that has been taking the analytics / OLAP market by storm, and TidesDB, a new and very state of the art LSM engine. LSM architecture is typically used for write-optimized, MVCC type OLTP workloads. 

Both of these are scheduled to present at the next Contributor Summit.  

Upcoming Contributor Summits 

If you’ve read this far, and if you are anywhere near as excited as yours truly… You might be asking the question: When and  where are these contributor summits happening and where can you buy tickets? 

The answer is that these are by invitation request; if you would like to attend, reach out to the Community Team. These events are by and for developers who already are working on new MySQL features, or have made a proposal that they will be presenting and getting feedback on. 

The next summit is just around the corner: 

•  August 5-6 in Colorado and virtually. 
• November will be a 100% virtual summit 
• February will be in Europe and adjacent to Fosdem and MySQL Belgium Days 
• And after that likely in May at a location still to be determined

If you are working on or intend to propose some contribution to MySQL, and you would like to present in the contributor summit, or attend a summit, you can email HENRIK.INGO@ORACLE.COM or LENKA.KASPAROVA@ORACLE.COM.  

Get Involved 

And if you just want to roll your sleeves and start submitting issues and PRs… Sure, you can do that, there’s no hard requirement to present slides first. You can create a proposal in the mysql/mysql-community repo, and when you are ready to submit your first Pull Request, you’d typically do that against trunk in the mysql/mysql-server repo. 

And as a reminder, to try to keep some focus while we open up the development, we’ve chosen four strategic roadmap categories. As you submit your proposals, try to think of which of these your contribution most closely fits into: 

In the following blog posts I want to dive deeper into each of these four work streams, and give a bit more context around the rather technical discussions you will see if you start following the discussions in each ticket. Stay tuned for the next episode in MySQL development as it happens. 

Henrik started his career in open source databases working at MySQL AB, shortly after graduating from college. Now, two decades and seven other database startups later, he is back to where he started, on the Oracle MySQL team. Prior to Oracle, he worked at DataStax where he led the project of porting DataStax Enterprise features back into the open source Apache Cassandra project, and at MongoDB, where he introduced the use of change point detection to automate discovery of performance regressions. Henrik is the author of the book “Open Life: The Philosophy of Open Source”, and its namesake blog.

Dentists might soon have an easier option on hand to treat the dreaded cavity.

Researchers at the University of Michigan conducted a large-scale Phase III trial testing out a liquid form of fluoride on children’s cavities. Compared to placebo, the treatment was significantly better at preventing further tooth decay and avoiding the need for more invasive options like fillings or surgery.

The findings show that liquid fluoride can be an effective “noninvasive treatment for young high-risk children and [support] its consideration for FDA drug approval,” the researchers wrote in their paper, published in July in JAMA Pediatrics.

Currently off-label

Cavities (also called caries) are holes caused by bacteria that erode the protective surface of our teeth. Though people these days might be taking better care of their teeth than in the past, more than 40% of children in the U.S. still develop some level of teeth decay. Cavities are usually treated using fillings, but in more severe cases where the decay penetrates deeper and causes an infection, people will need a more invasive root canal or even a complete removal of the affected teeth.

Fluoride has long been known to help prevent cavities, which is why governments in many parts in the world add small amounts of it to their drinking water supply. It also seems to be effective at preventing, or arresting, the further progression of existing cavities. Many countries have approved certain fluoride-based treatments, such as silver diamine fluoride (SDF), to prevent worsening cavities. Notably, however, this list doesn’t include the U.S.

In 2014, the Food and Drug Administration did approve SDF for treating tooth hypersensitivity, which allowed dentists to use it as an off-label treatment for cavities. Two years later, in 2016, the FDA designated SDF as a “breakthrough” therapy, a label intended to speed up the review process for treatments that can meet an urgent need. Without high-quality evidence of its safety and effectiveness, though, the FDA is unlikely to ever approve SDF for this use.

This current trial, funded in part by the U.S. National Institutes of Health, is meant to help provide that evidence.

Solid evidence

The trial involved 830 children under the age of six with severe early childhood cavities. Half of the children were randomized to get a placebo, and the remaining were given a 38% formulation of SDF, applied directly to the affected teeth via a small sponge-filled tip. People received treatment at the start of the study and a second dose six months later. The children were evaluated for cavities over the next eight months.

Ultimately, 70% of children completed the study in full. By the eight-month mark, about 50% of the children treated with SDF showed no progression of their cavities, compared to 17% of children given a placebo.

SDF is known to cause a permanent darkening of the teeth (an effect of the silver). That said, reported adverse events were similar between the two groups. This cosmetic side effect is also likely to be less worrying for children who will eventually lose their baby teeth.

The team’s findings should help strengthen the case for the FDA’s approval of SDF, the researchers say.

“If we want more children and families to benefit from this treatment, we need rigorous evidence showing both that it works and that it’s safe,” said lead author Margherita Fontana, professor of dentistry at the University of Michigan School of Dentistry, in a statement from the university. “From a public health perspective, if we want broader implementation across the United States, including in medical settings, we need carefully collected data in U.S. populations, and we now have that.”

Though the primary use of SDF is likely to be for very young children, it might also be a helpful stopgap for adults who are unable to get or afford other treatments.

“For almost anyone, this can arrest the decay and stop the infection and the pain it causes,” Fontana said. “This could benefit many people.”

August 1st, 2026 | Tech |

McDonald’s fast food restaurants in China sell limited edition backpacks with side pockets for large Fries and ketchup.

Designed with iconic McDonald’s colors and Golden Arches, the backpack features oversized side pockets that hold large servings of fries.

Shoulder strap includes a built-in storage loop for holding ketchup packets.

Instead of telling people to love fries, McDonald’s created a backpack that lets fans literally carry and display their love for fries wherever they go.

Big Fries Backpack celebrates fast food and does not take itself too seriously.

Most backpacks are designed to carry books, laptops, or clothing. This one proudly makes room for McDonald’s fries.

Included shoulder-strap fry holder allows people to snack hands-free while walking, almost like a wearable dining system.

Also check out: McDonald’s Fries Crosswalk