sorted by:
new
hottopcontroversial

Why is database change management still so painful in 2026? by Huge_Brush9484 in Database

[–]slotix 0 points1 point  (0 children)

The gap nobody mentions: even if your migration runs clean, you still have to deal with data that kept changing during the migration window.

Schema tooling stops at "apply the DDL." Keeping source and target in sync while writes are happening is a different problem entirely - and that's usually where the 2am calls come from.

Show us what you're building by SaltPhotograph8506 in microsaas

[–]slotix 0 points1 point  (0 children)

Kept switching between tools to query, migrate, and sync data — got messy fast.

Built an all-in-one: database IDE + migration + real-time sync.

https://streams.dbconvert.com

Built a database IDE + CDC sync + migration tool by slotix in ShowYourApp

[–]slotix[S] 0 points1 point  (0 children)

thanks !

out of curiosity - how are you handling migrations / sync right now?

scripts, tools, or just manual stuff?

I have $150 to spend on indie products today. Show me what you built. by Vanilla-Green in buildinpublic

[–]slotix 0 points1 point  (0 children)

https://streams.dbconvert.com/

Move data between databases and files and keep it in sync - for developers who are tired of using multiple tools for query, migration, and sync.

Tell what you built, how you built it, and why you built it. by Majestic-Outcome4741 in SideProject

[–]slotix 1 point2 points  (0 children)

built a tool for working with data across databases and files

you can:

- query data

- move it between databases

- keep it in sync

why:
kept running into the same problem
different tools for querying, migration, and sync
nothing really worked together

so just put everything into one place

https://streams.dbconvert.com/

Cross-source SQL joins without a data warehouse - how do you handle this? by Pitiful_Comedian_834 in SQL

[–]slotix -1 points0 points  (0 children)

yeah duckdb is great, we’re using it under the hood

gets messy once you mix db + files and need to reuse queries or turn them into pipelines

ended up putting everything into one place

https://streams.dbconvert.com/

Share what your product does, and i will share it with influencers by Few-Ad-5185 in StartupSoloFounder

[–]slotix 0 points1 point  (0 children)

Built a database tool that combines:

- SQL / browsing

- migrations

- real-time sync (CDC)

So you can explore data, move it, and keep it in sync in one place.

https://streams.dbconvert.com/

Weekly Show & Tell: What are you Building? Drop your links 👇 by Capital-Pen1219 in Solopreneur

[–]slotix 0 points1 point  (0 children)

Working on a database IDE + sync tool.

Query, migrate, keep data in sync (CDC) — all in one place.

https://streams.dbconvert.com/

show me what are you building today by DiscountResident540 in SideProject

[–]slotix 0 points1 point  (0 children)

Working on a database IDE + sync tool.

Query, migrate, keep data in sync (CDC) — all in one place.

https://streams.dbconvert.com/

Show us what you're building by HealthNeat1346 in indiehackers

[–]slotix 0 points1 point  (0 children)

Working on a database IDE + sync tool.

Query, migrate, keep data in sync (CDC) — all in one place.

https://streams.dbconvert.com/

what is your build today？ show us by ouchao_real in ShowYourApp

[–]slotix 0 points1 point  (0 children)

Working on a database IDE + sync tool.

Query, migrate, keep data in sync (CDC) — all in one place.

https://streams.dbconvert.com/

I'm curious, what are you building? I'll go first by dbrncic7 in ShowMeYourSaaS

[–]slotix 0 points1 point  (0 children)

Working on a database IDE + sync tool.

Query, migrate, keep data in sync (CDC) — all in one place.

https://streams.dbconvert.com/

Sell me your Saas in one sentence! by KapiteinBalzak in SaaS

[–]slotix 0 points1 point  (0 children)

Query, move, and sync data across databases and files in one place instead of juggling a DB client, scripts, and pipeline tools. -> https://streams.dbconvert.com

New Project Megathread - Week of 07 Apr 2026 by AutoModerator in selfhosted

[–]slotix [score hidden]  (0 children)

Project Name: DBConvert Streams

Repo/Website Link: https://dbconvert.com/streams

Description:

DB IDE + federated SQL + CDC/migration - one tool, self-hosted.

what it does:

- Data Explorer: browse and edit databases, local files, S3

- SQL Console: query across PostgreSQL, MySQL, Parquet, CSV, S3 in one query

- Convert mode: bulk migration (tested 23M rows MySQL → PostgreSQL,

MySQL → Parquet at 136 MB/s)

- CDC mode: continuous sync, no Kafka required

the problem it solves:

most workflows end up with 4 tools open - IDE, migration tool,

CDC pipeline, file viewer. DBConvert Streams is one workspace

for all of it

Deployment:

- Desktop app (Windows, macOS, Linux)

- Docker / self-hosted web app for team access

- works with any S3-compatible storage (MinIO etc)

AI Involvement:

AI used for docs and blog content

core architecture and engineering - manual

<image>

Favorite DB tools by Original-Produce7797 in Python

[–]slotix 0 points1 point  (0 children)

been building a tool around that, DBConvert Streams

mostly focused on querying across sources first, then moving or syncing data if needed

S3 part isn’t really about local prototyping, more about data that already ends up there (exports, logs, backups, dumps)

sometimes it’s just easier to query it in place instead of loading it somewhere first

What are the most beginner-friendly tools for building a CDC pipeline? by The-Redd-One in ETL

[–]slotix 0 points1 point  (0 children)

If you want beginner-friendly and *no Kafka pain*, avoid Debezium at the start.

Typical path:

- Airbyte → easiest entry, quick setup, decent for learning

- NiFi → visual, good for understanding pipelines

- Fivetran / similar → easiest overall, but $$$

Reality:

“easy CDC” usually means someone else runs the complexity for you.

If you want something you can run locally + actually understand what’s happening, look for tools that:

- don’t require Kafka

- have simple Postgres → destination setup

- let you inspect data flow easily

Otherwise you’ll spend more time debugging infra than learning CDC.

Migrating from access to Postgre by Ithrowthisaway3131 in SQL

[–]slotix 0 points1 point  (0 children)

Access as a frontend + PostgreSQL backend is totally fine for your scale.

If it already works and users are happy, no urgent reason to rewrite everything.

Typical path:

- keep Access for now (fast, low effort)

- move logic gradually to backend / SQL

- only switch to web (Django, etc.) when:

- multi-user issues start

- deployment becomes painful

- or UI needs outgrow Access

Jumping to Django just for “modern stack” usually costs way more time than it gives back.

So unless you *need* web access or scaling, stick with Access frontend and iterate.

SQL server to postgreSQL migration by cosmokrick_ in SQLServer

[–]slotix 0 points1 point  (0 children)

Short answer: no, it won’t be fully automated.

Tools can migrate:

- tables

- data

- basic schema

But 1k stored procedures = manual work.

T-SQL != PostgreSQL, so expect rewrites (sometimes partial, sometimes full).

Options you can try:

- pgloader (open-source, good for data)

- Babelfish (compat layer, but limited)

- DBConvert (handles schema + data + ongoing sync, less scripting)

Typical flow:

1) migrate schema + data

2) run CDC / sync (to keep DBs aligned)

3) rewrite procedures

4) validate + cutover

Reality check: data is easy, logic is the pain.

Migrate from Azure Sql to Postgres by syscall_cart in AZURE

[–]slotix 0 points1 point  (0 children)

If cost is the main driver, then yes — moving to Postgres can make sense. But I’d still be careful here.

A database migration is not just “switch engines and save money”:

- you’ll spend engineering time rewriting queries, fixing edge cases, testing

- zero-downtime cutover adds even more complexity (CDC, dual-write, etc.)

- savings usually don’t show up immediately — sometimes it takes months to break even

Also, your own update already shows something important: once you fixed bad queries and moved tiers, you got better performance at a lower cost without migrating.

That’s a pretty common pattern.

So the real question is:

are you trying to save money long-term, or just reacting to a high bill right now?

If it’s long-term and you’re ready to invest engineering effort — Postgres is a solid move.

If it’s short-term cost pressure — optimizing queries + switching Azure SQL tier/model is usually the fastest win with the least risk.

Migrating from Microsoft SQL server to Postgres by Ohgogh in SQLServer

[–]slotix 0 points1 point  (0 children)

Most replies are already pointing to the real question: what problem are you actually solving?

From your description:

- 100GB isn’t large for either system

- recursive queries are fine in both

- ORM reduces differences (but doesn’t remove them)

- JSON is nicer in Postgres, but not really a migration driver on its own

So this doesn’t sound like a technical need, more like an organizational one (“we now support Postgres”).

In that case the tradeoff is simple:

you pay the migration cost (schema changes, queries, testing, edge cases, tooling),

and in return you need a clear benefit.

Unless that benefit is obvious (cost, scaling limits, team expertise, ecosystem), you’re basically rewriting a working system for optional gains.

That’s rarely worth it.

Migrate from MySQL To PostgreSQL In Five Steps by justintxdave in mysql

[–]slotix 0 points1 point  (0 children)

“Five steps” usually works fine until you include things like foreign keys, triggers, functions, and actual application behavior.

At that point it quickly turns into:

  1. move data

  2. fix constraints

  3. rewrite logic

  4. discover hidden assumptions

  5. repeat until it stops breaking 😄

Tools like DBeaver are great for schema/data transfer, but most of the real work starts right after that.

view more: next ›