Postgres is presented as a powerful, versatile database, but not a cure-all. While the book champions its broad use, it acknowledges that no single technology fits every workload. Rather than listing weaknesses—advice that could quickly become outdated as Postgres evolves—the author focuses on durable decision-making principles that remain relevant despite rapid ecosystem change.
Three pragmatic reasons are offered for choosing something other than Postgres. First, if another database clearly matches the use case better, avoid forcing Postgres into an ill-fitting role. Second, if an application already runs well on a different database, there’s no need to replace it purely for standardization or preference—even if the current solution is licensed and the cost is acceptable. Third, when the team’s expertise centers on another database and both options are viable, leverage that familiarity to ship faster, reduce errors, and handle production with confidence—while using the opportunity to broaden one’s own skills.
The author underscores this mindset with a real-world example: on a project running a document database successfully, they chose not to push a migration to Postgres. Instead, they learned the existing system and helped optimize it, cutting infrastructure costs by a factor of five. Even so, Postgres remains the author’s default choice, and readers are encouraged to keep investing in it as its capabilities and adoption continue to grow.
FAQ
Does Postgres replace all other databases?No. It isn’t a silver bullet or a universal tool for every workload, and some use cases are better served by other databases.Why doesn’t the appendix list specific Postgres weaknesses?Because the ecosystem evolves quickly; what’s hard or unsupported today may be easy a year or two from now, making static lists unreliable.What are the top reasons to choose something other than Postgres?Three main ones: another database clearly fits the use case better; an existing database already works well; or the team is more experienced with another database and both options fit equally.What if another database is a better fit for my use case?Use it. Don’t overengineer by forcing Postgres when another database can handle the requirements more easily.Should I replace a working database with Postgres just to standardize?No. If the current database does its job and there are no concerns, keep it—even if it’s a paid product the company is comfortable funding.How does team expertise influence the database choice?If both Postgres and another option suit the use case, prefer the one your team knows to ship faster, make fewer mistakes, and handle production issues more confidently.Is cost a good reason to switch from a paid database to Postgres?Not on its own. If the organization is satisfied with the cost and the database works well, there’s no need to switch purely for savings.How can I stay objective if I’m enthusiastic about Postgres?Evaluate the three reasons above before adopting it. Avoid replacing systems that already work and choose what best serves the project.Any example of choosing not to replace a non-Postgres database?Yes. The author kept a document database that worked well and helped optimize it instead, reducing infrastructure costs by a factor of five.What’s the parting advice on using Postgres?Keep investing in it: start using it if you’re new, or apply it to new use cases if you’re experienced—its ubiquity and adoption are growing.
pro $24.99 per month
access to all Manning books, MEAPs, liveVideos, liveProjects, and audiobooks!
Just Use Postgres! ebook for free
