Database audit

Database Health Check

Audits the security and configuration health of your database servers and reports risky settings.

9: supported database engines
Configuration: permissions, settings, patching
Performance: indexes, queries and resource health
Narrative report: Turkish/English summary and recommendations

Why it matters

When a database breaks, the entire system is lost.

The database is the company's nerve center: customer data, transaction history, financial records live there. A misconfiguration or missing patch can lead to data loss, leaks or service outages. The problem is that the database is left to the systems administrator, but they may not fully understand permission rules, performance bottlenecks or which patches are missing. The result is forgotten settings and incomplete audits.

Who has audited your database configuration for errors and when?
When a critical security patch is found, is your database server updated that morning?
Do you even know when performance issues (slow queries, index bloat) began days ago?

What it does

What it does.

Multi-engine support

SQL Server, PostgreSQL, MySQL, MariaDB, Oracle, MongoDB, Redis, Elasticsearch and ClickHouse — all engines are audited from the panel.

Configuration audit

Permission rules, user rights, security settings, encryption configuration — missing or misconfigured settings are found and flagged.

Patch status

Database version and missing security updates are checked — which patches need to be applied and which are already loaded is shown.

Performance metrics

Query time, disk I/O, memory usage, open connections — tracked as time-series with trend detection and anomaly alerts.

Index health

Missing indexes, unused indexes and fragmented indexes are identified — how query performance can be improved becomes clear.

Finding details

Each issue is given a title, summary, evidence and remediation guidance. Simple issues come with ready scripts; complex ones are explained.

Narrative report

Audit results are transformed into Turkish or English summaries by the narrative layer — ready to present to management.

Audit trail

All audits are logged — when, by whom, what was found and remediated — providing evidence for compliance reports.

How it works

From setup to report.

01
Add the database

Create a new database record in the admin panel by entering connection details (host, port, credentials, engine type).
02
Start an audit scan

Scanning can be scheduled or run manually. The scan connects to the database and collects configuration and performance data.
03
Review findings

The panel lists configuration errors, patch deficiencies and performance issues. Each finding shows evidence and recommendations.
04
Apply fixes

Simple issues have automated scripts — one-click remediation is possible. Complex issues require manual intervention.
05
Prepare report

Scan results are transformed into summary reports by the narrative layer. Turkish or English reports are presented to management and auditors.

Technical details

The specifics.

Supported engines: Microsoft SQL Server, PostgreSQL, MySQL, MariaDB, Oracle Database, MongoDB, Redis, Elasticsearch, ClickHouse
Audit types: Configuration, permissions, patch status, performance metrics, index health, encryption, backup status
Performance data: Query time, disk I/O, memory, connection count — time-series recording and trend analysis
Findings and recommendations: Each finding has title, summary, evidence, recommendation and (for simple issues) an automation script
Language support: Turkish and English narrative reports
Audit trail: Scan date, user who triggered it, results, remediation and status are logged
Scheduling: Manual start, automatic weekly/monthly cycle, on-demand urgent scan

FAQ

Frequently asked questions.

Do I have to enter the database password in the panel?

Yes. The audit needs to connect to the database to work. Credentials are encrypted and only used during scanning. They are never written to disk as plain text. If you want to change credentials, update them in the panel.

Can scanning affect the production database?

Scanning runs read-only queries — it does not modify data, only reads. However, on a very busy server a slight performance dip may be seen during the scan. It is recommended to schedule scans during low-traffic hours.

Is the same audit run for all engines?

No. Each engine gets different audits. SQL Server checks permissions, PostgreSQL checks logical replication, MongoDB checks index strategy. Relevant audits are performed based on the engine's architecture.

Related services