Should I use PostgreSQL if I want to avoid vendor lock-in?

Yes—PostgreSQL is a strong choice if you want to minimize vendor lock-in, but it doesn’t eliminate lock-in entirely.

Why PostgreSQL helps

• Open source and widely supported
• Portable data model and SQL
• Runs on many clouds and on-prem
• Large ecosystem of tools, ORMs, drivers, and managed service providers
• You can usually move your database between vendors with less friction than with proprietary databases

Where lock-in can still happen

Even with PostgreSQL, you can still get locked in through:

• Cloud-specific managed features
  e.g. proprietary backups, replication options, extensions, IAM integration
• Postgres extensions that aren’t available everywhere
• Application code tied to one provider’s tooling
• Operational dependencies like monitoring, failover, and migrations built around one platform
• Schema/query assumptions that are hard to port later

Best way to reduce lock-in

If lock-in is a major concern, use PostgreSQL plus these practices:

• Stick to standard SQL where practical
• Avoid cloud-specific database features unless necessary
• Keep migration scripts and backups under your control
• Use portable infrastructure (e.g. Docker/Kubernetes/Terraform where appropriate)
• Abstract database access thoughtfully, but don’t overdo it
• Test restore and migration to another environment regularly

Bottom line

If your goal is to stay as portable as possible, PostgreSQL is usually one of the best mainstream choices.
If your goal is to eliminate vendor lock-in completely, no database can guarantee that—but PostgreSQL gives you a much better position than most proprietary alternatives.

If you want, I can also compare PostgreSQL vs MySQL vs a cloud-managed proprietary DB specifically for lock-in risk.