La oss anta at vi starter et nytt system i dag. Hvilken database bør vi velge først?

Mitt svar er enkelt: PostgreSQL. Start med SQL. Behold SQL. Legg til flere funksjoner når det trengs, uten å bytte database hvert kvartal.

Start fra SQL, deretter til Aurora DSQL Lenke til overskrift

PostgreSQL gir oss ACID-transaksjoner, joins, indekser og en moden spørringsplanlegger. For mange team er dette allerede nok i årevis.

Men hva om vi trenger global skala og multi-Region arkitektur? Aurora DSQL beholder PostgreSQL-kompatibilitet og legger til serverless distribuert infrastruktur. Samme SQL-tankesett, større skaleringsmuligheter.

Trenger du NoSQL? PostgreSQL kan også gjøre det Lenke til overskrift

PostgreSQL jsonb tillater dokumentbaserte arbeidsmengder i samme database. Du kan beholde semi-strukturerte data, legge til JSON-indekser, og fortsatt joine med relasjonelle tabeller.

Så ja, når noen sier “Nå trenger vi NoSQL”, er PostgreSQL i mange tilfeller allerede nok.

Trenger du API-tilgang? RDS Data API kan gjøre det Lenke til overskrift

Med Aurora + RDS Data API kan vi utføre SQL over HTTPS API-kall, med IAM og Secrets Manager-integrasjon. Dette fungerer bra for serverless og hendelsesdrevne systemer der langvarige DB-tilkoblinger ikke er ideelle.

Og hvis du vil ha en full backend-plattform rundt PostgreSQL, er Supabase en annen populær vei: PostgREST/GraphQL API-er, auth, sanntid, lagring og dashbord på toppen av Postgres.

Trenger du graf? Vi kan gjøre det Lenke til overskrift

Det er minst tre måter:

  1. Bruk rekursiv CTE (WITH RECURSIVE) for hierarki og graf-lignende traverseringer.
  2. Bruk utvidelsesbasert tilnærming (for eksempel Apache AGE) for property-graph stil spørringer.
  3. Bruk pgRouting (vanligvis med PostGIS) for korteste vei og graf-traverseringsproblemer. Supabase har en praktisk artikkel her: Postgres as a Graph Database: (Ab)using pgRouting

Trenger du vektorsøk? Vi kan gjøre det Lenke til overskrift

Med pgvector kan PostgreSQL lagre embeddings og kjøre likhetssøk. Dette er nok for anbefalinger, semantisk søk og RAG-lignende gjenfinning, mens transaksjonell metadata forblir på samme sted.

Trenger du cronjobs, pub/sub og bakgrunnsmønstre? Vi kan gjøre det Lenke til overskrift

Dette er et annet område der folk ofte legger til ekstra systemer for tidlig. PostgreSQL gir oss allerede mange nyttige byggeklosser:

  1. Cron-lignende jobber med pg_cron for periodiske SQL-oppgaver (opprydding, rollups, synkroniseringsjobber).
  2. Lettvekts pub/sub med LISTEN og NOTIFY for nesten sanntids app-hendelser.
  3. Durable queue workers med FOR UPDATE SKIP LOCKED.
  4. Outbox-mønster: skriv forretningsdata + hendelse i én transaksjon, og publiser deretter trygt fra outbox-tabellen.
  5. Retry og dead-letter-atferd med statuskolonner (pending, processing, failed) og retry-tellere.
  6. Idempotent jobbkjøring ved hjelp av unike nøkler, constraints og advisory locks.
  7. Supabase-sti: Postgres-endringer kan flyte inn i Realtime-abonnementer for klientoppdateringer.

Trenger vi fortsatt noen ganger Kafka, SQS eller EventBridge? Ja, selvfølgelig. Men for mange produktarbeidsmengder er det enklere og raskere å starte fra PostgreSQL-mønstre.

Trenger du backend for React-app? Ja, også mulig Lenke til overskrift

Typisk mønster:

  1. React frontend
  2. API-lag (Node/Express, Lambda eller GraphQL resolver)
  3. Aurora PostgreSQL eller Aurora DSQL
  4. Valgfri RDS Data API for HTTP-baserte SQL-kall

Referanse: React App video

Også populært: React + Supabase klient + Supabase Auth + Postgres database.

25 ting du kan gjøre med PostgreSQL (og Aurora PostgreSQL-kompatible alternativer) Lenke til overskrift

  1. Kjerne OLTP-transaksjoner med ACID-garantier
  2. Komplekse relasjonelle joins på tvers av normaliserte modeller
  3. Window-function analyser i SQL
  4. Rekursiv hierarkisk traversering med WITH RECURSIVE
  5. Bakgrunnsarbeiderkøer med FOR UPDATE SKIP LOCKED
  6. Materialiserte visninger for forhåndsberegnede lesninger
  7. Deklarativ partisjonering for store tabeller
  8. Radnivåsikkerhet for multi-tenant isolasjon
  9. Logisk replikering og CDC-pipelines
  10. Kryssdatabaseføderasjon med postgres_fdw
  11. Dokumentarbeidsmengder via json og jsonb
  12. JSON-feltindeksering med GIN
  13. Fulltekstsøk og rangering
  14. Hendelsessignalering med LISTEN og NOTIFY
  15. Genererte kolonner for beregnede verdier
  16. API-drevet SQL-utførelse via RDS Data API
  17. IAM-autentiserte datatilgangsmønstre på AWS
  18. Lambda til Aurora-integrasjoner uten tilkoblingspooladministrasjon
  19. GraphQL-resolvere støttet av PostgreSQL (eller Supabase pg_graphql sti)
  20. Geospatiale spørringer med PostGIS
  21. Grafmodellering via rekursive SQL-mønstre
  22. Property graph utvidelser som Apache AGE
  23. Vektorsøk med pgvector
  24. Hybride AI-arbeidsmengder: metadata + embeddings + transaksjoner
  25. Globale, serverless PostgreSQL-kompatible distribusjoner med Aurora DSQL

PostgreSQL vs Supabase (kort sammenligning) Lenke til overskrift

Denne delen er viktig fordi dette ikke er samme type produkt:

  1. PostgreSQL = database-motor
  2. Supabase = plattform som bruker PostgreSQL som kjernedatabase, pluss API/auth/sanntid/lagringsverktøy

Så “PostgreSQL vs Supabase” er vanligvis ikke et hardt enten/eller. I praksis:

  1. Velg ren PostgreSQL når du ønsker maksimal lavnivåkontroll og tilpasset plattformdesign.
  2. Velg Supabase når du ønsker raskere produktlevering med administrerte utviklerverktøy rundt PostgreSQL.
  3. Velg Aurora PostgreSQL/Aurora DSQL når din prioritet er AWS-native operasjoner, IAM-integrasjon og multi-Region administrert arkitektur.

Er dette GenAI? Ja Lenke til overskrift

“Er dette GenAI, Ja. Så her vil vi forestille oss hva PostgreSQL kan gjøre i fremtiden”

Dette er våre felles gjetninger, både dine og mine:

  1. In-memory databasearkitektur: de fleste varme data og utførelse i minnet, med holdbare S3-lignende backend-lag for persistens og gjenoppretting.
  2. Global verdensomspennende database i massiv skala: nesten native multi-Region aktiv-aktiv oppførsel som standard, ikke et premium unntakstilfelle.
  3. Agent runtime inne i PostgreSQL: AI-agenter hostet som databaseprosedyrer/funksjoner, nær dataene, med transaksjonsgarantier og policykontroller.

Kanskje ikke alt dette vil skje nøyaktig i denne formen. Men retningen er klar: PostgreSQL fortsetter å absorbere nye arbeidsmengder uten å miste SQL-grunnlaget.

Siste tanker Lenke til overskrift

I praksis trenger de fleste team ikke fem forskjellige databaser for fem datamønstre. PostgreSQL pluss Aurora PostgreSQL-kompatible alternativer dekker allerede de fleste arbeidsmengder:

  1. SQL
  2. NoSQL-lignende JSON
  3. API-tilgang
  4. Grafmønstre
  5. Vektorsøk
  6. Global distribuert PostgreSQL-kompatibel infrastruktur

Så hvis du spør meg hvor du skal starte: start med PostgreSQL. Legg deretter til kompleksitet bare når du virkelig trenger det.