I replaced my entire tech stack with Postgres...

PostgreSQL can replace a surprising chunk of a typical web “tech stack,” letting developers build full applications with fewer external services by leaning on built-in features and a large extension ecosystem. The core pitch is simple: instead of paying for separate tools for caching, cron jobs, search, analytics, APIs, realtime syncing, and even authentication plumbing, many of those needs can be handled inside PostgreSQL—often with extensions—so the database becomes the central system rather than just a data store.

The case starts with what makes PostgreSQL different from simpler SQL databases: advanced data types (including JSONB, arrays, key-value patterns, binary data, and geometric types) and, crucially, extensibility. That extensibility has produced an ecosystem where developers “mod” the database with new capabilities. The transcript also includes an important caveat—just because PostgreSQL can do something doesn’t mean it should—framing the approach as a tool-selection problem, not a blanket replacement of every specialized service.

From there, the examples move through common “infrastructure” tasks that teams often outsource. For unstructured or semi-structured data, JSONB lets each row carry different shapes while still supporting SQL queries that filter and access fields inside the JSON. For scheduled work, the PG cron extension provides database-native cron jobs, running SQL on a schedule without editing system cron tabs or paying for a separate scheduler.

Caching is treated as a “maybe you don’t need Redis” moment. The transcript proposes a “poor man’s Redis” using unlogged tables as a cache, trading durability for speed by disabling write-ahead logging for that data. It then suggests tuning PostgreSQL to keep cache-like data in shared buffers, using autovacuum to prevent bloat, and optionally combining with PG cron to expire entries.

AI and search are handled with extensions rather than separate vector databases or search engines. PG Vector adds a vector type for embeddings and nearest-neighbor queries using distance metrics like L2. The pgai extension goes further by supporting embedding workflows and loading datasets via SQL. For typo-tolerant search, TS Vector and generalized inverted indexes support ranking and querying with the @@ operator, reducing reliance on services like Algolia or Elasticsearch.

The stack gets more “full” as the transcript adds API and frontend integration. The PG graphql extension turns the database into a GraphQL API directly from SQL-defined resolvers, avoiding extra servers and middleware. For realtime data updates, Electric SQL is positioned as a sync layer between the database and the frontend, reducing the need for websocket-heavy custom code. For authentication and authorization, PG crypto and PG JWT show how to hash passwords, sign JSON Web Tokens, and enforce Row Level Security policies so users can only read and write rows they own.

Finally, the transcript covers analytics and delivery. PG mooncake converts PostgreSQL into a time-series-oriented system with column-store execution (via DuckDB execution) and supports dropping data into cloud storage and visualizing with tools like Grafana. PostgREST then exposes tables as a RESTful JSON API with features like filtering, pagination, and authentication. The endgame is storing HTML/CSS/JavaScript in the database itself—pushing application logic and UI assets closer to the data layer than most stacks typically allow.