Move database workloads forward with the source, destination, schedule, and recovery boundary in view

Data Tools brings migration, recovery, data movement, monitoring, and scheduled query work into one team-scoped operating surface. Each workflow should make its source, destination, schedule, and current status available for review before it changes data or sends an output.

Choose the operation by its boundary

Use PG Migration when a PostgreSQL or CockroachDB database needs to move to a new server or target. Use backup and restore jobs when a recovery artifact and its target must be explicit. Use Flowr when a source query needs a transformation and a destination. Use Data Watchers when database changes should trigger a webhook, and Workflows when a query should run on a schedule and optionally send its result to a configured channel.

The workspace does not replace review of credentials, database permissions, storage controls, destination ownership, webhook recipients, or the recovery procedure your team has tested.

Make the operating record useful

Give each operation a clear owner and preserve the choices that determine its effect. A connection name, database target, schedule, destination, and execution record make it easier to explain what ran and what needs investigation when a job, pipeline, watcher, or workflow behaves unexpectedly.

Use the linked product workspaces to configure and inspect live work. The diagrams on this page are illustrative and do not execute a migration, backup, restore, pipeline, watcher, or scheduled query.

Review the latest execution state before acting on a prior run's outcome.

Move a PostgreSQL database to a new target

PG Migration is a source-to-destination transfer workflow for PostgreSQL or CockroachDB schema and data. It is for server moves and new destination setups: select the source connection, the destination connection, and the database names, then choose the scope that fits the move.

The migration configuration supports schema-only or data-only selection, so the transfer boundary is visible rather than implied. Confirm that the source and destination are different, that each database name is correct, and that the destination can accept the selected data before creating the job.

Treat a server move as a cutover plan

A completed transfer is not by itself a cutover. Review application connections, database roles, extensions, data consistency, and the path to return to the previous system before directing production traffic to a new target. Keep the source and destination identified in the run record so later operators can investigate the result.

Warning: A migration can create, replace, or duplicate database objects and data at its destination. Confirm the selected source, destination, scope, permissions, and validation plan before starting it.

Validate the destination after transfer

Check the destination with the application workloads that matter, not only with the migration job status. Compare expected schemas and records, confirm required roles and connections, and retain an approved cutover window. If a target must be rebuilt, record which source and destination were used so the recovery decision remains reviewable.

Schedule backups and create restores as explicit recovery jobs

A backup schedule pairs a connection, storage destination, and cron expression. The job record makes the selected destination, schedule, recent run state, logs, and completed backup downloads available for inspection. Use those records to review what was configured and what completed; do not treat a visible record as a proof that every recovery requirement has been met.

A restore is a one-time recovery job. Select the backup, target connection, and PostgreSQL-oriented options before creating it. Options such as clean, IF EXISTS, and create database can change the effect at the target, so they require the same review as the target itself.

Recovery has a destructive boundary

Warning: A restore can replace or remove data and schema on its selected target. Confirm the backup source, target connection, restore options, permissions, and a tested recovery path before creating the job.

Set backup schedules only where the storage destination, credentials, cron expression, and retention process are understood by the operators who own them. Test the backup and restore procedure against the systems and failure cases that matter to your team. This interface does not imply point-in-time recovery, encryption, automatic restore validation, retention enforcement, or RTO/RPO guarantees.

Review completed work before relying on it

Use job logs and available downloads to inspect a completed backup or restore. Those records are useful evidence for an operator, but they do not replace a restore test against the destination and failure mode that the team expects to support. Keep the test environment and the recovery scope with the operating record.

Build a Flowr pipeline from query to destination

Flowr builds a source -> transform -> destination pipeline. Start with a query on a selected source connection and use its preview schema as the input to a Python transform. The transform returns fields for the destination rather than changing the source query's result in place.

Choose a database connection and table as the destination, with append or replace behavior, or configure an HTTP destination with its URL and headers. Review the target table or HTTP endpoint, destination mode, batch settings, and retry settings before records leave the source or change shape.

Run a pipeline one time, or select a recurring frequency including a custom cron schedule and timezone. Pipeline run logs make completed or failed work inspectable, but they do not prove that a downstream table or HTTP service accepted every intended record.

Check a pipeline before it becomes recurring work

Preview the source query before using its columns in a transform. Then confirm whether the destination is append or replace, who owns its database table or HTTP endpoint, and whether the configured schedule fits the intended operating window. Recheck run logs after changes to source schemas, transformation code, or destination contracts.

Open Flowr

Watch changes with table or query boundaries

Data Watchers provide two modes. A table watcher uses database triggers to detect selected insert, update, or delete changes. A query watcher polls a SELECT query and detects when its results change; it is more flexible, but it has a polling interval with a 30-second minimum.

For table watchers, select the schema and table, choose the change types to watch, and optionally add a SQL WHERE-clause filter. For query watchers, review the query and polling interval. In both modes, configure the webhook URL, HTTP method, and optional headers for the recipient that should receive the event.

Batching is optional: it groups multiple events before a webhook is sent, with configurable batch size and interval. It is not a guarantee that every downstream recipient will accept, process, or deduplicate each event. Limit filters, webhook destinations, and batching settings to the records and recipients intended.

Keep notification scope narrow

Table trigger monitoring is immediate for the selected changes; query monitoring checks for changed results on its configured interval. Choose the mode for that difference, then test the exact webhook receiver with the filters and batching configuration that will be enabled. A watcher event record helps with investigation, but it does not replace downstream delivery monitoring.

Open Data Watchers

Schedule query runs and configure result delivery

Workflows run a selected database query on an hourly, daily, weekly, or monthly schedule. The schedule configuration shows the frequency, timezone, time or day where relevant, and generated cron expression so the expected run time can be checked before the workflow is saved.

Result delivery is optional and only uses channels configured for the workflow: a Slack workspace and channel, an email address, or a Discord webhook URL. Configure the channel and recipient deliberately; enabling a workflow does not establish that an external channel is available, authorized, or monitored.

Review the selected connection, query, schedule, delivery channel, and recipients before enabling the workflow. Inspect execution records after it runs, especially when a report is used as an input to a decision or operational response.

Match the schedule to the recipient

Confirm the workflow timezone and cadence alongside the recipient's operational window. A Slack channel must be selected from a configured workspace, email needs a deliberate address, and Discord delivery uses a configured webhook URL. Change recipients or timing with the same care as changing the underlying query.

Open Workflows

Keep consequential work reviewable

Data Tools is designed to show the state around consequential operations, not to make them safe by default. A migration job, backup record, restore history, pipeline log, watcher event, or workflow execution is evidence about a workflow. It is not a substitute for checking the source, target, recipient, and resulting database state.

Operating checklist

1. Identify the source, destination, target, schedule, and owner for the operation.
2. Confirm database permissions, storage access, destination controls, webhook recipients, and query or transform behavior.
3. Review destructive options, filters, batching, and delivery settings before enabling or running work.
4. Inspect job results, logs, and downstream outcomes afterward.
5. Keep a tested recovery and rollback plan for systems where data loss or downtime would be consequential.

When an operation crosses a database, storage system, HTTP endpoint, or notification channel, the owner of each boundary should be clear before the work begins. Stop for review when the source, target, filter, schedule, recipient, or recovery behavior is uncertain.

Open the relevant workspace

• PG Migrations
• Backup and restore
• Flowr pipelines
• Data Watchers
• Scheduled Workflows