DataSZN

Independent database engineering

Most companies cannot name the databases they are running.

I inventory multi-engine database estates, map every instance to the business application that depends on it, and leave behind monitoring that tells you what is about to break before a user does.

Book a call See engagements

Estate inventory illustration

0
instances identified and mapped
Unidentified SQL Server Oracle PostgreSQL Db2
Typical mid-size estate. Every cell is a live database instance. Before: no owner, no engine, no inventory.

You already know if this is you.

None of these are unusual. They are what happens when a database estate grows faster than anyone's ability to document it.

Nobody can answer "what runs on this server?"

Monitoring shows hostnames. Hostnames mean nothing to the people who approve budgets, sign off on migrations, or decide what can be taken down on a Saturday.

Your inventory lives in a spreadsheet one person maintains

It was accurate the week it was written. Now it is a liability that gets cited in audits and quietly disbelieved by everyone who uses it.

Each engine has its own tool, its own owner, its own truth

SQL Server is watched one way, Oracle another, Postgres barely at all. No one view answers a question that spans them, so nobody asks questions that span them.

Certificates, patches, and end-of-life dates surprise you

Expiry is knowable months ahead. It becomes an incident only because nothing was watching the calendar across the whole estate.

You lost the person who knew

The knowledge was real. It was just never written down anywhere a second person could reach.

What actually makes someone call.

Nobody wakes up wanting a database inventory. Something forces the question. These are the eight situations that bring people here, and what I do about each one.

"We have an audit in ninety days and we cannot produce a list of our databases."

Audit evidence packageI produce the inventory, the access model, the patch and end-of-life position, and the backup coverage as documents an auditor will accept, along with the queries that regenerate them next cycle so you are not starting over next year.

"Our DBA left and took everything with them."

Knowledge recoveryI rebuild the picture from what the systems can tell me rather than what the person knew. Discovery across Active Directory, backups, endpoint management, cloud APIs, and network flows, then written runbooks so the next departure is not another emergency.

"We just acquired a company and we do not know what we bought."

Acquisition estate reviewFull discovery of the acquired environment, licensing exposure, version and support risk, and a consolidation path. Usually the first honest answer anyone gives about integration cost.

"Oracle sent us a license review letter."

Licensing position assessmentI count what is actually deployed, where features are enabled that you may not be entitled to, and where you are paying for editions you do not need. Findings first, so you know your position before the conversation rather than during it.

"An executive asked which applications are at risk and nobody could answer."

Application to infrastructure mappingEvery instance gets tied to the business application that depends on it, so risk, migration progress, and outage impact can be reported in language the business already uses instead of hostnames.

"We are moving to the cloud and nobody agrees on what moves first."

Migration sequencingDependency mapping, sizing from real workload data rather than guesses, a wave plan ordered by risk and coupling, and a written rollback position for each wave.

"Something broke and it turned out to be a database nobody knew existed."

Shadow estate discoveryFinding the instances no tool is watching: departmental installs, developer machines running production workloads, forgotten cloud instances still being billed. This is nearly always the largest surprise in the first engagement.

"We think we have backups. We have never actually restored one."

Recovery verificationI test the restore path on a representative sample, measure the real recovery time against what you have promised the business, and document the gap. Untested backup is a belief, not a control.

Three ways to work together.

Fixed scope, named deliverables, and a date. No open-ended discovery phases. The build is modular, so you can start small and stop whenever it stops being worth it.

Estate Audit

3 to 4 weeks  /  fixed fee

A complete, verified inventory of every database instance you are running, across every engine, with an owner and a business application attached to each one.

I connect to what exists, reconcile it against whatever registry or CMDB you already have, and surface the gap. The output is the document your team has been meaning to write for three years, plus the queries to regenerate it next quarter.

  • Instance inventory across all engines, with version and patch level
  • Application and owner mapping for every instance
  • Drift report: what your registry says versus what is actually running
  • End-of-life and certificate expiry calendar
  • Ranked risk list with the three things to fix first

Observability Build

From 6 weeks  /  priced per module

The audit tells you where you stand once. This keeps it true. I build the collection layer, the data model underneath it, and the interface your team actually opens in the morning.

It runs on your infrastructure, against your databases, with no per-instance licensing and no vendor between you and your own inventory. Your team owns the code when I leave.

It is built in modules, listed below. DBMonitor comes first and carries the platform. Version, permission, and certificate tracking each build on it. You commit to the first rung, not the whole ladder.

  • Collectors for each engine in your estate, scheduled and monitored
  • Layered warehouse model separating raw capture from published facts
  • Dashboard covering status, coverage, ownership, and drift
  • Alerting on the collectors themselves, so silent failure is impossible
  • Runbook and handover sessions with your engineers

Fractional Database Engineer

Monthly retainer  /  ongoing

For teams that need senior database judgment but cannot justify a full-time hire. A set number of hours each month, with a standing call and a shared backlog.

Hands-on engineering work is SQL Server: high availability design, upgrade and migration planning, access governance, and performance triage. Inventory, mapping, lifecycle, and estate-wide reporting covers every engine you run.

  • Standing weekly call and a prioritized backlog
  • High availability and disaster recovery review
  • Upgrade, migration, and consolidation planning
  • Least-privilege access model and approval tiers
  • Escalation path for incidents during agreed hours

The build, in modules

DBMonitor is the platform: collectors, warehouse layers, interface, alerting. Everything after it adds a collector, a model extension, and a view on top of work already done, which is why each module costs less than it would standing alone. Commit to the first rung, then decide. Once modules are running, keeping them running is what the retainer is for.

DBMonitor

6 to 8 weeks foundation — required first

What you have, what is running, and what it belongs to. Discovery across every source that knows about a database, reconciled into one inventory, with current state visible per instance and per application.

An inventory that stays true without anyone maintaining a spreadsheet.

DBVersion

+2 to 3 weeks requires DBMonitor

Edition, version, patch level, and support status for every instance, tracked over time rather than sampled once. The input to a lifecycle conversation that currently happens with estimates.

A lifecycle position you can take into a TLM review or a vendor negotiation.

DBPermissions

+3 to 4 weeks requires DBMonitor

Who can do what, and where. Logins, roles, elevated rights, orphaned accounts, and the privilege drift that has accumulated since the last time anyone looked.

An access audit that regenerates itself instead of being rebuilt every cycle.

DBCerts

+2 to 3 weeks requires DBMonitor

Certificates per instance with issuer, expiry, and owner, watched against a calendar. Expiry stops being an incident and goes back to being a date somebody already knew.

A dated expiry calendar with an owner attached to every entry.

Targeted projects

Shorter, single-question engagements. Useful on their own, or as a first piece of work before committing to anything larger.

Blind Discovery

2 weeks

For environments with no CMDB, no monitoring platform, and no inventory of any kind. I find the databases using the traces they leave: directory service records, backup job definitions, endpoint software inventory, cloud provider APIs, virtualization inventory, license records, and authorized network discovery.

A verified instance list built from evidence, not from memory or a spreadsheet.

Access Governance

3 to 5 weeks

For teams who cannot say who has access to what, or why. I inventory every login, role, and group membership across the estate, identify standing privileges that should be temporary, and design a least-privilege model with tiered approval that your team can actually operate.

A defensible access model, an exception list, and the recurring review process to keep it true.

HA and Recovery Review

2 to 4 weeks

For anyone who has a recovery objective written in a policy document and no evidence it can be met. I review the SQL Server high availability topology, test failover and restore on a sample, and measure real recovery time against what the business has been told.

A gap report comparing promised recovery objectives to demonstrated ones.

Lifecycle and EOL Plan

2 to 3 weeks

For estates carrying unsupported versions and expiring certificates with no calendar. I chart every instance against its vendor support timeline, map certificate and patch exposure, and sequence remediation by risk and business impact.

A dated remediation roadmap, plus automated tracking so the next expiry is not a surprise.

Migration Assessment

4 to 6 weeks

For cloud moves, datacenter exits, consolidation, and version upgrades. Dependency mapping, sizing from observed workload rather than vendor calculators, effort estimates per application, and a wave plan ordered by coupling and risk.

A sequenced migration plan with per-wave rollback positions and a defensible cost estimate.

Cost and Licensing Review

2 to 3 weeks

For estates where database spend has grown without anyone auditing it. Deployed editions versus entitlements, features enabled that carry separate licensing, oversized cloud instances, and instances still billing for workloads that ended.

A findings report with quantified reduction opportunities ranked by effort.

Performance Triage

1 to 2 weeks

For a specific SQL Server that is slow and nobody can say why. Wait analysis, query and index review, configuration audit, and capacity assessment, with the distinction drawn between what needs fixing now and what needs redesigning later.

A prioritized fix list separating quick remediation from structural work.

Team Enablement

1 to 2 weeks

For teams inheriting databases without a database background: platform engineers, developers on call, or an IT generalist who became the accidental DBA. Working sessions on your systems, not slides about someone else's.

Runbooks for your estate, plus engineers who know what to check before they escalate.

What you are actually buying

The deliverable is a document. The value is what becomes possible once it exists.

Decisions stop waiting on one person

Migration scope, outage windows, and change approvals currently depend on whoever remembers. Written inventory moves that into something a team can act on without a meeting.

Risk gets stated in business terms

"Fourteen unsupported instances" is a number nobody can act on. "Payroll and Claims Intake run on unsupported versions" gets funded.

Audits stop being projects

The evidence an auditor asks for is the same evidence every year. Generated once and regenerated on demand, it stops consuming a quarter of someone's time each cycle.

Spend becomes visible

Most estates carry instances nobody uses, editions nobody needs, and cloud sizing nobody revisited. The first audit usually pays for itself here.

Surprises move earlier

Expiry dates, capacity limits, and support windows are all knowable months ahead. They become incidents only because nothing was watching.

You own what I build

Code, queries, schema, and documentation stay with you. No per-instance licensing, no platform to renew, no dependency on me after handover.

Raw capture and published truth are not the same layer.

Most internal dashboards fail because collection, cleaning, and presentation all happen in one place. When something looks wrong, nobody can tell whether the database is broken or the report is. I separate the stages so every number on a screen can be traced back to the moment it was collected. Each stage is its own schema, named below, because a boundary you cannot point at is not a boundary.

01

Capture NEBULA

Raw results land exactly as the source returned them, timestamped, with nothing corrected. Four engines, four dialects, no interpretation yet.

Rule: this layer never edits.

02

Stage LOOM

Types are conformed, duplicates collapsed, and each engine's vocabulary is mapped onto shared terms. A version string from Oracle and one from Db2 become comparable facts.

Rule: this layer never joins across subjects.

03

Model ATLAS

Instances, hosts, applications, owners, and certificates become entities with relationships. This is where a hostname acquires a business meaning.

Rule: this layer holds no presentation logic.

04

Govern SCRIBE

Disagreements between systems of record are surfaced as work, not silently resolved. Unregistered instances, conflicting owners, and stale mappings get a queue and a status.

Rule: conflict is visible, never averaged away.

05

Publish PUBLISHED → BAZAAR

Stable, documented views that people and reports are allowed to depend on. Changes here are versioned, because someone downstream has built on them.

Rule: this contract does not break without notice.

06

Serve WARDEN

The interface. Fast, readable, and fail-loud: when data cannot be retrieved it says so in red rather than showing a confident empty chart.

Rule: never display a number it cannot source.

CANARY sits beside all six. Collector run history, failures, and timings. Every layer reports into it, so a stage that quietly stops running cannot stay quiet.

Illustrative data. This is the view that turns an argument between two teams into a list with a length.

Twelve years of this, at production scale, under regulation.

I spent twelve years as a SQL Server administrator before I built any monitoring, which is the reason my monitoring works. Observability designed by people who have never been paged at three in the morning measures the wrong things beautifully.

For the last five years that has been my day job, end to end: the collection layer, the warehouse model, the API, the interface, and the governance process around it. The estate runs past five hundred instances across four engines. The tooling is read daily by engineers and by executives who have never written a query.

The work that reached the leadership table was not the monitoring. It was the mapping: connecting raw infrastructure to the business applications that run on it, so that migration progress could be reported in terms of applications rather than server counts.

Twelve years deep in SQL Server. Mapped, modelled, and monitored across all four.

SQL Server Oracle PostgreSQL Db2
12
years administering production SQL Server
500+
instances in the estate I work across daily
4
engines mapped and monitored side by side
50+ TB
of production data in those environments

You are hiring a person, not an agency.

I am Zeeshan. DataSZN is me. When you book a call you talk to the engineer who will do the work, and when the project ships there is no account manager between you and the person who wrote it.

That is a deliberate limit on how much work I take. I run one or two engagements at a time. If the calendar is full I will tell you that on the first call rather than staffing it with someone else.

My background is banking, which means regulated change control, audit evidence, least-privilege access models, and the assumption that anything I build will be reviewed by someone whose job is to find the problem with it. That habit travels well.

  • SQL ServerTwelve years administering production SQL Server estates, hands on
  • Multi-engine estatesOracle, PostgreSQL, and Db2 mapped and monitored alongside SQL Server, schema through interface
  • Full stack of the problemPython and PowerShell collection, T-SQL and warehouse modeling, PHP and Vue interfaces
  • GovernanceLeast-privilege access frameworks with tiered approval, certificate and lifecycle tracking
  • CommunityActive in the SQL PASS community

Start with the audit.

Thirty minutes, no pitch deck. Tell me roughly how many databases you have and what made you start looking. I will tell you honestly whether this is worth paying for.

Email hello@dataszn.com Book 30 minutes

Good fit

  • +Twenty to a few hundred database instances
  • +More than one engine in play
  • +No dedicated database team, or one stretched thin
  • +An audit, migration, or acquisition forcing the question
  • +Willingness to act on what the inventory finds

Not a fit

  • −Under ten databases on a single managed service
  • −Looking for dashboards without fixing the data underneath
  • −Emergency incident response starting today
  • −Analytics, BI, and executive reporting as the main goal
  • −Staff augmentation billed by the seat