Greetings,
Given that the bulk of your existing tools are self-contained with optional links to your other tools, I have to ask why you guys are requiring PostgreSQL here.
I could understand if PostgreSQL were an optional data store, but from what I have been able to determine, everything you are using the PostgreSQL DB for could be handled by Vault, Consul, SQLite, etc.
Hi there…totally fair question!
Early on we made a determination that this was a much, much bigger domain (and with different runtime characteristics) than what could be achieved via a Vault secrets engine. (This is also taking into account the needs of a very deep roadmap we have for Boundary.) There was too much complexity, too much coordination, arbitrary network connections and listeners, we wanted a different permissions model, and didn’t want to be tied to a Vault plugin lifecycle.
We also have a lot of experience with Vault in trying to approximate RDBMS semantics via in-memory indexes and the drawbacks and challenges that result. Given that the problem domain lends itself extremely well to a relational model, rather than try to coordinate transactions between various in memory indexes and disk writes, we decided that overall we could make a better, more consistent, and overall easier to operate product by using a real RDBMS.
As for Postgres: it’s fast, well-regarded, extremely stable, widely available (every cloud and PaaS has managed offerings if you don’t want to run it yourself), widely deployed (so there is a lot of operator experience), and free/OSS. That said, we may well support other RDBMSes in the future…we purposefully avoided depending on Postgres-specific capabilities.
Sqlite is unlikely to be on that list, however, as it doesn’t natively support network access or multiple concurrent processes with the database open (so you can’t get around the first problem via e.g. NFS).
Hope this explains things!