Skip to content
0:00 / 0:00

#postgres#postgrest#pg_cron

I replaced my entire tech stack with Postgres...

Fireship

4.3M subscribers • 25 videos on Hallway

YouTube
  • Recommended by 1 person: 1 in engineering communities.
  • An opinion. It argues one side of a question engineers disagree on.

Beginner. No background in the topic needed.

1.6M views1 year ago1 recommendation

Databases and dataWeb developmentPostgresFull-stack frameworks

An exploration of ten unusual ways to use PostgreSQL as a full-stack application backend, including queues, cron jobs, and APIs.

Sign up for Neon and create up to 10 Postgres databases for free fyi.neon.tech/fireship Learn 10 unusual ways to use PostgreSQL to build a fullstack applications from scratch and harness the full power of this awesome relational database. #programming #database #webdevelopment 💬 Chat with Me on Discord discord.gg/fireship 🔗 Resources Postgres in 100 Seconds youtu.be/n2Fluyr3lbc SQL Tutorial youtu.be/Cz3WcZLRaWc 📚 Chapters 🔥 Get More Content - Upgrade to PRO Upgrade at fireship.io/pro Use code YT25 for 25% off PRO access 🎨 My Editor Settings - Atom One Dark - vscode-icons - Fira Code Font 🔖 Topics Covered - Cool things you can do with PostgreSQL - SQL tips - How to build a fullstack app with Postgres - Advanced database tips

Why it's here

1 person recommends this

What people say. Shared as a popular video discussing the controversial idea of using PostgreSQL for the entire application stack.

u/cachedriveDBAin r/PostgreSQL • Recommends

I replaced my entire tech stack with Postgres...

u/prophase25in r/PostgreSQL • Mentions

Is "full-stack" PostgreSQL a meme? By "full-stack", I mean using PostgreSQL in the manner described in Fireship's video I replaced my entire tech stack with Postgres... (e.g. using Background Worker Processes such as pg_cron, PostgREST, as a cache with `UNLOGGED` tables, a queue with `SKIP LOCKED`, etc...): using PostgreSQL for *everything*. I would guess the **cons** to "full-stack" PostgreSQL mostly revolve around *scalability* (e.g. can't easily horizontally scale for writes). I'm not typically worried about *scalability*, but I definitely care about *cost*. In my eyes, the biggest **pro** is the reduction of *complexity*: no more Redis, serverless functions, potentially no API outsi…