I ran a discovery exercise at a financial services firm last quarter. The infrastructure team estimated they had around 120 databases across their environment. The actual number was 347. That’s not a rounding error — that’s a structural problem.

Database sprawl has become one of the most common and least discussed infrastructure issues in Australian enterprises. While everyone’s busy debating multi-cloud strategies and AI deployment models, there’s a growing mess of PostgreSQL instances, MySQL databases, MongoDB clusters, and legacy SQL Server installations quietly accumulating across the organisation. Nobody owns the problem. And it’s costing more than anyone wants to admit.

How We Got Here

The story is familiar. Each development team spins up databases for their applications. Some use managed services on AWS or Azure. Others run self-hosted instances on VMs. Someone in the data team set up a dedicated analytics database three years ago and nobody’s sure if it’s still in use. There are staging databases that became production databases when nobody was looking. And there’s always at least one Access database that someone in finance refuses to give up.

The containerisation movement made this worse, not better. When every microservice comes with its own data store, and teams have the autonomy to choose their own stack, you end up with a zoo of database technologies. I’ve worked with organisations running PostgreSQL, MySQL, MariaDB, MongoDB, DynamoDB, Redis, Elasticsearch, and Snowflake — all for legitimate use cases, but with no overarching governance.

Cloud providers don’t discourage this either. AWS alone offers more than fifteen different database services, each optimised for a slightly different workload pattern. That’s great for technical flexibility. It’s terrible for operational manageability.

The Real Costs

Database sprawl isn’t just an aesthetic problem for tidy-minded architects. It creates genuine, measurable costs:

Licensing. If you’re running commercial databases like Oracle, SQL Server, or MongoDB Enterprise, every instance costs money. Sprawl means you’re paying for instances nobody’s using, instances that could be consolidated, and instances running on higher-tier licences than they need.

Operational overhead. Every database needs patching, monitoring, backup, and eventual upgrades. Your DBA team (if you still have one) can only manage so many instances before things start falling through the cracks. And when things fall through the cracks in database management, the consequences are usually data loss or security breaches — neither of which is a minor inconvenience.

Security exposure. Databases you don’t know about are databases you aren’t securing. They’re not getting patched. They’re not behind the right network policies. They probably have default credentials or credentials stored in plaintext config files. Every unknown database is a potential entry point for an attacker.

Performance issues. Database sprawl often means databases competing for resources on shared infrastructure. I/O contention, memory pressure, and network bottleneck issues frequently trace back to databases that shouldn’t be running on the same host.

Backup gaps. If it’s not in your database inventory, it’s probably not in your backup schedule. And if it’s not in your backup schedule, you will lose data eventually. Not if — when.

Getting a Handle on It

Here’s a practical approach that I’ve seen work in several organisations:

Step 1: Discovery

Before you can fix the problem, you need to know its scale. Run a network-level scan to identify every database listener across your environment. Tools like nmap can identify database ports, and cloud-native tools can enumerate managed database instances across your AWS, Azure, or GCP accounts.

Don’t just scan production. Check development, staging, UAT, and sandbox environments. Those are usually where the worst sprawl lives.

Step 2: Classify and Inventory

For every database you find, document:

• What application or service uses it
• Who owns it (team, not individual)
• What data it contains (particularly whether it holds PII or financial data)
• Whether it’s actively used or dormant
• What environment it belongs to
• Its backup status

This is tedious work, but it’s essential. You can’t govern what you haven’t inventoried.

Step 3: Define Standards

Pick your supported database technologies and stick to them. Most organisations can operate effectively with two to four database engines. A reasonable stack might be PostgreSQL for general relational workloads, MongoDB or DynamoDB for document stores, Redis for caching, and Snowflake or BigQuery for analytics.

Everything else gets a migration plan or a documented exception with an expiry date.

Step 4: Consolidate

This is the hard part. Consolidation means moving data, updating connection strings, testing applications, and retiring old instances. It takes time, and it’s not glamorous work. But every database you consolidate or retire reduces your operational burden, your security surface, and your costs.

Step 5: Govern Going Forward

Implement a process for database provisioning. It doesn’t have to be bureaucratic — a simple approval workflow that ensures every new database gets logged, assigned an owner, and added to backup and monitoring schedules. The goal is preventing the sprawl from recurring, not creating a bottleneck.

Who Owns This?

That’s the question, isn’t it? Database sprawl persists because nobody wants to claim it. The DBA team says it’s a platform problem. The platform team says it’s an application problem. The application teams say they just need their databases to work.

Someone at the leadership level — typically the Head of Infrastructure or a Platform Engineering lead — needs to own this as a cross-cutting concern. It’s not a project with a start and end date. It’s an ongoing discipline, like keeping your house clean.

The organisations that manage their database estates well don’t have some secret tool or magic process. They just have someone who cares about the problem and the authority to do something about it. If that person doesn’t exist in your organisation, the sprawl will keep growing.