What we build with it
PostgreSQL is where product data lives on most of what we build. Not because it is fashionable, but because it is the database that keeps being the right answer: real transactions, real constraints, JSON columns when a schema genuinely needs to be flexible, and full-text search that removes the need for a second system on most products.
The work that matters here is rarely the choice of database. It is the schema — getting the model right early, putting constraints in the database rather than hoping the application enforces them, and indexing for the queries the product actually runs.
Where we have shipped it
The white-label cashback platform and the Formtastic platform both run on PostgreSQL, the latter under load as a system explicitly built for growth.
We wrote up the part teams most often get wrong in how databases and indexes actually work, and the money-specific trap in floating point and money — store currency as integers or numeric, never as a float.
When we recommend it
As the default for anything transactional. A single well-indexed PostgreSQL instance handles far more than most teams assume, and it is cheaper to run one database well than three databases badly.
Reach for something else when the workload genuinely is not relational — a time-series or analytics store for high-volume telemetry, a cache for hot ephemeral state. Those sit next to PostgreSQL rather than replacing it.
