Forget this comment. It's completely wrong. This one was right:
I thought the workflow looked interesting, so I had a closer look at the source code.
It doesn't actually use SQLite for searching, just as a "dumb" datastore. It still loads every repo into memory on each run and filters it with go-alfred's MatchesTerms function.
This kills the main performance advantage of using SQLite (databases get much of their speed from not loading unwanted stuff into memory), so the only speed tradeoff would be AwGo's fuzzy search vs go-alfred's simpler "contains" search (which is still significant, but shouldn't be super-noticeable for ~4000 items).
I'm 99% certain that using an SQL query similar to what I posted above would be the fastest of all, but you'd have to change the database schema to include the full name of each repo, as that is what you want to search against, and it currently isn't stored in the database.