Worried about Vendor Lock-in?

Unlike Open source technologies such as PostgreSQL, most Database vendors (think Oracle, Microsoft, IBM, SAP) offer a suite of products, and obviously they will try to convince you to use more components in their technology stack. The benefits you may achieve by doing so include:

  • A lower overall cost (relative to buying different pieces of the stack from different vendors).
  • Tighter and better integration between components of the stack resulting in fewer problems.
  • The ability to leverage knowledge and expertise across applications.
  • A single support organization to deal with if there is a problem.

Needless to say every one of these benefits are very attractive.

Large vendors will offer enterprise (“all you can eat”) license agreements for a limited period of time to have an organization consume as much technology it wants to come back at the end of the period and renegotiate the cost based on then actual use of the technology. The more you use, the more you end up paying, and that is exactly the way the vendors like it.

Lower single vendor dependencies with Open Source PostgreSQL

What if you want to lower your dependency on a single vendor and introduce another vendor’s or even Open Source technologies into the mix? This can be a big risk. However, when it comes to swapping out database technologies (with multiple good options – likely good enough for what you use the database for) know that you can mitigate the risk by using a heterogeneous data replication technology like HVR to mitigate the risk. HVR 5 introduced support for Open Source PostgreSQL as a source for log-based, real-time Change Data Capture making it easier to introduce Open Source into a mix of transactional database technologies from vendors like Oracle, Microsoft, IBM and Actian.

Database migration steps

At a high level the database migration scenario goes as follows:

    1. Set up the secondary database. With HVR consider using its schema creation as the starting point for your new database.
    2. Perform an initial load of the database application tables. HVR enables on-line refresh to avoid downtime on the source database.
    3. Start real-time replication to keep your new database in sync with the current one.
    4. At this point users can start validating the new setup and run non-intrusive reports on the new system that is synchronized in real-time. You may also use HVR’s compare functionality to identify whether systems are in sync.
    5. Once you feel comfortable with the new technology switch the application to start using the new database. Also switch the flow of the real-time replication so that the new database continues to keep the old database in sync in real-time. This reverse data flow is the safety net if for whatever reason the new setup does not work as expected then you can always temporarily switch back to the old setup with no data loss.
    6. Disable the replication and stop using the old setup.

If the application allows for an active/active setup then you may even run two implementations of the application concurrently whilst you validate the new technology stack.

Would you like to limit vendor lock-in? Give HVR a try!

About Mark

Mark Van de Wiel is the CTO for HVR. He has a strong background in data replication as well as real-time Business Intelligence and analytics.

© 2019 HVR

Try now Contact us