Hvert eneste nyt projekt starter med det samme spørgsmål fra kunder og kolleger: "Bruger I ikke Redis til cachen? Elasticsearch til søgning? En vector-database til AI-funktionerne?"
Svaret er næsten altid nej. Vi bruger Postgres. Og det virker.
Full-text søgning — uden Elasticsearch
Postgres har haft tsvector og tsquery siden version 8.3. Det understøtter dansk stemming, GIN-indeks for hurtig søgning, og ranking via ts_rank. For 95% af de use-cases vi møder — produktsøgning, sagssøgning, indholdssøgning — er det mere end nok.
Vi har erstattet Elasticsearch-setups med Postgres full-text search i tre projekter. Søgetiderne er sammenlignelige under normale loads, og vi undgår en hel infrastruktur-komponent der skal driftes, skaleres og opdateres.
Job queues — uden Redis
Postgres LISTEN/NOTIFY og en simpel jobs-tabel giver en pålidelig task-queue til de fleste opgaver. Alternativt kan man bruge pg_cron til planlagte jobs. Vi bruger denne tilgang til e-mail-afsendelse, rapportgenerering og asynkrone API-kald i de fleste projekter.
Er det så hurtigt som Redis? Nej. Er det hurtigt nok? Til 99% af produktionskrav — ja.
Embeddings — uden en vector-database
pgvector giver Postgres mulighed for at gemme og søge i embeddings direkte. For projekter der ikke har millioner af vektorer er dette fuldt tilstrækkeligt. Vi har brugt det til semantisk søgning i dokumentarkiver og som fundament for simpel RAG-implementation.
"Den primære grund til at teams tilføjer ekstra databaser er resume-driven development — ikke teknisk nødvendighed."
Hvornår er Postgres ikke nok?
Der er tilfælde. Milliardvis af dokumenter i Elasticsearch. Sub-millisekund cache-lookups i Redis ved meget høj throughput. Realtids-analytics i stor skala med DuckDB eller ClickHouse. Men de fleste projekter vi bygger — og de fleste projekter I sandsynligvis har — når aldrig til det punkt.
Instagram kørte på Postgres i årevis. Notion kører stadig primært på Postgres. Det er ikke mangel på ambition — det er pragmatisme.