The engine is often not the painful part anymore. The pain is the stuff around it: live DBs, S3 paths, Parquet files, credentials, repeatable runs, exports, validation, and the moment a one-off script quietly becomes infrastructure.
Quack makes the remote/server part cleaner, but the bigger trend seems to be DuckDB becoming the SQL layer inside tools, not necessarily the final user-facing tool.
A self-hosted database IDE with built-in migration, CDC, and DuckDB-powered federated SQL.
Mostly trying to remove the annoying gap between "I can inspect this database" and "I can safely move/sync this data somewhere else".
Current focus: resumable large loads and cleaner initial-load-to-CDC handoff for Postgres/MySQL.
moving data between DBs still feels more manual than it shouldmost workflows look like: IDE -> export -> scripts -> pipeline -> CDCso tried collapsing that into one tool:query across PostgreSQL / MySQL / files use the query as a data source move it then turn on CDCruns locally or via Dockerwould love feedback, especially on: whether query-as-pipeline makes sense or if...
Trying to collapse what is usually:
SQL IDE -> export/scripts -> pipeline -> CDC -> back to SQL
into a single workflow instead of stitching 3–4 tools together.
Runs locally or via Docker, no Kafka / heavy setup.
Every data workflow I touched had the same shape:- explore schema in one tool - write and test queries in another - run the migration separately - set up CDC sync somewhere elseEach tool does its job fine. But the switching, glue scripts, and "wait, which connection config was this?" start to add up.So I built DBConvert Streams 2.0, a self-hosted tool that keeps the whole workflow in one...
Replicate data and synchronize changes from MySQL and PostgreSQL, enabling applications to respond to these changes in real-time with minimal latency.
2) Published COVID-19 widgets website https://covid-19.dataflowkit.com/