---
categories: [aws]
date: 2026-02-23 00:00:00 +0000 UTC
lastmod: 2026-02-23 00:00:00 +0000 UTC
publishdate: 2026-02-23 00:00:00 +0000 UTC
series: [AWS]
slug: postgresql-the-only-database-you-need
tags: [postgresql aws aurora aurora-dsql rds-data-api nosql graph vector react supabase]
title: PostgreSQL: The Only Database You Need
---

Let's assume that we are starting a new system today.
What database should we pick first?

My answer is simple: PostgreSQL.
Start with SQL. Keep SQL. Add more capabilities when needed, without changing the database every quarter.

## Start from SQL, then go to Aurora DSQL

PostgreSQL gives us ACID transactions, joins, indexes, and a mature query planner.
For many teams this is already enough for years.

But what if we need global scale and multi-Region architecture?
Aurora DSQL keeps PostgreSQL compatibility and adds serverless distributed infrastructure.
Same SQL mindset, bigger scale envelope.

## Need NoSQL? PostgreSQL can do it too

PostgreSQL `jsonb` allows document-style workloads in the same database.
You can keep semi-structured payloads, add JSON indexes, and still join with relational tables.

So yes, when somebody says "Now we need NoSQL", in many cases PostgreSQL is already enough.

## Need API access? RDS Data API can do it

With Aurora + RDS Data API, we can execute SQL over HTTPS API calls, with IAM and Secrets Manager integration.
This works well for serverless and event-driven systems where long-lived DB connections are not ideal.

And if you want a full backend platform around PostgreSQL, Supabase is another popular route:
PostgREST/GraphQL APIs, auth, realtime, storage, and dashboard on top of Postgres.

## Need graph? We can do it

There are at least three ways:

1. Use recursive CTE (`WITH RECURSIVE`) for hierarchy and graph-like traversals.
2. Use extension-based approach (for example Apache AGE) for property-graph style queries.
3. Use `pgRouting` (usually with PostGIS) for shortest-path and graph traversal problems.  
   Supabase has a practical write-up here: [Postgres as a Graph Database: (Ab)using pgRouting](https://supabase.com/blog/pgrouting-postgres-graph-database)

## Need vector search? We can do it

With `pgvector`, PostgreSQL can store embeddings and run similarity search.
This is enough for recommendation, semantic search, and RAG-like retrieval, while transactional metadata stays in the same place.

## Need cronjobs, pub/sub, and background patterns? We can do it

This is another area where people often add extra systems too early.
PostgreSQL already gives us many useful building blocks:

1. Cron-like jobs with `pg_cron` for periodic SQL tasks (cleanup, rollups, sync jobs).
2. Lightweight pub/sub with `LISTEN` and `NOTIFY` for near-real-time app events.
3. Durable queue workers with `FOR UPDATE SKIP LOCKED`.
4. Outbox pattern: write business data + event in one transaction, then publish safely from outbox table.
5. Retry and dead-letter behavior with status columns (`pending`, `processing`, `failed`) and retry counters.
6. Idempotent job execution using unique keys, constraints, and advisory locks.
7. Supabase path: Postgres changes can flow into Realtime subscriptions for client updates.

Do we still sometimes need Kafka, SQS, or EventBridge? Yes, of course.
But for many product workloads, starting from PostgreSQL patterns is simpler and faster.

## Need backend for React app? Yes, also possible

Typical pattern:

1. React frontend
2. API layer (Node/Express, Lambda, or GraphQL resolver)
3. Aurora PostgreSQL or Aurora DSQL
4. Optional RDS Data API for HTTP-based SQL calls

Reference: [React App video](https://www.youtube.com/watch?app=desktop&v=3JW732GrMdg)

Also popular: React + Supabase client + Supabase Auth + Postgres database.

## 25 things you can do with PostgreSQL (and Aurora PostgreSQL-compatible options)

1. Core OLTP transactions with ACID guarantees
2. Complex relational joins across normalized models
3. Window-function analytics in SQL
4. Recursive hierarchy traversal with `WITH RECURSIVE`
5. Background worker queues with `FOR UPDATE SKIP LOCKED`
6. Materialized views for precomputed reads
7. Declarative partitioning for large tables
8. Row-level security for multi-tenant isolation
9. Logical replication and CDC pipelines
10. Cross-database federation with `postgres_fdw`
11. Document workloads via `json` and `jsonb`
12. JSON field indexing with GIN
13. Full-text search and ranking
14. Event signaling with `LISTEN` and `NOTIFY`
15. Generated columns for computed values
16. API-driven SQL execution through RDS Data API
17. IAM-authenticated data access patterns on AWS
18. Lambda to Aurora integrations without connection pool management
19. GraphQL resolvers backed by PostgreSQL (or Supabase `pg_graphql` path)
20. Geospatial queries with PostGIS
21. Graph modeling via recursive SQL patterns
22. Property graph extensions such as Apache AGE
23. Vector similarity search with `pgvector`
24. Hybrid AI workloads: metadata + embeddings + transactions
25. Global, serverless PostgreSQL-compatible deployments with Aurora DSQL

## PostgreSQL vs Supabase (quick compare)

This part is important because these are not the same type of product:

1. PostgreSQL = database engine
2. Supabase = platform that uses PostgreSQL as the core database, plus API/auth/realtime/storage tooling

So "PostgreSQL vs Supabase" is usually not a hard either/or.
In practice:

1. Choose pure PostgreSQL when you want maximum low-level control and custom platform design.
2. Choose Supabase when you want faster product delivery with managed developer tooling around PostgreSQL.
3. Choose Aurora PostgreSQL/Aurora DSQL when your priority is AWS-native operations, IAM integration, and multi-Region managed architecture.

## Is this GenAI? Yes

"Is this GenAI, Yes. So here we will imagy what PostreSQL can do in the future"

These are our shared guesses, both yours and mine:

1. In-memory database architecture: most hot data and execution in memory, with durable S3-like backend layers for persistence and recovery.
2. Global worldwide database at massive scale: near-native multi-Region active-active behavior as a default, not a premium edge case.
3. Agent runtime inside PostgreSQL: AI agents hosted as database procedures/functions, close to the data, with transactional guarantees and policy controls.

Maybe not all of this will happen exactly in this form.
But the direction is clear: PostgreSQL keeps absorbing new workloads without losing the SQL foundation.

## Final take

In practice, most teams do not need five different databases for five data patterns.
PostgreSQL plus Aurora PostgreSQL-compatible options already cover most workloads:

1. SQL
2. NoSQL-like JSON
3. API access
4. Graph patterns
5. Vector search
6. Global distributed PostgreSQL-compatible infrastructure

So if you ask me where to start: start with PostgreSQL.
Then add complexity only when you really need it.