Most providers will not give you a number without a discovery call. This article gives you ours, explains what sits behind each one, and shows the arithmetic that decides whether any quote — ours or anyone else's — is actually good value.

All figures are in Australian dollars and exclude GST.

The short answer

ModelPriceSuits
Monthly DBA planFrom $1,500/monthProduction estates with no in-house DBA
On-call / standby$100 per instance per month, plus $150/hour for callsTeams who run it themselves and want a safety net
Consultancy$150/hour, four-hour minimumA specific problem with a defined end
Fixed-price projectQuoted per projectMigrations, upgrades, HA builds

Monthly plans, and the number that matters

Our entry plan is $1,500 a month for up to 10 SQL Server instances. That is the headline figure. The number that actually matters is the one underneath it: $150 per instance per month.

This is where most comparisons go wrong. A competitor advertising $999 a month looks 33% cheaper until you read what it covers. If that plan covers three instances, it is $333 per instance — more than double. The bigger headline number is less than half the price per instance.

So the first thing to do with any quote is divide. Price, divided by instances covered. If a provider will not tell you the instance count the price assumes, that is itself the answer to a different question.

Our three plans:

  • $1,500/month — up to 10 SQL Server instances, 5 TB, two-hour response SLA, 10 professional service hours a month, monthly health check.
  • $3,000/month — adds 4 MySQL or PostgreSQL instances and 20 TB, one-hour SLA, 20 service hours, automated alerting configured.
  • $7,500/month — 20 SQL Server, 4 MySQL/PostgreSQL and 6 Oracle instances, 50 TB, one-hour SLA, 50 service hours, daily health checks.

Every plan includes 24/7/365 monitoring and remote support. Service hours beyond the monthly allocation are $140 an hour, agreed with you before the work starts rather than discovered on an invoice.

What to check before comparing two numbers

Three things separate quotes that look identical.

What the response SLA measures

A response SLA that starts when a human notices the alert is not a response SLA. Ours starts when the alert fires. The difference is invisible in a proposal and extremely visible at 3am. Ask any provider explicitly: what event starts the clock?

Whether service hours are included

A plan that covers monitoring but bills every remediation hour separately is a monitoring contract, not a support contract. Our plans include a block of professional service hours — 10, 20 or 50 a month depending on the plan — so routine work is covered rather than itemised.

Who actually holds the credentials

This is the one most buyers do not think to ask until procurement asks it for them. Database access at Onsys is held by our consultants in Australia, and only by them — no offshore engineer holds credentials to a client database, on every plan, by default, not as a paid upgrade. Some providers price an onshore-only guarantee as a premium tier. It is worth knowing which kind of quote you are holding.

When an hourly engagement is cheaper

A monthly plan is not automatically the right answer. Consultancy is $150 an hour with a four-hour minimum, billed in 30-minute increments, and it is the better model when the work has an end: a performance problem to diagnose, a migration to plan, a second opinion on someone else's design.

The rough crossover is around ten hours a month. Below that, hourly usually wins. Above it, you are paying plan money for hourly service and getting no SLA, no monitoring and no included hours for it.

On-call cover sits between the two: $100 per instance per month holds a two-hour response SLA around the clock, and calls are $150 an hour when you make them. A quiet month costs almost nothing. It suits a team that runs the databases day to day and wants someone to ring when something is genuinely wrong.

What drives a project quote

Projects — migrations, upgrades, high availability builds — are quoted as a single fixed price against written acceptance criteria, with milestone payments, so there is no cost-overrun risk. What moves the number is rarely the database work:

  • Instance and database count. Linear, and the easiest thing to scope.
  • Application coupling. A database behind one application is a different project from one behind nine, with linked servers between them.
  • Downtime tolerance. A four-hour window is a different design from a four-minute one, and the difference is most of the cost.
  • Change control. An organisation with a weekly CAB and a formal test sign-off is not slower to work with, but it is more work to plan for.

Where scope genuinely cannot be defined up front, we say so and work hourly rather than quoting a number we would have to revise later.

What a fair quote looks like

You should be able to read a quote and answer all of these without ringing anyone:

  1. How many instances does this price cover, and what happens when we add one?
  2. What event starts the response SLA clock?
  3. How many hours are included, and what is the rate beyond them?
  4. Who holds credentials to our databases, and where are they?
  5. What is the term, and what happens if we leave?

Ours run month to month with no lock-in. Full pricing is published rather than quoted on request, and a free 20-point health check will tell you what your estate actually needs before you commit to anything — including when the answer is that you do not need us yet.