At some point, every team hits a wall with their database. Queries slow down, replicas get overloaded, or infrastructure starts to creak under growing traffic.
And then the thought pops up: maybe it’s time to switch to something better?
Modern databases promise a lot: built-in scalability, serverless everything, easy compatibility. Just export your data, point your app to the new system, and you’re good to go.
But if your database is in production with real users, jobs, dashboards, and data pipelines, a migration is rarely that simple.
In this post, I’ll walk through what actually makes migrations difficult, what we learned from running into this ourselves, and what to consider before switching systems.
Migrations seem simple at first
Most migration guides make it sound easy. Change your connection string, test a few queries, and move on.
And if it’s a side project or development environment, it might be that simple. But production databases are deeply connected to background jobs, dashboards, alerting, exports, and ETL pipelines. Unwinding all that is rarely plug and play.
Copying data at scale
Moving terabytes is slow and fragile. Transfers can overload your primary or fail midway. If replication falls behind, write-ahead logs grow and start affecting other workloads.
Keeping data in sync
You cannot shut down your production app. So you need to sync the old and new systems until cutover.
- Logical replication works but does not handle schema changes
- Change data capture is flexible but hard to get right
- Dual writes require extra app logic and can create inconsistent state
- Backfill plus delta sync reduces downtime but takes work to validate
Changing the application
Even if the new database is “compatible,” subtle things break:
- ORMs generate different queries
- Timezones, collation, and encoding can behave differently
- Extensions, functions, or triggers might be missing
- Roles and access control might not translate cleanly
You also need to coordinate updates across:
- Connection pools
- Secrets and credentials
- CI pipelines and infrastructure
Testing and validation
You will need to test everything that touches the database under production-like load, including:
- Background jobs
- API endpoints
- Internal dashboards
- Analytics queries
The long tail of edge cases is usually where things go wrong.
Timelines and tradeoffs
For a small app, a migration might take a few weeks. For more mature systems, the work can stretch into months.
And during that time, engineers are not building features or improving the product. The migration becomes the project.
Our own experience
At a previous company, we built near-realtime analytics dashboards powered by Postgres. Every hour, we ran jobs that updated large tables with web traffic data. At the same time, users triggered complex analytical queries against those same tables.
The write and read workloads collided. Dashboards lagged. Queries slowed down.
We considered two options:
- Move data to a warehouse
- Add read replicas
Both options looked good on paper. But in reality, each added more engineering work. The warehouse needed change data capture and application rewrites. Replicas needed either query splitting logic or proxying.
In the end, we optimized what we had and tried to buy more time. That experience later inspired what we’re building now.
Should you migrate?
Sometimes the answer is yes. Maybe your database is being deprecated. Maybe your architecture is shifting. But often, teams migrate because reads are slow, costs are rising, or infrastructure is getting harder to manage.
If that is the case, switching systems may not be the best move.
Another option
If your bottleneck is read performance, there might be an easier path.
Springtail adds elastic read capacity to your existing Postgres database without code changes, data migration, or new infrastructure. You don't need to rewrite queries or rearchitect your system.
You can learn more about how it works in our docs.
Top comments (0)