Skip to content

Guide

PopSQL shutdown postponed: what to do now

PopSQL / shared SQL library / scheduled SQL exports / migration

PopSQL was due to shut down on 1 September 2026, then postponed with limited support only. A practical plan to move saved SQL and scheduled reports.

PopSQL was one of the tools that made shared SQL feel normal: a query editor in the browser, folders the whole team could see, variables, charts and scheduled results. It is now owned by Tiger Data, the company formerly known as Timescale, and it moved into limited support. Tiger Data then announced a shutdown for 1 September 2026, and on 11 August 2026 it postponed that shutdown until further notice.

The postponement is real and PopSQL keeps working. The terms of it are also clear: limited support, critical security and emergency fixes only, no new features, and at least 90 days notice before a future retirement. For a team that keeps operational SQL there, that is a comfortable runway rather than a reason to stay.

What is actually at risk

The editor is the least of it. Any SQL client can run a query. What disappears with the service is the shared state that accumulated around the editor over the years:

  • the folder tree of saved queries, including the ones only one person understands
  • variables and their default values
  • scheduled queries that send results somewhere every morning
  • charts and dashboards built on those queries
  • connections configured once and shared with the team

The first three are the ones that hurt, because they are usually undocumented anywhere else. A dashboard that stops is noticed the same day. A scheduled export that stops is noticed when someone asks where their Monday file went.

A plan that takes an afternoon, not a project

Inventory before moving anything. Export or list the saved queries per folder and mark each one: run in the last three months, run by someone outside the data team, scheduled. Most libraries shrink by half at this step, and the abandoned drafts are better left behind.

Copy the scheduled queries first. They are the ones with recipients waiting. Note the schedule, the time zone, the format and who receives the result.

Then the shared queries people actually run. Keep their variables. Drop the personal scratch queries unless their owner asks for them.

Rebuild dashboards last, and elsewhere. If charts were the main use, a BI tool is the right destination. A SQL library is not a dashboard tool, and pretending otherwise just moves the problem.

Run old and new side by side for a week for anything scheduled, compare the outputs, then turn the PopSQL schedule off.

Where Taavik fits, and where it does not

Taavik covers the saved queries and the scheduled exports, against private PostgreSQL, MySQL, SQL Server and Redshift databases. Queries live in a personal space or a shared company space with nested folders, the same double brace {{variables}} keep working, and each save can be a checkpoint with a message that can be restored later. A saved query becomes a schedule on a daily, weekly, monthly, interval or cron cadence and lands as CSV or Excel in an email list or a Slack channel.

The main difference from PopSQL is where queries run. A small agent inside the network executes them and only connects outbound, so databases that were never exposed to the internet do not need to be.

It has no charts, no dashboards and no live co-editing. There is no importer either, so queries are copied by hand. A team whose PopSQL use was mostly dashboards should look elsewhere, and the comparison page says the same.

The free plan covers one connection, two members, 25 saved queries and one daily schedule, which is enough to move the scheduled reports that matter most before deciding about the rest.