+++
date = "2026-02-23"
title = "PostgreSQL: Den eneste databasen du trenger"
slug = "postgresql-the-only-database-you-need"
tags = [
    "postgresql",
    "aws",
    "aurora",
    "aurora-dsql",
    "rds-data-api",
    "nosql",
    "graph",
    "vector",
    "react",
    "supabase",
]
categories = [
    "aws",
]
series = ["AWS"]
+++

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

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

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

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

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](https://supabase.com/blog/pgrouting-postgres-graph-database)

## Trenger du vektorsøk? Vi kan gjøre det

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

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

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](https://www.youtube.com/watch?app=desktop&v=3JW732GrMdg)

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

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

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)

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

"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

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.