SSRS Subscriptions, on PostgreSQL
When SSRS goes, its subscriptions go with it. ReportBridge keeps the workflow: heavy reports render in the background, and scheduled snapshots pre-render on a timetable so your users open a fresh copy instantly — no waiting, no timeouts, no Microsoft licensing.
Two Problems SSRS Solved That Dashboards Don't
Interactive analytics tools assume every report is fast enough to run on demand and fresh enough to render live. Operational reporting breaks both assumptions. SSRS handled this with long-running execution and subscriptions. A migration that ignores those two capabilities leaves users worse off than before.
Reports That Run for Minutes
A wide regulatory extract or a multi-hundred-page packet can run far longer than a browser or gateway will wait. Rendered live, it times out. Users retry, pile on load, and still get nothing.
Reports People Expect on a Schedule
The Monday compliance report, the nightly reconciliation, the month-end packet. SSRS subscriptions pre-rendered these so they were waiting when users arrived. Drop subscriptions and every user re-runs the same expensive query by hand.
The point: replacing SSRS means replacing its delivery model, not just its rendering engine. ReportBridge ships both — async background rendering and scheduled snapshots — so the workflow survives the migration.
How ReportBridge Delivers Long-Running & Scheduled Reports
Both paths run on the same PostgreSQL-backed platform as your interactive reports — no second system, no separate portal, no SQL Server.
Async Background Rendering
Reports too heavy for a synchronous request run on a dedicated render worker. You trigger the report and keep working; the viewer polls and notifies you the moment the result is ready. No gateway timeouts, no frozen tab.
Scheduled Snapshots
Pre-render a report on a cron timetable against your live PostgreSQL data. Users open the most recent snapshot instantly — the SSRS subscription pattern, rebuilt for a PostgreSQL backend.
Last-Refreshed Transparency
Every snapshot carries its render time. The viewer shows a last-refreshed banner so users always know how current the data is — no guessing whether they’re looking at this morning’s numbers or last week’s.
Same Access Control
Scheduled and background-rendered reports use the same Domo group-based, fail-closed access control as interactive reports. Pre-rendering a report never changes who is allowed to see it.
After SSRS: Without vs With ReportBridge
Without Scheduled & Async Reports
Heavy reports time out in the browser or gateway
Every user re-runs the same expensive query by hand
No automated, pre-rendered Monday/month-end reports
Users can't tell how fresh a report's data is
Subscription workflows left behind with SSRS
With ReportBridge
Long-running reports render in the background and notify when ready
Scheduled snapshots pre-render on a cron timetable
Users open the most recent copy instantly
Last-refreshed banner makes snapshot age explicit
SSRS subscription workflow preserved on PostgreSQL
Coming soon: edit reports in the Bold Report Viewer designer
Private betaWe're building an in-place editing path that lets an authorized user open a published report directly in the Bold Report Viewer designer — no separate report-server login — and sync changes back into ReportBridge. It's in private beta behind a feature flag and not yet generally available. Want early access? Apply for the beta.
Scheduled & Long-Running Reports — Frequently Asked Questions
Does ReportBridge replace SSRS subscriptions?
Yes — it brings the same delivery workflow to PostgreSQL. SSRS subscriptions let you pre-render a report on a schedule so users open a fresh copy without waiting for the query to run. ReportBridge does this with scheduled snapshots: a report renders on a cron timetable, the result is stored, and the viewer shows a last-refreshed banner so users know how current the data is. When SSRS reaches end of life, the subscription workflow does not have to leave with it.
What happens to reports that take minutes to run?
They run in the background. Heavy reports — large regulatory extracts, multi-page packets, wide date ranges — can exceed any reasonable synchronous request window. ReportBridge offers async background rendering: you trigger the report, the work runs on a dedicated render worker, and the viewer polls and notifies you when the result is ready. No spinning browser tab, no gateway timeout, no lost work.
How are reports scheduled?
Scheduled snapshots are configured per report from the admin app and driven by a cloud scheduler. You pick the cadence; the platform renders the report on that timetable against your live PostgreSQL data and stores the snapshot. Users always open the most recent pre-rendered copy instantly, and the viewer’s last-refreshed banner makes the snapshot age explicit.
Do scheduled and async reports respect access control?
Yes. Both paths use the same Domo group-based access control as interactive reports. A scheduled snapshot or a background render is only visible to users whose groups have access to that report — access is enforced server-side and fails closed, so no group assignment means no access. Scheduling a report never widens who can see it.
Is there a limit on how long a report can take?
Async background rendering handles reports far beyond the limits of a live request. For routine long-running reports the dedicated render worker is sufficient. Reports that need to run for very long durations are on the roadmap via a heavier worker tier; if you have an extreme case, tell us during onboarding and we’ll confirm the fit before you migrate it.
Keep the Workflow. Drop the Microsoft Stack.
Your users don't care which engine renders their reports — they care that the Monday report is waiting and the big extract finishes. ReportBridge keeps SSRS's long-running and subscription workflows on a PostgreSQL backend, with no SQL Server to license.