I’m facing a problem with the Custom SQL feature in QuickSight. We’re hitting the 65356 character limit for SQL queries, which is causing issues in our development. This limit is too restrictive for the complexity of our queries.
Do you have any tips for managing larger queries within this character limit?
Hi @duho - Welcome to AWS QuickSight community and thanks for posting the question. One of the solution is to create data base view and put your sql as part of the view definition. In QS, just bring the view data like select * from <view_name>.
I ran into this same problem, especially when trying to us the API to migrate data sets. We had to move all these large queries into views. It was not fun to do this. The only other alternative is to manually enter the large Query into the Quicksight UI. That character limit does not happen there. It just manifests itself when using the API.
Thank you for your response! I considered using views, but we support a multi-tenant environment, so creating and managing views for each domain can be quite challenging.
For this reason, I’m currently trying to split the query and create separate datasets, then join them for use. I’m really curious if others are using this approach as well.
Thank you @duho, Yes there will be additional operational management at DB side for views. When you are telling multi-tenant environment, can you please provide more details on your architecture. This sounds interesting problem, if you can give a high level architecture how your QS is designed and integrated with data sources and end users access the tool, that will be a great. It will be a new learning for me.
We can connect offline for the same ( if possible).
Hello, @Sanjeeb2022 !
Sorry for the delayed response.
I’d be happy to share more details about our multi-tenant environment. Currently, we have set up separate QuickSight namespaces for each domain. This arrangement allows users of each domain to work within their respective namespaces. Our data sources are isolated by these namespaces, ensuring that end-users can access only the information related to their own domain.
Now i am considering splitting long query into multiple smaller views. This approach aims to simplify management and improve performance.
Are you still running into this issue or were one of the comments above helpful? Were you able to try @ErikG 's suggestion above as well?
It has been some time since we have heard from you but would still like to help you find a solution. If we do not hear from you in 3 business days this topic will be archived.