SmartList Builder can access any tables/views from a non-GP database as long as it is on the same SQL server instance as GP. Often times the issue that users run into with this, lies within the security setup on the SQL side. With a GP database the users will all be part of the DYNGRP role and the SQL objects will have that role assigned. When using a non-GP database none of your GP roles or GP users will have access to the database until you grant access.
The issue I run across most often is when an admin user (sa usually) creates a list in SmartList Builder using a table or view from the database and is able to return result in SmartList just fine, but all the other users that run the SmartList receive no errors or data. This can be a bit puzzling as you are sure you gave them access to the list in GP, but all the list will return is the column names. If you were to run a SQL trace or dexsql.log you would see an error that they do not have access to the specific SQL object you have used in your SmartList Builder setup. The admin user can see the results though because they have access to everything by default. Once you have the list setup using objects from your non-GP database you need to give your users access. This can be done in several different ways, I chose to add my GP user to a new role and assign the role to my SQL objects as needed:
1. Add your GP users that need access to the SmartList to your non GP database.
2. If you plan to use a role as I did, create a new role and add the GP users to the role.
3. Once you have a role setup with your selected GP users you can assign the role and grant Select permissions to the SQL objects used in your SmartList Builder setup. If you used a view and it queries several other views or tables you need to assign the role to each of those objects as well.