dbHydrate01
SOURCE / READ ONLYDevelopment
app.orders+ status varchar(32)+ idx_orders_statusPOSTGRESQLSelected stage
COMPARE. REHEARSE. HYDRATE.
Database changes.
Without the guesswork.
Compare schemas, review the plan, and refresh environments with selected, masked data.
Commerce DevelopmentSOURCE · DEV
public.customers
id bigintfirst_name varchar(80)email varchar(255)+ phone varchar(32)REVIEWED SQL✓
Inspect the plan before applying.ALTER TABLE public.customersADD COLUMN phone varchar(32);CREATE INDEX idx_customers_emailON public.customers (email);
Commerce UATTARGET · UAT
public.customers
id bigintfirst_name varchar(80)email varchar(255)phone varchar(32)Illustrative schema journey
THE COMPLETE WORKFLOW
See dbHydrate in action.
From choosing connections to a recorded change. Watch the workflow, or explore each step at your own pace.
Illustrative PostgreSQL example · No live databaseConnect → Review → Rehearse → Apply
SCHEMA SYNC / POSTGRESQL
Local workspaceSet up your comparison
Commerce Development Commerce UAT
1 Configure2 Review3 Validate4 Apply
SOURCE CONNECTION
Choose a saved connection
The desired schema comes from your source
TARGET CONNECTION
Choose a saved connection
Check the environment before proceeding
SOURCE SCHEMA
publicTARGET SCHEMA
publicCompare first. Decide what belongs.
Inspect schema differences and generated SQL before making a change.
01 / 18
Plays when in view01
Choose your source.
Start with a saved development connection. Source sessions are read only.
PRODUCT AVAILABILITY
Products are not available right now.
Check again shortly for current products and download options.
Check download availabilityUnderstand the change.
Then make it.
Security & privacy Review before you apply
Inspect differences and generated SQL.
Rehearse the plan
Test the plan with an engine-specific dry run.
Keep database processing local
Database work runs on your computer.
ONE WORKSPACE. THE WHOLE PICTURE.
The context stays
with the change.
Move from schema review to selected data, queries and inspection without losing your source and target context.
Choose your tables, filter your rows, and include their relationships.
Try a schema review in your browser
CLARITY AT EVERY STEPInteractive product illustration
SCHEMA SYNC
Review your changes
SOURCEdevelopment
DevTARGETsandbox
SandboxCHANGES 3
No deletions in this plan
-- Preview before you apply
1ALTER TABLE app.orders2 ADD COLUMN status varchar(32)3 NOT NULL DEFAULT 'pending';Reviewed SQL. No hidden changes.
You review. You approve.
Illustrative workflow with sample data. This preview does not connect to a database.
FROM YOUR WORKSTATION TO YOUR WORLD
Your laptop. Your cloud.
A considered change.
Explore how schema changes and test data move between local and production environments—with review at the center.
ENVIRONMENT MAPPOSTGRESQL / PROMOTE
Compare a source schema, review the SQL, then confirm the protected target.
02
SQL / IMPACT / GATESChange review
2 selected changesDependencies orderedReview before applyREVIEW GATEExample
03
PROTECTED TARGETProduction
Dry run requiredSnapshot requiredConfirm database namePOSTGRESQLExample
01Compare schemas02Review generated SQL03Confirm the target
Illustrative workflow · no database connection
THE REVIEW SEQUENCERead the PostgreSQL workflow
See development beside production.
Connect two databases of the same engine. Compare the current schemas and select the objects that belong in this change.
LOCAL DEVELOPMENTREVIEW & REHEARSALCLOUD PRODUCTION
TWO DIRECTIONS. ONE CONSIDERED PROCESS.
Move changes forward.
Bring useful data back.
Choose the workflow for the job. Source and target use the same database engine.
01 / SCHEMA PROMOTIONReview the difference.
Keep the test case.
DevelopmentUATProduction
Review the difference.
Decide the next move.
Compare a baseline with your target. Inspect the plan and resolve unexpected drift through review.
Explore schema drift detection 02 / TEST DATA REFRESHProductionMaskSandbox
Keep the test case.
Replace selected details.
Choose the useful rows, include required relations, and review masked values before copying.
Explore selected data refreshSchema comparison, selected data, reusable masking, local history, user administration and CLI workflows. Review engine support and limitations before choosing.
Compare capabilitiesBEFORE YOUR NEXT CHANGE
Good questions.
Clear answers.
Which dbHydrate product should I choose?
No products are currently published. Check the trial page for availability.
How much does a dbHydrate license cost?
No products are currently available for purchase.
Can I refresh a test environment with selected data?
Yes. Copy whole tables, test a WHERE condition, select primary-key rows, or apply a row limit. Include related rows, review masking rules, and use fixed column overrides for environment-specific values. Row limits are not a guarantee of a representative random sample.
Can I reuse masking rules across copies?
The reusable masking dictionary supports wildcard column patterns, categories, enabled/disabled rules, deterministic seeds, and a live playground. Rules include Faker replacements, salted hashes, regex replacements, fixed strings, and NULL. Column overrides run after masking, so review final values. Presets are configuration aids, not compliance certification.
What does verify mean in this workflow?
Inspect recorded SQL and run results, then compare source and target schemas again. The current documented scope does not promise automated row-by-row reconciliation or checksum verification; those are development opportunities.
Will my connections and appearance settings persist?
The application uses a persistent local data location for saved connections, settings, and history, with migration of legacy configuration during upgrades. Light, Dark, or System appearance preferences are saved. Database and schema discovery also keeps a manual-entry fallback.
Which databases does dbhydrate support?
No products are currently published. Check the trial page for availability.
Can I migrate PostgreSQL to MySQL?
dbhydrate synchronizes environments of the same engine: PostgreSQL to PostgreSQL, or MySQL to MySQL. It does not convert schemas or data between database engines.
What happens before a change reaches production?
Every run opens Review & Confirm with the change list and generated SQL. High-protection targets require a passing dry run, a pre-apply snapshot, and a typed database-name confirmation. The target schema is checked again before execution; if it has changed, you must compare again.
Can schema changes be rolled back?
PostgreSQL changes in the transactional phase roll back automatically on failure; some operations run in a separate phase. MySQL DDL commits one statement at a time and cannot roll back automatically. dbhydrate records applied steps and generates rollback SQL for review. Schema rollback scripts do not reverse copied data; restoring data requires an appropriate data export.
How does sensitive data masking work?
When copying from a higher-protection source to a lower-protection target, every copied column needs an approved masking rule or an explicit “Not PII” decision. Values are transformed in memory before writing to the target. Detection uses column names and local samples, with no AI service.
Where are my credentials and run history stored?
App state stays in local files on your computer. Saved database passwords and SSH secrets are encrypted with AES-256-GCM, protected by your master password. Run history records the exact SQL and results without credentials. Database connections still communicate directly with your chosen servers.