Making dashboards feel instant without a bigger database

An operations dashboard is a screen that asks the same questions all day. How many orders are open, which shipments are late, what is the stock position at each site. Twenty people have it open, it refreshes every thirty seconds, and every refresh runs the same queries against the same database that is also trying to run the business.

Why dashboards are hard on a database

A dashboard is read-heavy and repetitive. It does not create data; it summarises data other systems created. But because the summaries are recomputed on every refresh, the database does the same expensive work over and over, for each viewer, whether or not anything changed since the last time.

That work competes with the operational load. The warehouse system inserting a shipment and the dashboard counting shipments are on the same server, and at peak both get slower. The usual outcome is a dashboard that takes eight seconds to load at exactly the moment a manager most wants to look at it.

The reflex fixes and their costs

The first reflex is a bigger database. That is a step up in monthly cost for every hour of the year, to serve a screen that needs it for a few hours a week. The second reflex is to refresh less often, which makes the dashboard less useful. The third is a separate reporting copy of the database, which doubles the licence and adds a job that someone has to keep running.

Each fix trades away something the business cares about, and none of them addresses the actual waste: the same read, repeated.

A dashboard does not need a faster database; it needs to stop asking the database.

Serving the reads from memory

redfly sits between the dashboard's data layer (the code that fetches its numbers) and the database. The rows the dashboard reads are kept in a memory store (Redis, which holds data in memory rather than on disk and answers in about a millisecond). A sync service watches the database for changes and carries them to memory shortly after they happen; on SQL Server it reads change tracking on a short interval, and on PostgreSQL and MongoDB it streams the changes as they happen. Pre-computed totals and counts can live there too, so the expensive part of the query is done once, not once per refresh.

The dashboard's refresh now reads from memory. The database sees the writes that changed the underlying data, and only those. Twenty viewers refreshing every thirty seconds cost the database nothing extra, because the memory copy is answering all twenty.

What the customer still builds

redfly does not build the dashboard. The customer builds it with the reporting tool or the web framework they already use, and we support that with advice and development tools. What redfly supplies is the data path: the memory copy, the sync that keeps it correct, and an API the dashboard reads through.

This matters because the dashboard is where the business logic lives. Which shipments count as late, how a region is defined, which manager sees which sites; those are the customer's decisions and they belong in the customer's code. The data path underneath is generic, and that is the part worth not building twice.

What instant honestly means

The screen is fast because its reads come from memory; page loads under two hundred milliseconds on the same database hardware is the outcome this is built for. The numbers on it sit a short lag behind the database, not exact to the instant. For an operations dashboard that is the right trade. A manager looking at late shipments does not need the count to be exact to the millisecond; they need it now and they need it not to freeze.

If the memory store is ever unreachable, reads fall back to the database automatically. The dashboard slows to its old speed until the cache is back; it does not go blank.

What it takes to set up

The tables the dashboard reads have to be chosen, and any totals worth pre-computing have to be identified. The memory store has to be sized for those tables. The dashboard's data layer is then pointed at the redfly API instead of at the database directly. That is a piece of work with an engineer on each side, done once, not a switch someone flips.

Where redfly fits

redfly supplies the read path and the sync for the customer's own SQL Server, MongoDB or PostgreSQL database, running in the customer's cloud account or on their own servers, as a design partnership. The dashboard stays the customer's; the database stops carrying it.