"Our dashboard says 1,240 active users. The spreadsheet Jess shared yesterday says 1,180. And the number the CEO quoted in the all-hands was 1,310. Which one is right?"

If this conversation sounds familiar, you're not alone. For most growing companies, the fight over which number is correct is a weekly ritual. It wastes time, erodes trust, and most importantly means people are making decisions based on data they don't fully believe.

The fix is conceptually simple: one canonical place where the real data lives, and everyone reads from it. In practice, most companies already have that place: their database. The challenge is making the database accessible enough that people actually use it instead of copying data into spreadsheets, Notion pages, and slide decks where it immediately starts going stale.

Why Numbers Diverge in the First Place

Before fixing the problem, it helps to understand how it develops. At the start, everything is fine. The database has the real data. Engineers pull reports when asked. Life is manageable.

Then the company grows. An analyst exports a CSV to do some calculations in Excel and shares the result. That spreadsheet gets copied and extended. A PM builds a Notion dashboard by pasting numbers from the analyst's spreadsheet. Someone else screenshots a Salesforce report and puts it in a deck. The CEO quotes a number from last month's deck.

Now you have four different numbers for "active users," each reflecting a different point in time with a different definition of "active." Nobody did anything wrong each person was trying to do their job with the tools available to them.

The root cause is access. When querying the database is hard, people avoid it. They work with stale copies instead. The single source of truth exists it's just not accessible enough to be used consistently.

What "Single Source of Truth" Actually Means

A single source of truth (SSOT) doesn't mean everyone reads from the exact same dashboard that would require everyone to have identical information needs, which they don't.

It means:

One place where the raw, authoritative data lives your database

Agreed definitions "active user" means the same thing everywhere

Access patterns that pull from that source rather than from copies of it

The goal isn't to ban spreadsheets. It's to make sure that when someone needs a number, they get it from a live query against the database, not from a screenshot or CSV someone emailed two weeks ago.

The Agreed Definitions Problem

Here's the part that's often underestimated: the database can be perfectly accurate and you can still have contradictory numbers if different people define things differently.

Take "active user." Depending on who you ask:

An engineer might count any user who has logged in within 30 days

A product manager might count any user who has completed at least one meaningful action in 30 days

A sales rep might count any user whose subscription is currently active, regardless of whether they've logged in

All three queries return different numbers. All three numbers are "correct" by their own definition. But if different people are citing different definitions, the resulting confusion looks like a data quality problem when it's actually a definition problem.

Solving this means documenting your key metric definitions somewhere central a metrics glossary and ensuring that the SQL queries that calculate those metrics implement those definitions consistently.

-- Agreed definition: "active user" = logged in AND performed at least one action
-- in the last 30 days, on a paid plan

SELECT COUNT(DISTINCT u.id) AS active_users
FROM users u
JOIN sessions s ON s.user_id = u.id
JOIN events e ON e.user_id = u.id
WHERE
  u.plan != 'free'
  AND s.created_at > NOW() - INTERVAL '30 days'
  AND e.created_at > NOW() - INTERVAL '30 days';

Once that query exists and is agreed upon, it can be saved, reused, and referenced. The number it returns is the canonical number. When someone cites a different figure, you have a reference point to trace where the discrepancy came from.

Making the Database Accessible Enough to Be the Default

The reason people use spreadsheets isn't that they prefer them. It's that spreadsheets are easy to get to and the database isn't.

To make the database the default source, you need to reduce the friction of getting answers from it. There are a few approaches.

Give everyone read-only database access. This is free and easy to implement. Create a read-only user in your database, share credentials with trusted team members, and point them at a query tool like DBeaver or TablePlus. The problem: most non-technical teammates won't be comfortable writing SQL, and even technical ones will still copy results into spreadsheets for sharing.

Build a metrics layer. Tools like dbt or Lightdash let you define metrics in code, which get compiled into SQL. You define "active_users" once and anyone can reference it. This is excellent for engineering-heavy teams but requires significant setup and ongoing maintenance.

Use a natural language database interface. Tools like AI for Database let anyone on the team ask questions in plain English. "How many active users do we have this week, broken down by plan?" gets translated to SQL, run against the live database, and returned as a table or chart no SQL knowledge required.

This last approach changes who can access the database from "developers only" to "everyone." When your ops manager, PM, and sales lead can all pull their own numbers from the same source, they stop needing to ask engineering for data and stop creating stale copies.

Building Live Dashboards That Don't Go Stale

One of the most common forms of the SSOT problem is the dashboard that gets built, shared, and then never updated. Within a week it's out of date. Within a month nobody trusts it.

The fix is dashboards that query the database directly and refresh automatically. Instead of:

Database → CSV export → Excel → Chart → Screenshot → Slide

You get:

Database → Live query → Dashboard (auto-refreshes)

In practice, this means building dashboards using a tool that maintains a live database connection and re-runs the underlying queries on a schedule.

AI for Database does this natively. You connect your database, define your key metrics queries in plain English, and the resulting dashboard refreshes automatically daily, hourly, whatever interval makes sense for the metric. Everyone who opens the dashboard sees the same live number from the same source.

This is how you stop the "which number is right?" conversation before it starts. If the dashboard refreshes from the database every hour, the number on the dashboard is always correct by definition.

Handling Access Controls

One common objection to making the database more accessible is security. "If everyone can query the database, someone will run a query that returns every user's personal data."

This is a legitimate concern, and the solution isn't to keep the database inaccessible it's to implement appropriate access controls.

At the database level, this means:

Read-only credentials (no DELETE, UPDATE, or INSERT permissions for the query interface)

Row-level security in PostgreSQL where different users should see different subsets of data

Column-level restrictions to hide sensitive columns like payment details or hashed passwords

At the application level, tools like AI for Database support connection-level access controls. You connect the database and configure what users are allowed to see. The AI layer only queries within those boundaries.

The goal is a system where the marketing analyst can pull campaign performance data, the sales rep can see their pipeline numbers, and the PM can access product engagement metrics but nobody can inadvertently access data they shouldn't see.

The Migration Path: From Spreadsheet Chaos to Database-Driven Decisions

Moving from a world of spreadsheet copies to a database-driven culture isn't an overnight switch. Here's a practical sequence:

Step 1: Audit your current metrics. List the 10-15 numbers that get cited most often in company meetings. "Active users," "MRR," "churn rate," "signups this week," and so on. These are your priority candidates.

Step 2: Write the canonical queries. For each metric, write the SQL that produces the agreed-upon number. Document the definition alongside the query. Get sign-off from whoever owns that metric.

Step 3: Build live dashboards. Translate those queries into dashboards that pull from the database and refresh automatically. Set the refresh interval to match how frequently the metric is used in decisions.

Step 4: Make it accessible. Set up a tool that lets non-technical team members pull their own queries without needing SQL. This reduces the engineering bottleneck and eliminates the incentive to maintain separate spreadsheet copies.

Step 5: Deprecate the stale copies. Once people trust the live dashboards, archive the old spreadsheets. This takes time trust is built by the live dashboards being right, repeatedly, over weeks.

When the Database Isn't Enough

Sometimes the database isn't the right single source of truth for a specific metric. A few examples:

Sales pipeline data often lives primarily in a CRM, not the database. Unless your CRM data is synced to the database (some teams do this), the database won't have the freshest picture.

Ad spend and campaign performance live in ad platforms. You can pull this data into your database via ETL, but that adds complexity.

Qualitative customer feedback lives in survey tools or support tickets.

For these, the answer is usually to bring the data into the database (via ETL or direct integration), or to accept that some metrics will live in their source system and clearly designate which tool is authoritative for which metrics.

The goal isn't to have literally all data in one database that's rarely practical. It's to be explicit about where each number comes from and to ensure that everyone is reading from the same place for each metric.

The Underlying Point

The database already has the real data. The fight over which number is right isn't a database problem it's an access problem. When querying the database is harder than copying a number from a spreadsheet, people copy numbers from spreadsheets.

The path to a genuine single source of truth runs through making the database the easiest place to get answers. That means live dashboards that refresh automatically, natural language access for non-technical teammates, and agreed definitions for your most important metrics.

Once your ops manager can ask "how many users churned this month?" and get the answer in seconds from the live database the same way your developers can the spreadsheet copies stop getting made. Not because you banned them, but because there's a better option.

Try AI for Database free at aifordatabase.com connect your database and give your whole team direct access to the numbers that matter.

Database as a Single Source of Truth: Stop Fighting Over Numbers