From 5d742d6db9a46d6f5563c5aaac414944f3b61685 Mon Sep 17 00:00:00 2001 From: Matt Dragon Date: Thu, 3 Oct 2024 15:14:47 -0400 Subject: [PATCH] Fixes from PR --- documentation/wiki/decisions/adr/2024-10-02-search-engine.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/documentation/wiki/decisions/adr/2024-10-02-search-engine.md b/documentation/wiki/decisions/adr/2024-10-02-search-engine.md index 90620c45b..7ba1cacb2 100644 --- a/documentation/wiki/decisions/adr/2024-10-02-search-engine.md +++ b/documentation/wiki/decisions/adr/2024-10-02-search-engine.md @@ -19,7 +19,7 @@ Simpler needs to surface Grant Opportunities to Grant Seekers to ensure that the ## Options Considered -- Roll our own search engine in [PostgreSQL]() +- Roll our own search engine in [PostgreSQL](https://postgresql.org) - [Elastic Search](https://www.elastic.co/) - [OpenSearch](https://opensearch.org/) @@ -50,12 +50,11 @@ Utilize some PostgreSQL supported SQL syntax to do searches as SQL SELECT querie - **Pros** - No additional infra/cost - Infra already exists - - Very quick, but very bad, MVP implementation - Works with existing data we're already tracking, no data sync needed - **Cons** - Not a core/frequently utilized portion of the product functionality - Still wasn't really "utilizing" the existing data/skillset as special indexes/syntax are needed - - Potential for issues scaling since it would require scaling the entire DB + - Creates issues scaling since it would require scaling the entire DB instance to account for search traffic - Harder to support new search features, onboard new developers, etc. - Slow queries