slotix

2 miesiące temudiscuss

[dead]

2 miesiące temudiscuss

I read it less as "DuckDB wants to become Postgres" and more as DuckDB becoming an execution layer inside bigger workflows.

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.

slotix

2 miesiące temudiscuss

We are working on DBConvert Streams:

https://streams.dbconvert.com

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.

slotix

2 miesiące temudiscuss

We wrapped exactly this into a GUI - attach MySQL and PostgreSQL, files/ s3 as sources, query them together with DuckDB. No imports. https://streams.dbconvert.com/cross-database-sql

slotix

3 miesiące temudiscuss

Working on database tooling around data movement + CDC.

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.

https://streams.dbconvert.com/

slotix

3 miesiące temudiscuss

Happy to answer questions about architecture, tradeoffs, or specific use cases.

Submissions

[untitled]

[untitled]

[untitled]

[untitled]

[untitled]

[untitled]

Show HN: DBConvert Streams 2.0 – explore, migrate, sync. No pipeline glue

Why database tools are split – and that's the real problem

Show HN: I got tired of juggling 4 tools for data work – built one instead

comments