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 Link to heading

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 Link to heading

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 Link to heading

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 Link to heading

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

Need vector search? We can do it Link to heading

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 Link to heading

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 Link to heading

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

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

25 things you can do with PostgreSQL (and Aurora PostgreSQL-compatible options) Link to heading

  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) Link to heading

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 Link to heading

“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 Link to heading

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.