A few months ago I joined the SaaS Developer Community to learn more about challenges SaaS developers face.
The community has a podcast series with guests discussing technical topics related to SaaS.
I recently had the chance to join the host Gwen on the podcast series in an episode discussing PostgreSQL, Ruby on Rails, and high performance for web applications.
In this post I’ll recap and expand on some points from our discussion.
Outline
- SaaS Developer Community
- Why did I choose to write about PostgreSQL and Rails?
- Advocating for PostgreSQL and Rails
- Database Skills for Developers
- ORMs and SQL
- N+1 Query Pattern Problem
- Read and Write Splitting
- High Request Volume
- PostgreSQL Resources
- Community Links
- Full Interview
First I wanted to highlight the SaaS Developer Community.
The community is run by Gwen Shapira, co-founder and CPO of Nile, and has a couple of thousand members. There is also a video podcast series on YouTube.
Check it out!
Why did I choose to write about PostgreSQL and Rails?
I’ve worked with this stack for many years and more recently with a focus on PostgreSQL. This is a mature and reliable open source stack of tools, that’s also productivity centric. I like working with Ruby and I also like SQL!
I also think there’s an opportunity in the market to help teach PostgreSQL skills to developers. At the same time, Active Record keeps gaining features that help big companies scale their Rails applications.
Advocating for PostgreSQL and Rails
A confluence of factors happened in 2020 for me that sparked my interest in these topics.
The first was a curiosity to learn PostgreSQL in greater depth than what I’d done so far as an application developer.
The second was the opportunity to put what I learned into practice right away at a business operating a high scale Rails application.
The application was suffering from common PostgreSQL operational problems like high bloat from Autovacuum falling behind, so that’s where we started.
The team did not have a dedicated DBA that might have otherwise already solved the problem. Our team needed to develop some specialized database operational skills but we were all application developers, so there was an opportunity there to expand outside the comfort z
