PostgreSQL: The Foundation of the PRVN Stack
This is the second in a series of posts about the PRVN stack, the toolkit that Ten Forward uses to make great web and mobile applications. As we discussed in the PRVN stack introduction last week, choosing a toolset is all about tradeoffs. At Ten Forward, we make tradeoffs that optimize for developer productivity, stability over the long term, and a strong community.
PostgreSQL: old but popular once again
The story of the tool we'll focus on today highlights the power of choosing stability as a principle.
One of the most important features of a web or mobile application is storing data over time. Business transactions, user logins, and the creative work of your site's users must be entrusted to a reliable tool with a proven track record. We've chosen a mature, rock-solid database - PostgreSQL - as the foundation of our stack, but this old tech is still turning heads after nearly 30 years.
Despite its age, nearly 30% of StackOverflow users say they use PostgreSQL and it's the most-loved database among developers. It's also the favorite database of 86% of programmers using Ruby on Rails (Rails), the application framework we use.
The hot new databases
Five or six years ago, many web developers were switching to newly-created databases like MongoDB. We took the conservative approach and stuck with PostgreSQL.
At the time, these newcomer databases were billed as a panacea, a decisive step forward in database technology where there were no downsides. These new databases would make it easier to get started with a project - you wouldn't need to think about how your data is structured ahead of time, just start saving data in whatever form you want. These new databases were designed to scale to multiple servers in multiple datacenters around the world - as your company became Facebook-sized, the database could grow along with you.
That's not how it turned out.
With the benefit of hindsight, we can now see that there were tradeoffs all along.
The tradeoffs
As applications matured and new fields were added to the newer databases, application code became a tangled mess of "if" statements to handle all the exceptions where an older database record was missing a newer field. Having stuck with PostgreSQL, we had to invest time up front in thinking about how the data should be structured, but saved ourselves from having to rewrite parts of applications as the data structure changed.
Operating at scale is hard, and designing for scale is not simple or cheap. Plus, multi-server databases can make it tempting to "just throw more hardware" at a problem, instead of developing smart, performant software that needs fewer computing resources in the first place.
The problem of scale is not a realistic concern for 99.99% of web applications. In fact, a single PostgreSQL database server can write over 1 million rows every second ( although if you need a web application with over 10 million daily users, we would be more than happy to help you write it!).
PostgreSQL: back in the limelight
After the wave of new databases passed and developers learned more about the tradeoffs they'd have to make using them, attention turned back to the tried-and-true PostgreSQL. It's in the middle of a huge increase in popularity and adoption.
Some of that can be attributed it to being a current trend/fad like those new databases 5 years ago, but we think it has more to do with the fact that PostreSQL is open-source, not owned by one company, and has incorporated major improvements in the past few years. These new features were previously only found in the newcomer databases.
PostgreSQL has combined the durability and reliability guarantees of an older database with the rich features of a modern database, and we're proud to use it as the foundation of the PRVN stack.