A database is a structured set of information stored in a way that allows it to be accessed, modified, and utilized by authorized applications or users. The database management system (DBMS) is the software that orchestrates these operations: creating tables, reading, writing, access control, and maintaining consistency. Understanding database management first involves grasping the distinction between the container (the database) and the mechanism that keeps it alive (the DBMS).
Data Traceability in Non-Production Environments
Most guides on database management focus on production: query performance, index optimization, high availability. Database copies, however, often remain in the blind spot.
Backups, test clones, and sandboxes created to train an AI model or validate a migration contain the same sensitive data as the main environment. Recent recommendations emphasize the need to also trace exports, replicas, and test environments, as this is where the true compliance risk surface is created.
A database clone created in January and never deleted may contain personal data that should have been purged since then. When an AI agent queries a staging environment to feed a report, no one checks whether the data it consumes is up to date or compliant with retention policies. To delve deeper into this topic, a detailed article on database management on Tech Mafia explains the fundamental principles underlying these traceability issues.
Best practice involves maintaining a register of all copies of a production database, including their creation date, owner, purpose, and expected expiration date. Without this register, each forgotten clone becomes a silent regulatory liability.
Database Observability: Beyond Classic Monitoring
Monitoring query response times or CPU usage is monitoring. Observability goes further: it involves continuously tracking data freshness, schema compliance, distribution drifts, and the volume of records per table.
Specifically, an observability alert does not just say “the database is slow.” It indicates that a customer table has not received any insertions for three days while the normal frequency is daily, or that a column supposed to contain five-character postal codes suddenly has three-character values.
What an Observability System Monitors
- Data Freshness: time since the last update of a table or partition, compared to the expected frequency
- Schema Compliance: automatic detection of columns added, removed, or whose type has changed without a validation procedure
- Distribution Drift: abnormal variation of values in a column (for example, a “country” field that goes from ten distinct values to two overnight)
- Association with an Owner: each alert must designate a responsible person or team, along with the associated business impact
This approach transforms database management into a proactive process. Instead of discovering a quality issue when a monthly report shows aberrant results, the anomaly is detected at the moment it appears.
Schema Change Management in Regulated Environments
Modifying the structure of a database (adding a column, changing a data type, deleting a table) may seem trivial in a development project. In a regulated environment, every schema change must be documented, tested, and approved before deployment.
The DORA regulation, which applies to the European financial sector, imposes explicit requirements for ICT change management. This means that a simple column addition in a banking database requires a formal procedure: description of the change, non-regression tests, validation by a manager, and archiving of the proof of approval.
Applying Version Control to the Schema
The principle is the same as for source code: each schema modification is subject to a versioned script. The script is reviewed, tested in a pre-production environment, and then applied in production with a rollback mechanism.
An unversioned schema makes any audit trail impossible. If a column containing personal data is deleted without a trace, no one can prove when and why this deletion occurred. Schema migration tools (Flyway, Liquibase, or equivalents integrated into DBMS) allow for maintaining this history without disproportionate manual effort.
Data Security and Governance in a DBMS
The security of a database relies on three complementary mechanisms: authentication (who can connect), authorization (who can read or modify what), and encryption (protection of data at rest and in transit).
Governance adds an organizational layer. It defines who is responsible for the quality of a dataset, what retention rules apply, and how access is reviewed over time. Without governance, technical security only partially protects: a user with legitimate rights can exfiltrate data if no usage policy frames their activity.
- Role-based access control: each user or application receives only the permissions necessary for their function, never default administrative access
- Access logging: each sensitive read or modification is recorded with the user’s identity, timestamp, and nature of the operation
- Periodic rights review: inactive accounts or permissions that have become unnecessary are revoked regularly, not just when an employee leaves
These practices apply to the production database, but also, and this is the often-overlooked point, to every copy and every test environment that contains real data.
Database management is no longer just about optimizing queries or planning backups. The proliferation of copies, the increasing use of data by AI systems, and tightening regulations require treating every environment, including those thought to be temporary, with the same level of rigor as production. The weak link is rarely the main database, but the clone that everyone has forgotten.
