SmartLink
Data platform

Data warehouse and BI services in Pakistan: cost and build time

Data warehouse and BI services in Pakistan are usually commissioned after the same meeting. Two departments arrive with two different figures for the same month and nobody in the room can say which one is right. SmartLink Services builds dimensional models and reporting layers from Karachi on SQL Server, Oracle and Power BI, with reconciliation to source as a deliverable rather than a promise. This page covers the commercial ground: what a warehouse and reporting build costs at published market rates, how long it takes before a first reconciled dashboard exists, and whether your business needs a warehouse at all or better reporting off what it already runs.

Discuss this service
Model
Dimensional
Refresh
Nightly \u00b7 intraday
Consumers
Finance \u00b7 ops \u00b7 leadership
Overview

Reporting off the production database punishes both sides.

The pattern is familiar enough to predict. Finance needs a report, somebody writes it against the transactional system because that is where the data lives, and it works. A year later there are forty such reports, several of them heavy, all running during the working day, and the operational system slows every time a dashboard is opened. Meanwhile no two reports agree, because each one encoded its author's private understanding of what a figure means. Nobody wrote those assumptions down, because at the time nobody thought they were assumptions.

A modelled warehouse separates the two concerns. Operations recovers its performance because reporting is no longer competing with transactions for the same resources. Reporting gets a structure designed for questions rather than for transaction processing, with history retained even where the source system overwrites it. Both benefits follow from the same decision, which is why the separation is often worth making before the analytics ambition is fully settled. The transactional system stops paying for reporting it was never designed to serve, and reporting stops being constrained by a schema built for entering orders.

The valuable part of this work is not the pipeline. It is agreeing what the numbers mean: which orders count as revenue and on what date, how returns are treated, what a customer is when the ledger holds legal entities and sales holds trading names, and who owns each definition when two departments disagree. A metric dictionary with named owners outlasts every dashboard that gets built on top of it. Dashboards get rebuilt every few years as tools change. Definitions, once genuinely agreed, tend to survive intact.

Scope

What Data warehouse & BI covers

Everything below is agreed in writing before any oracle & databases work starts, so both sides know what is in and what is not.

What the work covers

  • Source system analysis and metric definition
  • Dimensional model design with agreed grain
  • ETL or ELT pipeline build and scheduling
  • Reconciliation of warehouse figures to source
  • Dashboard build for finance, operations and leadership
  • Row-level security for shared dashboards

What you get at handover

  • Metric dictionary with owners
  • Dimensional model documentation
  • Scheduled pipelines with failure alerting
  • Reconciliation report to source systems
  • Published dashboard set

Typically involves

dbt
Discuss this service
01

Agreeing the grain before anybody builds a dashboard

Grain sounds like modelling jargon and it is the most practical decision in the project. It is simply the question of what a single row represents. An order, an order line, a shipment, a shipment line, or a daily summary of any of those. Getting it wrong is not a rounding issue. Quantities double, averages stop meaning anything, and every measure built on that table inherits the error silently. Nothing fails, and every number is slightly wrong in a direction nobody can predict.

The mistake usually arrives as an innocent request to add a column. Somebody asks for delivery date on an order level table, delivery actually happens per line, and the table quietly changes grain to accommodate the request. Every existing measure is now wrong in a way that is genuinely difficult to see, because the totals still look approximately right and only certain specific cases diverge from the source. Those cases are usually the large orders, which are precisely the ones somebody eventually checks by hand.

We write the grain down for each fact table, state what a row represents in language a business user can check, and then hold that line through the inevitable requests. Where a different grain is genuinely needed, it becomes a separate table rather than a compromise, because two correct tables cost far less over time than one that quietly disagrees with itself at the edges. Refusing a column request is far easier when the grain is written down and everybody signed it, which is most of the reason we insist on writing it down.

  • Grain stated in plain language for every fact table before the table is built
  • Additive, semi additive and non additive measures identified, so totals are not summed wrongly
  • Requests that would change grain met by adding a table rather than amending the existing one
  • Conformed dimensions shared across facts, so the same customer means the same thing everywhere
  • Slowly changing dimension handling decided per attribute rather than applied uniformly
02

The semantic layer is where revenue stops meaning three things

Ask three departments for last month's revenue and you will usually get three numbers, each of them defensible. Sales counts orders won. Operations counts what shipped. Finance counts what is recognised under its policy. All three are correct, and the disagreement consumes a surprising amount of senior time because the definitions are implicit and every report encodes its author's assumption without saying so. The cost is not the disagreement itself. It is that the disagreement gets rediscovered every quarter by different people, each of whom works out from first principles why the numbers differ.

A semantic layer turns the definition into a shared object rather than a private choice. The calculation for a measure is defined once, together with the filters and the time treatment it carries, and every dashboard uses that definition. When the definition changes it changes in one place, and reports built last year move with it instead of quietly continuing to apply a rule nobody remembers agreeing. That single property is what keeps a reporting layer maintainable across several years rather than replaced whenever the tooling changes.

This is governance work more than technical work. Each measure needs an owner who can settle a question about it, a written definition in business language, and a route for changing it. Where two definitions genuinely have to coexist, they get two distinct names and both are published, which is considerably better than one name meaning different things depending on which department is in the room. Naming both is not a failure to decide. It is an accurate description of a business that genuinely measures two things.

  • Every measure defined once in a shared layer rather than reimplemented inside each report
  • A written definition in business language, with a named owner able to settle disputes
  • Two legitimate definitions given two distinct names rather than sharing a single label
  • Time treatment stated explicitly: transaction date, posting date or period of recognition
  • A change route for definitions, so historical reports move with an agreed and dated revision
01

What a data warehouse and BI build costs in Pakistan

No published market band exists in Pakistan for warehouse work by itself. The nearest published project figure is custom application development at PKR 200,000 to 1,000,000 and up, and most warehouse builds are either quoted inside that shape or against hours, where market rates run PKR 3,500 to 8,000 for full stack technical work with senior specialist time at the top of the band. Where reporting is bought as part of a wider programme, the enterprise implementation band starting at PKR 3,000,000 applies instead, since multi site scope with integrations is what puts a project there in the first place.

Source count drives the effort more than anything else. Each source is an extraction to build, a mapping to agree, a schedule to run and a reconciliation to prove every night, and adding a second source is closer to doubling the work than to adding a fifth. Metric count matters less than metric contention: forty agreed measures are cheaper than six that finance and sales define differently. Refresh frequency is the third driver and it is a design decision rather than a setting, since nightly batch and intraday incremental loading are different builds with different failure handling. History depth is the fourth, and the initial load of several years is often the longest running job the project ever executes.

Dashboards are the part everybody counts and the cheapest thing in the estimate. A report built on an agreed model is a day of work; the model underneath it was the project. Row level security adds real effort where one dashboard serves regions or branches with different visibility, because it needs a rule and a maintained mapping of person to scope. Licences sit outside our invoice entirely, whether that is Power BI with Microsoft or the database platform with its vendor, and we resell none of them. Every figure here is market context. A real figure follows discovery, once the source list, the metric list and the refresh requirement are written down.

  • Source system count treated as the main driver, since each carries its own reconciliation
  • Contested metric definitions costed as negotiation time rather than as build time
  • Nightly and intraday refresh priced as different designs rather than as a setting
  • Initial history load planned as the longest job the project will run
  • Reporting licences contracted with Microsoft or the platform vendor, with no margin to us
02

How long a data warehouse takes to build

A first useful dashboard can exist within weeks of a data warehouse and BI build starting, and it should. Agree the grain, agree one metric, load one source, reconcile it and publish. That sequence produces something a finance manager can argue with, and an argument about a real number moves a project faster than another workshop about requirements.

The full build follows the reported delivery bands in Pakistan: six to twelve weeks for a focused single company scope, three to six months for an SME programme, longer where several systems and a group consolidation are involved. Most of the elapsed time is not technical work. It is agreement. Pipelines, models and dashboards are built in weeks. Deciding what a number means takes longer than building the thing that displays it, and no tool shortens that part.

Definition is the slow part and it is an organisational negotiation rather than a modelling task. The day finance and sales agree what revenue means, whether it is net of returns, which date it belongs to and how a credit note behaves, is the day the build accelerates. Until then every dashboard is provisional. Source access is the second delay, particularly where a system belongs to a vendor who charges for an extract or restricts direct reads. Reconciliation is the third and the most instructive: the first night the warehouse disagrees with the ledger is the start of the real work, not a defect at the end of it. We plan for several of those nights, because each one usually exposes a genuine source system problem that predates the project.

  • One source, one metric and one reconciled dashboard published early to force real feedback
  • Metric definitions treated as a business decision with a named owner per measure
  • Source access and any vendor extract charges established before the plan is baselined
  • Reconciliation failures expected and scheduled, since each one exposes a source problem
  • Group consolidation and multi entity reporting scoped as its own phase
03

A warehouse or reporting straight off the source

Plenty of businesses in Pakistan are sold a warehouse when what they needed was a read replica and an argument settled. The test is not company size and it is not data volume. It is four questions, and if the answer to all four is comfortable, do not build a warehouse this year.

How many systems hold the numbers. Where one system holds nearly everything and the rest is reference data, reporting directly off it, or off a standby opened for reads, will answer most questions at a fraction of the cost. Whether the definitions are disputed. If two departments already disagree about revenue, no reporting tool resolves that, and the modelling exercise is valuable precisely because it forces the argument to a conclusion with a named owner. How long the numbers must survive. A metric that has to outlive a source system replacement, or history that must outlast a retention purge in the transactional system, needs somewhere else to live. And what reporting is doing to the system that takes orders, because a warehouse is sometimes bought for governance and justified by the fact that the ledger stopped being usable at four in the afternoon.

The middle option is worth naming since it rarely gets offered. A read replica or a standby opened for reporting removes the load from the transactional database without building a model at all. It is quick, it is cheap, it buys a year, and it settles nothing about definitions. Where the real complaint is performance rather than trust, it is frequently the correct purchase, and we will say so even though it is a smaller piece of work for us.

One warning that applies either way. A warehouse does not repair master data. Where one company exists twice in the customer master under two spellings, the warehouse will faithfully report two customers, and it will do it faster and more visibly than the source system did. Fix the duplicates or agree a cross reference before anybody promises a single view of anything. Our usual recommendation is the smallest warehouse that settles the argument you actually have, with the grain and one metric agreed in writing before a line of the model is built.

  • Source system count and definition disputes weighed before any platform is chosen
  • A read replica or reporting standby offered where the complaint is load rather than trust
  • History that must outlive a source system treated as a genuine reason to build
  • Duplicate master data resolved or cross referenced before a single view is promised
  • The grain and the first metric agreed in writing ahead of the model
How we deliver

Delivering Data warehouse & BI

Order matters more here than anywhere else. Monitoring goes in before anything is touched, because a tuning claim with no baseline behind it is an assertion rather than a result.

  1. 01

    Discover

    Baseline the estate first: versions and patch levels, parameter drift, who holds which privilege, what the alert log has been saying for months, which query plans have flipped, and whether a restore was ever actually performed.

  2. 02

    Blueprint

    Character set, block size, storage layout and partitioning keys are chosen once and written down, with the recovery point and recovery time the business is willing to accept stated in hours, not adjectives.

  3. 03

    Build

    Instances are created from a scripted build so a second one is identical, with Data Guard standby, RMAN catalogue, backup schedule and monitoring configured before a single application schema is loaded.

  4. 04

    Test

    Testing here means a restore. A full RMAN recovery to a point in time on separate hardware, timed, with the switchover to standby rehearsed and the output written up as evidence somebody can read.

  5. 05

    Go live

    Cutover is a migration window with a stated fallback: the old instance stays intact and reachable until the new one has carried a full month-end and the reconciliation has been signed.

  6. 06

    Run

    Quarterly patching on a rehearsed route, monthly capacity and health reporting, restore tests on a schedule, and privileges withdrawn in stages once audit evidence shows which application actually uses them.

Working together

When a warehouse is not the answer

A warehouse is a standing commitment: pipelines to run, definitions to govern, models to change whenever a source system does. An organisation with one reporting need, a single source system and a stable question is usually better served by a well written report and a read replica. We will say so, because the cost of a warehouse is not the build, it is the several years that follow it.

The other thing worth stating plainly is that a warehouse does not improve source data. If customer records are duplicated in the CRM and cost centres are inconsistent in the ledger, the warehouse will reproduce all of that faithfully and make it considerably more visible, which is useful and is not the same as fixing it. Where the data quality problem is upstream, the honest sequence is to address it there and model on top of the result.

Credentials

Accreditations behind Oracle & databases

Accreditation questions get technical in this practice, so here is what each partnership actually covers in database work.

Oracle

Partner

Oracle Database from 11g through 23ai, including RAC, Data Guard, RMAN and the quarterly update route. We flag separately licensed features before enabling them during any investigation.

Microsoft

Partner

SQL Server administration alongside the Oracle work: Always On availability groups, backup verification, index and plan analysis, and Azure as the hosting option when the hardware refresh is due.

Google

Partner

PostgreSQL on Cloud SQL for teams who want a managed engine, with backups landing in Cloud Storage and the same monitoring, restore testing and privilege review we apply to Oracle.

FBR digital invoicing

Compliant integrations

Invoice records submitted to the FBR system have to be retrievable years later. That is a retention, indexing and audit trail problem in the database, and it is where we get involved.

HIPAA

Compliant practices

Health data at rest is encrypted, production copies used in test are masked, auditing is enabled on the objects that hold it, and we work under a business associate agreement.

Client words

What Oracle & databases clients say

Comments from people who run oracle & databases systems day to day.

  • The handover was the part I judged them on. Configuration decisions documented with the reasoning, our administrators trained properly, and a checklist we actually worked through. We run it ourselves now, and calling them is a choice rather than a necessity.
    Head of Shared Services Multi site manufacturing group
  • What sold us was that they argued with our brief. We asked for a reporting layer and they came back saying the reporting was fine, the batch data underneath it was not, and fixing that first would cost less. That turned out to be right. Our first mock recall after go live took an afternoon instead of the better part of a week.
    Finance Director Food manufacturing group, Karachi
  • We had been through one failed implementation already, so we were sceptical of the whole category. The difference here was the migration work. Two full rehearsal loads before the real one, with a reconciliation pack we could check ourselves. Nobody had ever handed us evidence like that and asked us to sign it.
    Head of IT Wholesale distribution business
Questions

Questions about Data warehouse & BI

There is no published band for warehouse work alone. The closest published market figure is custom application development at PKR 200,000 to 1,000,000 and up, with most work quoted against hourly rates of PKR 3,500 to 8,000 for senior technical time. Source count, contested metric definitions and refresh frequency move the number most. Reporting licences are contracted with the vendor. We quote after discovery.

A first reconciled dashboard on one source can exist within weeks and we aim for that deliberately. The full build follows reported delivery bands in Pakistan of six to twelve weeks for a focused scope and three to six months for an SME programme. Agreeing what a metric means, rather than building the model, is what usually sets the date.

Often that is the sensible order. Where one system holds nearly all the numbers, reporting directly off it, or off a standby opened for reads, answers most questions cheaply. Build the warehouse when a second source has to be joined, when history must outlive a purge, or when reporting load is visibly slowing the system that takes orders.

Usually because they are answering different questions with the same word. One counts a sale on despatch and the other on invoice. One nets returns and the other does not. One excludes intercompany. A warehouse fixes this only in the sense that building it forces the definition to be written down and given an owner, which is the part that actually resolves the argument.

If you publish and share through the Power BI service, yes, and they are contracted with Microsoft rather than with us. We resell nothing, so the platform recommendation carries no margin either way. Count the readers rather than the report authors when estimating, because that is usually where the number lands, and settle it before the dashboard set is designed.

Somebody has to, and it is worth naming them before go live. Pipelines fail, source systems change shape without warning, and a new metric arrives every quarter. The work is small but it is continuous. We hand over the model documentation, the metric dictionary with owners and the failure alerting, and we can hold the operational side under a separate arrangement where you would rather not.

More in Oracle & databases

More Oracle & databases services

Data platform

Oracle database management

Day-to-day administration: patching, backups, monitoring, capacity and incident response.

Open service page → Data platform

Oracle database building

New database architecture: sizing, schema design, high availability and standards, built to be handed over.

Open service page → Data platform

Database security & hardening

Privilege review, encryption, auditing and masking, reducing what an incident can reach.

Open service page → Data platform

Performance tuning

Slow reports and month-end close bottlenecks diagnosed with evidence, not guesses.

Open service page →

Two departments, two versions of the same number?

Tell us what you run today and where data warehouse & bi is causing you trouble. The first conversation is a consultation rather than a pitch.

Book a consultation All oracle & databases