Hey I submitted through the contact form but not sure if it went through: I have an existing nullable VARCHAR(64) column named business_fingerprint on an existing production table. I need to add a database-level UNIQUE constraint to that existing column while continuing to allow multiple existing NULL values. CREATE UNIQUE INDEX through MCP execute_sql returns Blocked statement: Command not...
Founder Team
Riya_NoCodeBackend
Sep 28, 2026
A: Hi,
You have three supported ways to add this UNIQUE constraint without recreating the table or losing any data:
Method 1: Using the "Run SQL" Button in the Dashboard (Direct)
1. Navigate to your database and open the "Edit Database" page.
2. In the top-right header, click the "Run SQL" button.
3. Run the following standard ALTER TABLE statement:
I’ve been really impressed with how quickly I can get a backend up and running with NoCodeBackend. The MCP integration looks especially interesting.
Are you planning to expand the MCP capabilities further? It would be really cool to let AI agents not only query the database, but also help manage things like authentication, RLS policies, API configuration, etc.
Founder Team
Riya_NoCodeBackend
Sep 28, 2026
A: Thank you so much! We’re really glad you’re enjoying NoCodeBackend and finding the MCP integration useful.
Actually, many of the capabilities you mentioned are already covered as part of our MCP integration. AI agents can work with the database and also interact with backend capabilities such as authentication, RLS policies, and API configuration.
You stated that each workspace supports 15 parallel in-flight requests plus a 30-request FIFO buffer. Is this concurrency limit shared across my entire AppSumo workspace and all databases, or does each database get its own 15 + 30 concurrency pool? For example, on Tier 5 with 100 active databases used by 100 separate client apps, would all 100 apps together share only 15 active concurrent requests?
Founder Team
Riya_NoCodeBackend
Sep 26, 2026
A: Hi Solu,
Great question!
The short answer is: No, your 100 apps will not share 15 requests.
Each database in NoCodeBackend has its own unique secret key. Our traffic limit (15 concurrent requests + 30 waiting queue) is tied to that specific key.
This means each of your 100 databases gets its own separate 15 concurrent slots.
If App #1 gets hit with heavy traffic and maxes out its 15 slots,...
Another question: I have the original grandfathered Tier 2 AppSumo plan with unlimited records per database. If I upgrade now to Tier 5, will all 250 databases available to my Tier 5 account, including databases I create in the future, retain unlimited records per database? Tier 5 + all 250 database slots + future databases + unlimited records?
Q: Until Sept 25, a user's email alone let others see their databases and secret keys. Will you warn and investigate?
Until Sept 25, a serious bug let any registered user — free or paid — open any other user's account with just that user's email address. They could see every database that person built and its secret key: full control to read, change, or delete everything inside.
I reported it privately with steps to reproduce; it is now fixed.
But a quiet fix is not enough. My questions:
1. Will you tell all...
Founder Team
Riya_NoCodeBackend
Sep 28, 2026
A: Hi Miyan,
Thank you for your post. We take security and platform integrity very seriously. Because your post characterizes this as a catastrophic platform-wide exploit where anyone could "open any account and delete everything," we want to address your questions transparently and set the record straight for all users and prospective customers.
The Technical Reality: What It Was (and What It...
We did offer the user a $250 coupon code in recognition of their work. The concern from their end appears to be that they were expecting a refund of $1,500+ directly to their account. We declined that request because they had already been using the tool for more than nine months.
Thank you for answering, Riya. Your reply confirms the flaw was real and has been fixed, and that keys can be regenerated with one click.
Two questions remain, and both are about protecting users: 1. Since there was no forced revocation, keys issued before Sept 25 keep working until each owner regenerates them. Will you email every user (free, paid, AppSumo and direct) and ask them to do so?
2. Your audit found "zero unauthorized access." Since when did the endpoint behave this way, and does the audit cover that whole period?
For the record: my refund request was sent 91 minutes after my report, not 9 (9 minutes was your acknowledgment). The full timeline and evidence: https://ncb-disclosure-2026.pages.dev/
To address your latest questions: as already stated, we reviewed the relevant Cloudflare, application, and database logs for the period the affected functionality was in production. We found no evidence that customer data, database records/rows, or database secret keys were accessed or exposed.
That is why we did not force global key revocation or send a blanket rotation notice,
which would unnecessarily disrupt customers' applications. Had our logs shown any actual exposure, we would have immediately taken protective action, including forced key rotation where appropriate. The vulnerability and actual data compromise are therefore two different matters. Our investigation found no evidence of an actual breach.
We also note that your own report states that you did not access, read, or change anyone else's data or keys. Therefore, recommendations to users based on assumed exposure should not be presented as evidence that a breach actually occurred. If there is specific evidence of actual unauthorized access or exposure, we are happy to review it.
Thanks, Riya. We agree that a vulnerability and a breach are different things. My report says so directly ("It does not claim that anyone's data was actually stolen").
But you've now confirmed that no notice was sent to users, and the reason you give doesn't apply to a notice. A forced revocation could break apps. An email breaks nothing.
It simply lets each user decide, with the facts, whether to regenerate a key, which you say takes one click.
That decision belongs to users, not to the vendor. It's their data, and often their own customers' data, that sat behind those keys, and some of them may have their own obligations to check. Most users will never read this thread or the reviews.
An email from you is the only way most of them will ever find out. Telling them is part of a developer's responsibility, and "our logs show no evidence" can't replace it, especially without the dates the logs cover.
So, three questions: 1. Will you email all users (free, paid, AppSumo and direct) that keys issued before Sept 25 could be retrieved by other accounts, and that they can regenerate them? 2. If not, what is the reason, given that an email doesn't disrupt anyone's application? 3. What are the start and end dates of the period your logs covered?
The affected endpoint was in production from September 19, 2026 at 12:40:49 UTC through September 25, 2026 at 10:24:07 UTC, when the security fix was deployed. We reviewed the system records and application logs available to us and found no confirmed evidence that customer data, database records/rows, or database secret keys were accessed by an unauthorized party
Accordingly, there was no basis to force a global key rotation, which could unnecessarily disrupt customers' applications and integrations. Had our investigation identified actual exposure, we would have taken immediate protective action, including forced rotation where appropriate.
As an additional precaution, we have also provided customers with information regarding the resolved issue.
Customers have also been given the option to regenerate their keys.
The distinction is important: a security vulnerability existed and was fixed; our investigation found no evidence of an actual customer-data or credential compromise. We have addressed the issue and consider the matter closed.
We expect future public statements about NoCodeBackend to be accurate, factual, and evidence-based.
Q: Question
Hey I submitted through the contact form but not sure if it went through: I have an existing nullable VARCHAR(64) column named business_fingerprint on an existing production table. I need to add a database-level UNIQUE constraint to that existing column while continuing to allow multiple existing NULL values.
CREATE UNIQUE INDEX through MCP execute_sql returns Blocked statement: Command not...
Riya_NoCodeBackend
Sep 28, 2026A: Hi,
You have three supported ways to add this UNIQUE constraint without recreating the table or losing any data:
Method 1: Using the "Run SQL" Button in the Dashboard (Direct)
1. Navigate to your database and open the "Edit Database" page.
2. In the top-right header, click the "Run SQL" button.
3. Run the following standard ALTER TABLE statement:
```sql
ALTER TABLE your_table_name
ADD...
Share NoCodeBackend
Verified purchaser
Perfect and a piece of cake, thank you!
Q: Question on MCP capabilities
I’ve been really impressed with how quickly I can get a backend up and running with NoCodeBackend. The MCP integration looks especially interesting.
Are you planning to expand the MCP capabilities further? It would be really cool to let AI agents not only query the database, but also help manage things like authentication, RLS policies, API configuration, etc.
Riya_NoCodeBackend
Sep 28, 2026A: Thank you so much! We’re really glad you’re enjoying NoCodeBackend and finding the MCP integration useful.
Actually, many of the capabilities you mentioned are already covered as part of our MCP integration. AI agents can work with the database and also interact with backend capabilities such as authentication, RLS policies, and API configuration.
We’re continuing to expand and refine the MCP...
Share NoCodeBackend
Q: 15 parallel in-flight requests + 30-request FIFO buffer.
You stated that each workspace supports 15 parallel in-flight requests plus a 30-request FIFO buffer. Is this concurrency limit shared across my entire AppSumo workspace and all databases, or does each database get its own 15 + 30 concurrency pool? For example, on Tier 5 with 100 active databases used by 100 separate client apps, would all 100 apps together share only 15 active concurrent requests?
Riya_NoCodeBackend
Sep 26, 2026A: Hi Solu,
Great question!
The short answer is: No, your 100 apps will not share 15 requests.
Each database in NoCodeBackend has its own unique secret key. Our traffic limit (15 concurrent requests + 30 waiting queue) is tied to that specific key.
This means each of your 100 databases gets its own separate 15 concurrent slots.
If App #1 gets hit with heavy traffic and maxes out its 15 slots,...
Share NoCodeBackend
Verified purchaser
Another question:
I have the original grandfathered Tier 2 AppSumo plan with unlimited records per database. If I upgrade now to Tier 5, will all 250 databases available to my Tier 5 account, including databases I create in the future, retain unlimited records per database?
Tier 5 + all 250 database slots + future databases + unlimited records?
Yes you will retain your original limits as per your original plan.
Q: Addons Custom Domains
Hey, after the deal ends, is it still possible to add custom domains because I could not see it in nocodebackend Plans & limits
Riya_NoCodeBackend
Sep 25, 2026A: Hi,
Custom domains cannot be purchased after this AppSumo campaign ends. They are currently only available through AppSumo during this deal.
thanks,
Riya
Share NoCodeBackend
Q: Until Sept 25, a user's email alone let others see their databases and secret keys. Will you warn and investigate?
Until Sept 25, a serious bug let any registered user — free or paid — open any other user's account with just that user's email address. They could see every database that person built and its secret key: full control to read, change, or delete everything inside.
I reported it privately with steps to reproduce; it is now fixed.
But a quiet fix is not enough. My questions:
1. Will you tell all...
Riya_NoCodeBackend
Sep 28, 2026A: Hi Miyan,
Thank you for your post. We take security and platform integrity very seriously. Because your post characterizes this as a catastrophic platform-wide exploit where anyone could "open any account and delete everything," we want to address your questions transparently and set the record straight for all users and prospective customers.
The Technical Reality: What It Was (and What It...
Share NoCodeBackend
Verified purchaser
Thank you for those questions.
Thanks for reporting it. What you did is important and shows how honest a company is. You should actually have been rewarded for it, not ignored.
We did offer the user a $250 coupon code in recognition of their work. The concern from their end appears to be that they were expecting a refund of $1,500+ directly to their account. We declined that request because they had already been using the tool for more than nine months.
@Riya This is exactly the kind of transparency I was hoping for. Thank you very much for your professional response. It makes sense and builds trust.
Verified purchaser
Thank you for answering, Riya. Your reply confirms the flaw was real and has been fixed, and that keys can be regenerated with one click.
Two questions remain, and both are about protecting users:
1. Since there was no forced revocation, keys issued before Sept 25 keep working until each owner regenerates them. Will you email every user (free, paid, AppSumo and direct) and ask them to do so?
Verified purchaser
2. Your audit found "zero unauthorized access." Since when did the endpoint behave this way, and does the audit cover that whole period?
For the record: my refund request was sent 91 minutes after my report, not 9 (9 minutes was your acknowledgment).
The full timeline and evidence: https://ncb-disclosure-2026.pages.dev/
To address your latest questions: as already stated, we reviewed the relevant Cloudflare, application, and database logs for the period the affected functionality was in production. We found no evidence that customer data, database records/rows, or database secret keys were accessed or exposed.
That is why we did not force global key revocation or send a blanket rotation notice,
which would unnecessarily disrupt customers' applications. Had our logs shown any actual exposure, we would have immediately taken protective action, including forced key rotation where appropriate.
The vulnerability and actual data compromise are therefore two different matters. Our investigation found no evidence of an actual breach.
We also note that your own report states that you did not access, read, or change anyone else's data or keys. Therefore, recommendations to users based on assumed exposure should not be presented as evidence that a breach actually occurred.
If there is specific evidence of actual unauthorized access or exposure, we are happy to review it.
Verified purchaser
Thanks, Riya. We agree that a vulnerability and a breach are different things. My report says so directly ("It does not claim that anyone's data was actually stolen").
But you've now confirmed that no notice was sent to users, and the reason you give doesn't apply to a notice. A forced revocation could break apps. An email breaks nothing.
Verified purchaser
It simply lets each user decide, with the facts, whether to regenerate a key, which you say takes one click.
That decision belongs to users, not to the vendor. It's their data, and often their own customers' data, that sat behind those keys, and some of them may have their own obligations to check. Most users will never read this thread or the reviews.
Verified purchaser
An email from you is the only way most of them will ever find out. Telling them is part of a developer's responsibility, and "our logs show no evidence" can't replace it, especially without the dates the logs cover.
Verified purchaser
So, three questions:
1. Will you email all users (free, paid, AppSumo and direct) that keys issued before Sept 25 could be retrieved by other accounts, and that they can regenerate them?
2. If not, what is the reason, given that an email doesn't disrupt anyone's application?
3. What are the start and end dates of the period your logs covered?
To clarify and close this matter:
The affected endpoint was in production from September 19, 2026 at 12:40:49 UTC through September 25, 2026 at 10:24:07 UTC, when the security fix was deployed.
We reviewed the system records and application logs available to us and found no confirmed evidence that customer data, database records/rows, or database secret keys were accessed by an unauthorized party
Accordingly, there was no basis to force a global key rotation, which could unnecessarily disrupt customers' applications and integrations. Had our investigation identified actual exposure, we would have taken immediate protective action, including forced rotation where appropriate.
As an additional precaution, we have also provided customers with information regarding the resolved issue.
Customers have also been given the option to regenerate their keys.
The distinction is important: a security vulnerability existed and was fixed; our investigation found no evidence of an actual customer-data or credential compromise. We have addressed the issue and consider the matter closed.
We expect future public statements about NoCodeBackend to be accurate, factual, and evidence-based.
We reserve all rights and remedies regarding materially false or misleading factual statements or other unlawful conduct.
Any specific evidence of actual unauthorized access or exposure can be provided for review.