Hi all, wondering what your thoughts are.
We've been using Xano for about 2 years now and have been overall pleased with the platform but have encountered some serious issues regarding instance performance and unreliability - this seems to specifically be an issue with RAM (which has been made clear to me multiple times but after months, there is still no way to see RAM usage and no warnings provided anywhere). For insight, we store 2,000,000+ records and probably 40 to 50 endpoints with regular CPU usage under 25% and storage at ~60%. What scares me is that time and time again we are running into the following:
Loops stopping out of nowhere at arbitrary points
Support told me it was a RAM issue
Added 2-3 second pauses between iterations and voila, it suddenly stopped crashing.
Tasks shutting down and timing out (seeing things like: "Current Active Statement (Last update: 23h 39m 19s ago)
Support told me it was a RAM issue
Support told me to debug it (e.g. "add record to a debug table for each iteration" or "send to debug") but some statements don't even execute after each iteration. So we will be left with a failed task, no error messages, and missing debug statements that were supposed to be added but are missing.
Getting critical failure errors across the entire instance
Support told me it was a RAM/Storage Issue
Entire platform breaks (cannot even login Xano to diagnose the problem - if you're already on Xano, tables show critical failure alerts and show 0 records)
All APIs become unsuable (return critical server errors with no other information as to whats going on)
Having to disable task history on nearly every single API /function/task
Was told by support to do this to save storage/RAM
Creating internal API endpoints that are called by functions, instead of running the function directly in the task itself
Was told by support to do this as apparently APIs have better performance than tasks (not indicated anywhere in the documentation or resources)
Rather than task -> function, it becomes task -> utility function that calls api -> API endpoint runs actual function
Lack of documentation on things like the the DB Connector
After going through support, was made clear that DB connector operations could potentially break my Xano instance completely and that I should stick with simple CRUD operations.
Nowhere is any of this made clear in the resources for the DB connector.
Heavy queries returning no data/timing out (edit: added)
Sometimes we have to backup records to the cloud (aws, google, etc.), which involves querying entire tables. We handle this using dedicated APIs that do these queries and upload the data (always on the weekends when overall load is low).
Consistently now, queries just fail. They return nothing and the API request history shows nothing. We know the data was not uploaded but there is no record or log of anything as Xano just decides to stop and kill the processing. We have no way of backup up critical data except for Xano's own backup feature.
Naturally, the best solution to address the RAM issue is to upgrade to a better instance, but even when we had higher tier plans, the same issues occurred. Granted, Xano has its limits and we are certainly pushing them, but I feel as though some of these issues are so prevalent that they require at least some sort of review. For so many issues, we are left wondering if its our problem (e.g. a buggy function) or Xano's. And for what seems like one too many times, it has been the latter. The debug update was great as it gave us insight into what was going on, but it was not enough - scalability and reliability go hand-in-hand, and for us, the reliability has just not kept up. RAM analytics are nonexistent, large queries are getting dropped and failing with no ability to debug, the debugger is still unreliable for heavy tasks, critical failures are not alerted and the platform UI becomes inaccessible when your instance load is too high, etc. The answer can't always just be "upgrade to a better instance".
I love Xano and what the team is doing. And we are definitely testing its limits, but I hope some of these issues are addressed.