RDS MariaDB: what is the './tmp' directory inside the data directory?

The './tmp' directory you're seeing in SHOW DATABASES on RDS MariaDB is an internal directory used by the database engine for temporary tablespace operations. This is expected behavior and no action is required.

In MariaDB, the temporary tablespace stores temporary tables created during query execution. When these temporary tables are dropped, the space is not automatically reclaimed from the global temporary tablespace, which can cause the directory to appear non-empty even when no user-created objects exist within it.

This explains why all your metadata queries return zero results - there are no user-created tables, views, triggers, or routines in that schema. The directory contains internal temporary tablespace files managed by the InnoDB storage engine, not user objects that would appear in information_schema.

For your ISO 27001 hardening checklist, you can document this as an expected internal directory created and maintained by the MariaDB engine itself. It is not an unused or example schema - it serves an active operational purpose for the database's temporary table management. The fact that it cannot be dropped (errno 39 "Directory not empty") is by design, as the engine maintains control over this directory.

If you need to manage the size of the temporary tablespace for operational reasons, MariaDB 11.8 and higher versions on RDS support temporary file size limits through system variables like max_tmp_session_space_usage and max_tmp_total_space_usage. Additionally, you can use the mysql.rds_execute_operation procedure to shrink the temporary tablespace and reclaim disk space when needed. However, the directory itself should remain in place as part of normal database operations.
Sources
MariaDB feature support on Amazon RDS - Amazon Relational Database Service
mysql.rds_execute_operation - Amazon Relational Database Service

My understanding is differenziert from the re:Post Agent’s answer … for the OS-level error you are encountering and the path forward for your audit.

Errno 39 "Directory not empty" is a standard POSIX operating system error (ENOTEMPTY).

-> https://repost.aws/questions/QUp9Ga07WQR7KXA6TzNkYADw/drop-database-errno-39

When you execute DROP DATABASE, MariaDB deletes all recognized database files (like .frm, .ibd) and then attempts to remove the directory using the OS rmdir() command. If the directory contains files that MariaDB did not create and does not recognize (such as hidden files, logs, or artifacts left by internal RDS automation agents), MariaDB leaves them untouched. Consequently, the OS prevents the directory from being deleted.

This also explains why your information_schema queries return zero results: there are no valid database objects in that folder, only unrecognized file remnants. Resolution for your ISO 27001 Audit: Because RDS is a managed service, you do not have the underlying shell access required to inspect or delete these foreign files manually.

To satisfy your ISO 27001 control, I guess the only supported path is to open an AWS Support Case.

I would ask AWS Support to either:

• Manually clear the unrecognized files from the underlying host so your DROP DATABASE command can succeed.
• Provide a formal, written confirmation in the ticket stating that this directory and its contents are internal, AWS-managed artifacts.

You can then use the AWS Support ticket resolution as direct, official evidence for your auditor to close the control or document a valid exception.