Leer hoe je 'PostgreSQL search everywhere' ontwerpt voor interne schermen door full-text search, trigram- en partiële indexen te kiezen voor snelle resultaten.
Op een intern scherm betekent “zoeken overal” meestal: “Help me het exacte record te vinden dat ik in mijn hoofd heb, snel, ook als ik het niet precies herinner.” Mensen browsen niet. Ze willen direct naar één klant, ticket, factuur of apparaat springen.
Daarom voelt trage zoekfunctie slechter dan een trage pagina. Een paginalaadtijd gebeurt eens. Zoeken gebeurt vaak meerdere keren achter elkaar, vaak terwijl iemand aan de lijn is of triage doet. Als resultaten 2–3 seconden duren, veranderen gebruikers de zoekopdracht, backspacen, proberen een andere term, en krijg je meer load en meer frustratie.
Vanaf één zoekvak verwachten gebruikers een bundel van gedragingen: gedeeltelijke matches ("alex" vindt "Alexander"), tolerantie voor kleine typefouten ("microsfot" vindt nog steeds "Microsoft"), een logische "beste resultaat"-volgorde (exacte ID's of e-mails komen bovenaan), een beetje recency-bias en filters die standaard van toepassing zijn (open tickets, actieve klanten).
Het lastige is dat één invoer vaak meerdere intenties verbergt. Een medewerker kan een ticketnummer plakken, een naamfragment typen, op een e-mail zoeken of een telefoonnummer invoeren. Elke intentie vraagt om een andere strategie, andere indexen en soms een andere rangschikkingsregel.
Begin dus niet met indexen. Begin met het opschrijven van de paar zoekintenties die je gebruikers daadwerkelijk hebben, en scheid identiteitvelden (ID's, e-mails) van fuzzy velden (namen, onderwerpen) en lange tekst (notities).
Voordat je een index kiest: noteer wat mensen daadwerkelijk typen. “PostgreSQL search everywhere” klinkt als één feature, maar het is meestal een mix van heel verschillende zoekopdrachten.
Interne tools mengen “harde” identifiers (order ID, ticketnummer, factuurcode) met “zachte” tekst (klantnaam, e-mail, notities, tags). Die groepen gedragen zich anders in PostgreSQL, dus ze hetzelfde behandelen is een snelle weg naar trage queries.
Vervolgens: scheid de gedragingen:
TCK-104883 en verwacht één precies resultaat.john smth en wil een vergevingsgezinde match over namen (en misschien e-mails) en zal een korte lijst scannen.Bepaal vroeg of resultaten gerankt moeten worden (beste matches eerst) of simpelweg gefilterd. Ranking is belangrijk voor notities en langere omschrijvingen. Voor ID's en e-mails voelt ranking vaak willekeurig en voegt alleen kosten toe.
Een korte checklist is meestal genoeg:
Als je die beslissingen van tevoren benoemt, voelen indexkeuzes later niet als giswerk.
Zet eerst de eenvoudige wins vast. Voor veel interne schermen geeft een gewone B-tree-index al directe resultaten voor exacte matches zoals ID's, ordernummers, e-mails en externe referenties.
Als mensen een exacte waarde plakken, zorg dat je query echt exact is. WHERE id = ... of WHERE email = ... kan extreem snel zijn met een normale index. Een unieke index op e-mail betaalt zich vaak dubbel terug: snelheid en betere datakwaliteit.
Problemen beginnen wanneer “zoeken overal” ongemerkt verandert in ILIKE. Een query als name ILIKE '%ann%' heeft een voorloop-wildcard, dus PostgreSQL kan geen normale B-tree-index gebruiken. Het controleert veel rijen en wordt voorspelbaar langzamer naarmate de tabel groeit.
Prefix-zoek kan werken, maar alleen wanneer het patroon aan het begin verankerd is: name ILIKE 'ann%'. Zelfs dan doen details ertoe (collatie, case-afhandeling en of je hetzelfde expressie hebt geïndexeerd als waarin je zoekt). Als je UI case-insensitief moet zijn, is een gangbare aanpak om lower(name) te query'en en een bijpassende index op lower(name) te maken.
Het helpt ook om te bepalen wat “snappy” betekent:
Met zulke doelen is het makkelijker te beslissen of je bij exacte en prefix-matches kunt blijven, of dat het tijd is voor full-text search of trigram-indexen.
Full-text search is de beste keuze wanneer mensen natuurlijke taal typen en verwachten dat het systeem de juiste items vindt, niet alleen exacte matches. Denk aan ticketberichten, interne notities, lange omschrijvingen, knowledge base-artikelen en gesprekslogs.
De grote winst is ranking. In plaats van een lange lijst terug te geven waarin het beste resultaat verborgen ligt, kan full-text search sorteren op relevantie. In interne tools doet dat ertoe: iemand heeft binnen seconden een antwoord nodig, niet nadat hij 50 rijen heeft doorgezocht.
Op hoog niveau heeft full-text search drie onderdelen:
tsvector (de doorzoekbare tekst, opgeslagen of gegenereerd)tsquery (wat de gebruiker typte, omgezet naar een query)Taalconfiguratie is waar gedrag zichtbaar wordt. PostgreSQL verwijdert veelvoorkomende stopwoorden (zoals “de” of “en”) en past stemming toe, zodat “pay”, “paid” en “payment” kunnen matchen. Dat is geweldig voor notities en berichten, maar kan gebruikers verrassen wanneer ze op een kort algemeen woord zoeken en niets terugkrijgen.
Synoniemen zijn een ander beslispunt. Ze helpen wanneer je organisatie verschillende woorden voor hetzelfde gebruikt (bijvoorbeeld “refund” vs “chargeback”), maar ze vragen regelmatig onderhoud. Houd de synoniemenlijst kort en gebaseerd op wat support of ops daadwerkelijk typen.
Een praktisch voorbeeld: zoeken op “can’t login after reset” zou tickets moeten ophalen waarin staat “cannot log in after password reset”, ook als de woordkeuze anders is. Dat “vind relevante” gedrag is waar full-text search voor gemaakt is en het is meestal een betere keuze dan proberen ILIKE zich te laten gedragen als een zoekmachine.
Trigram-indexen zijn een sterke keuze wanneer gebruikers fragmenten typen, typefouten maken of zich alleen iets vaags herinneren. Ze schitteren op korte tekstvelden waar full-text search te strikt is: persoonsnamen, bedrijfsnamen, ticketonderwerpen, SKU's, ordernummers en productcodes.
Een trigram is een 3-karakter stukje tekst. PostgreSQL vergelijkt twee strings op basis van hoeveel trigrams ze delen. Daarom kan het "Jon Smth" matchen met "John Smith", of "ACM" met "ACME", en het kan resultaten vinden wanneer de query in het midden van een woord staat.
Dit is vaak het snelste pad naar een vergevingsgezind “PostgreSQL search everywhere”-vak wanneer de taak is “vind de juiste rij”, niet “vind documenten over een onderwerp”.
Full-text search is geweldig voor langere tekst en ranking op betekenis, maar het handelt niet vanzelfsprekend gedeeltelijke strings en kleine typefouten op korte velden af. Trigram-search is gebouwd voor dat soort fuzzy matching.
Trigram-indexen zijn groter en voegen overhead toe bij schrijven, dus wees selectief. Indexeer de kolommen die mensen daadwerkelijk gebruiken:
Als je de exacte velden kunt noemen waar je team in het zoekvak op typt, kun je trigram-indexering meestal klein en snel houden.
Een “zoeken overal” vak heeft meestal verborgen defaults. Mensen zoeken binnen een workspace, op actieve items en met verwijderde items uitgesloten. Als die filters in bijna elk verzoek aanwezig zijn, maak dan het veelvoorkomende pad snel door alleen die rijen te indexeren.
Een partial index is een normale index met een WHERE-clausule. PostgreSQL houdt het kleiner omdat het alleen entries opslaat voor rijen die je het meest interesseren. Dat betekent vaak minder pagina's om te lezen en betere cache-hitpercentages.
Veelvoorkomende doelen voor partial indexes zijn actieve rijen (status = 'active'), soft deletes (deleted_at IS NULL), tenant-scoping en “recente” vensters (bijvoorbeeld de laatste 90 dagen).
De sleutel is je UI matchen. Als het scherm altijd verwijderde rijen verbergt, moeten je queries altijd deleted_at IS NULL bevatten en je partial index dezelfde conditie gebruiken. Kleine mismatches, zoals is_deleted = false op de ene plek en deleted_at IS NULL op de andere, kunnen de planner ervan weerhouden de index te gebruiken.
Partial indexen werken ook naast full-text search en trigram-indexen. Bijvoorbeeld: tekstzoekindexen alleen voor niet-verwijderde rijen houden de indexgrootte beheersbaar.
Trade-off: partial indexen zijn minder nuttig voor zeldzame queries. Als iemand af en toe over verwijderde records zoekt of over alle workspaces, kan PostgreSQL terugvallen op een trager plan. Los dat op met een apart admin-only pad, of voeg een tweede index toe alleen als die zeldzame query gebruikelijk wordt.
De meeste teams eindigen met het mixen van technieken omdat één zoekvak verschillende intenties moet afhandelen. Het doel is de volgorde van bewerkingen duidelijk te maken zodat resultaten voorspelbaar aanvoelen.
Een eenvoudige prioriteitsvolgorde helpt, of je het nu implementeert als aparte queries of als één query met duidelijke CASE-logica.
Begin strikt, en word pas vager als het nodig is:
Als je je aan dezelfde ladder houdt, leren gebruikers wat het zoekvak “betekent.” Ze denken niet dat het systeem kapot is wanneer “12345” een ticket onmiddellijk vindt terwijl “refund policy” langer duurt.
Fuzzy search wordt duur wanneer het de hele tabel moet overwegen. Vernauw de kandidaten met de filters die mensen daadwerkelijk gebruiken (status, toegewezen team, datumbereik, account), en voer daarna trigram of full-text uit op wat overblijft. Zelfs een snelle trigram-index kan traag aanvoelen als je het miljoenen rijen laat scoren.
Het is ook de moeite waard om een korte regel in gewone taal op te stellen die niet-technische collega's begrijpen, zoals: “We matchen eerst ticketnummer exact, dan klantnaam met foutentolerantie, daarna notities.” Die gedeelde definitie voorkomt latere discussies over waarom een rij verscheen.
Een snel “search everywhere” vak is een reeks kleine beslissingen. Schrijf ze eerst op, dan wordt het databasewerk eenvoudiger.
EXPLAIN (ANALYZE, BUFFERS).Om veilig te deployen: verander één ding tegelijk en houd rollback eenvoudig. Voor nieuwe indexen op grote tabellen heeft CREATE INDEX CONCURRENTLY de voorkeur zodat je writes niet blokkeert. Als het kan, zet het achter een feature-flag en vergelijk latentie voor en na.
Een praktisch patroon voor “PostgreSQL search everywhere” is: eerst exacte match (snel en precies), trigram-matching voor menselijke velden waar mensen verkeerd spellen, en full-text search voor lange tekst die profiteert van ranking.
Stel je een support adminpaneel voor waar het team één zoekvak heeft, maar verwacht dat het klanten, tickets en zelfs notities vindt. Dit is het klassieke “één invoer, vele betekenissen” probleem.
De eerste winst is intent zichtbaar maken zonder frictie toe te voegen. Als de query eruitziet als een e-mail of telefoonnummer, behandel het als klantopzoeking. Als het eruitziet als een ticket-ID (bijvoorbeeld "TKT-10482"), routeer het direct naar tickets. Alles anders valt terug op tekstzoek over ticketonderwerp en notities.
Voor klantopzoeking voelen trigram-indexen meestal het beste. Namen en bedrijfsstrings zijn rommelig en mensen typen fragmenten. Een trigram-index kan zoekopdrachten zoals “jon smi” of “acm” snel en vergevingsgezind maken.
Voor ticketnotities: gebruik full-text search. Notities zijn echte zinnen en je wilt meestal relevante matches, niet “bevat deze substring”. Ranking helpt wanneer tientallen tickets hetzelfde trefwoord noemen.
Filters doen er vaak meer toe dan teams verwachten. Als agents in “open tickets” leven, voeg dan een partial index toe die alleen open rijen dekt. Doe hetzelfde voor “actieve klanten”. Het houdt indexen kleiner en maakt het gemeenschappelijke pad snel.
Zeer korte queries verdienen regels, anders doet de database dure bewerkingen voor ruis:
De meeste "waarom is zoeken traag?" bugs zijn zelf toegebracht. Het doel is niet om alles te indexeren, maar te indexeren wat mensen daadwerkelijk doen.
Een veelval is indexen toevoegen op veel kolommen “voor het geval dat.” Reads kunnen verbeteren, maar elke insert en update heeft nu extra werk. In interne tools waar records de hele dag veranderen (tickets, orders, gebruikers) doet writesnelheid ertoe.
Een andere fout is full-text search gebruiken terwijl je eigenlijk fouttolerante lookup op namen of e-mails nodig hebt. Full-text is geweldig voor documenten en omschrijvingen. Het is geen magische oplossing voor “Jon” vs “John” of “gmail.con” vs “gmail.com.” Dat is meestal trigram-terrein.
Filters kunnen ook ongemerkt je plan breken. Als de meeste zoekopdrachten met een vast filter komen (zoals status = 'open' of org_id = 42), is de beste index mogelijk een partial index die die conditie dekt. Als je dat vergeet, kan PostgreSQL veel meer rijen scannen dan je verwacht.
Een paar veelvoorkomende fouten:
Voorbeeld: een supportscherm zoekt tickets op onderwerp, klantnaam en ticketnummer en sorteert vervolgens op laatste activiteit. Als latest_activity_at niet geïndexeerd is voor het gefilterde bereik (bijvoorbeeld open tickets), kan die sort de snelheid die je van de zoekindex kreeg tenietdoen.
Voordat je een “search everywhere” feature afkent, wees concreet over het gedrag dat je belooft.
Als je modi mengt, bepaal welke wint bij conflicten.
Identificeer dan de 2–3 velden die de meeste zoekopdrachten aandrijven. Als 80% van de zoekopdrachten op e-mail, naam en ticket-ID is, optimaliseer die eerst en behandel de rest als secundair.
Een korte pre-ship checklist:
Test tenslotte met realistische datagrootte en timing, niet alleen correctheid. Een query die instant voelt met 1.000 rijen kan traag worden bij 1.000.000.
Een zoekvak blijft snel wanneer het team het eens is over wat het moet doen. Schrijf de regels in gewone taal: wat “match” betekent (exact, prefix, fouttolerant), welke velden doorzocht worden en hoe filters het resultaat beïnvloeden.
Houd een kleine testset van echte zoekopdrachten en behandel die als regressietest. Tien tot twintig queries zijn meestal genoeg: een paar veelvoorkomende namen, een paar gedeeltelijke e-mails, een typefout, een lange notitietekstregel en één “lege resultaten”-geval. Draai ze voor en na veranderingen zodat performancewerk niet ongemerkt relevantie kapotmaakt.
Als je interne tools bouwt met AppMaster (appmaster.io), helpt het om die zoekregels samen met het datamodel en de business logic te definiëren, zodat UI-gedrag en databasekeuzes niet uit elkaar groeien als de vereisten veranderen.
Wat betekent "search everywhere" meestal in een interne tool?Zie het als "vind het exacte record dat ik bedoel, snel", niet als bladeren. Begin met het opschrijven van de paar werkelijke intenties van gebruikers (ID-zoekopdracht, naam/e-mail-zoek met typefouten, lange-notitie zoek) en de standaardfilters die ze bijna altijd gebruiken. Die keuzes bepalen welke queries je moet uitvoeren en welke indexen de moeite waard zijn.
Waarom maakt `ILIKE '%...%'` zoeken traag?ILIKE '%term%' heeft een voorvoegsel-wildcard, dus PostgreSQL kan meestal geen normale B-tree-index gebruiken en moet veel rijen scannen. Het voelt misschien prima op kleine tabellen, maar wordt snel langzaam als de data groeit. Als je substring- of fouttolerante matching nodig hebt, plan dan voor trigram of full-text in plaats van te hopen dat ILIKE schaalt.
Wat is de snelste manier om exacte lookups zoals ID's of e-mails af te handelen?Gebruik exacte vergelijkingen zoals WHERE id = $1 of WHERE email = $1 en ondersteun ze met een B-tree (vaak uniek voor e-mails of codes). Exacte lookups zijn de goedkoopste zoekopdrachten en zorgen er ook voor dat resultaten voorspelbaar aanvoelen. Als gebruikers een volledig ticketnummer of e-mail plakken, routeer dan eerst naar dit pad.
Hoe doe ik case-insensitive prefix-zoeking zonder indexen kapot te maken?Geef de voorkeur aan een prefixpatroon zoals name ILIKE 'ann%' en houd dit consistent met hoe je indexeert. Voor betrouwbare case-insensitieve zoekacties kiezen veel teams ervoor lower(name) te gebruiken en een index op diezelfde expressie te maken zodat de planner deze kan gebruiken. Als je het patroon niet kunt verankeren aan het begin, is prefix search niet genoeg.
Wanneer moet ik trigram-indexen gebruiken voor een zoekvak?Gebruik trigram-indexering wanneer gebruikers fragmenten typen, kleine typefouten maken of zich alleen iets vaags herinneren, vooral op korte velden zoals namen, onderwerpen, codes en gebruikersnamen. Het werkt goed om het midden van een string te matchen en voor bijna-matches zoals spelfouten. Wees selectief met welke kolommen je indexeert, want trigram-indexen nemen ruimte in en verhogen de schrijfkosten.
Wanneer is PostgreSQL full-text search de betere keuze?Gebruik full-text search wanneer mensen zinnen of trefwoorden in langere inhoud doorzoeken, zoals notities, berichten, omschrijvingen of kennisbankartikelen. Het grote voordeel is relevantie-ranking, zodat beste matches bovenaan komen in plaats van dat gebruikers door een lange lijst moeten scrollen. Let op taalgedrag zoals stemming en het verwijderen van stopwoorden, wat handig is voor proza maar verrassend kan zijn bij zeer korte algemene woorden.
Hoe helpen partiële indexen "search everywhere" schermen?Voeg partial indexes toe wanneer de meeste zoekopdrachten dezelfde filters bevatten, zoals deleted_at IS NULL, status = 'open' of een tenant/workspace-constraint. Omdat de index alleen de veelvoorkomende subset dekt, blijft hij kleiner en is hij vaak sneller in echte workloads. Zorg ervoor dat je queries exact dezelfde filterconditie gebruiken als de partial index, anders kan PostgreSQL deze negeren.
Hoe kan ik exacte, trigram- en full-text search combineren zonder gebruikers te verwarren?Gebruik een consistente prioriteitsladder zodat resultaten stabiel aanvoelen: eerst exacte match voor ID's/e-mails, dan prefix waar het past, daarna trigram voor fouttolerante naam/titel-matches, en full-text voor lange notities en omschrijvingen. Pas de standaardfilters vroeg toe om te beperken hoeveel rijen fuzzy search moet overwegen. Zo blijven performance en relevantie niet-random naarmate data groeit.
Wat moet ik doen met 1–2 karakter zoekopdrachten of lege invoer?Stel eenvoudige regels in zoals minimaal 3 tekens voordat je fuzzy search uitvoert, en gebruik korte queries om recente of vaak geraadpleegde records te tonen. Zeer korte inputs geven veel ruis en kunnen dure bewerkingen triggeren met weinig waarde. Bepaal ook wat je doet bij lege invoer zodat de UI de database niet overspoelt met "match alles"-queries.
Hoe valideer ik performance en rol ik zoekwijzigingen veilig uit?Maak de index, verifieer vervolgens de echte query met EXPLAIN (ANALYZE, BUFFERS) op realistische datagroottes, niet alleen een dev-dataset. Rol wijzigingen één voor één uit en houd rollback makkelijk; op grote tabellen maak nieuwe indexen bij voorkeur met CREATE INDEX CONCURRENTLY om writes niet te blokkeren. Als je het scherm bouwt met AppMaster (appmaster.io), definieer dan de zoekregels samen met het datamodel en de business logic zodat UI-gedrag consistent blijft als vereisten veranderen.
21 jan 2026
8 min
20 jan 20268 min
20 jan 20267 minExperimenteer met AppMaster met gratis abonnement.
Als je er klaar voor bent, kun je het juiste abonnement kiezen.
