Lock-In Is Not a Binary Decision
One of the major attractions of Postgres is the ability to stop using database software controlled by a single vendor. Single-vendor control means a single entity controls the software, tools, training, and support. There are sometimes options from other vendors, but they are usually hampered because the source code is closed.
Postgres is a strong move away from that, but is it always a complete disconnection from lock-in? Well, it can be — you could:
- Download the Postgres source code and compile it yourself
- Evaluate, integrate, and test the tools you need to use Postgres in your organization
- Create a training program for your employees
- Develop a Postgres internals team to support Postgres and your tools
- This is not possible for proprietary software, but because Postgres is open source, it is certainly possible.
However, once you have completed these steps, what do you have? No lock-in? Well, no vendor/external lock-in, but you do have internallock-in. Your staff is doing a lot of work, and any change in direction is going to be difficult. This also might be an expensive option due to staff costs. By choosing an external vendor, you can reduce costs, though you increase your external lock-in. (I covered this concept recently.)
So, lock-in isn't always a bad thing if it reduces costs or increases efficiency or flexibility. Importantly, you have the ability to switch vendors when advantageous, and since vendors know they can be easily replaced, they are less likely to be exploitative. Frankly, the problem to avoid is not lock-in as much as being a hostage of a single vendor.
This article was originally published on: https://momjian.us/main/blogs/pgblog/2019.html#March_5_2019