xTuple.com xTupleU Blog & News Customer Support

xTuple on AWS RDS / shared database hosting

I tried running xTuple on AWS RDS postgres and ran into a couple of problems, both related to the need for a superuser on the database.  AWS RDS does not allow one to create a super-user because they are taking responsibility for backups and server maintenance, and it also reserves the username "admin".  It is possible to create a new user, but not with super user capabilities, or named admin.  I think this is pretty common in shared hosting scenarios.

Because the userpriv tables are hardcoded to only give permissions to 'admin" we can't start with a clean database.  

I'd like to use RDS due to the automated backups/failover and the fact that I can access it from anywhere.  If I restore a database from my local machine to the RDS service that has the username and permissions defined that I want, am I going to run into issues with not having full super-user privileges?

Most of the previous database applications I've used use one set of credentials for connecting to the database, and a different set that handles application level authentication and authorization.  Are there any plans to decouple the database user from the applicaton user?

Thanks for trying xTuple on AWS RDS. We have only heard of a few attempts to run it on there, but none have been successful. The RDS environment is too limited to support xTuple's use case. We would suggest you try AWS's new Aurora PostgreSQL service. From what we have heard, it has less restrictions than RDS and might work with xTuple. We have not tried it yet, so we cannot endorse it.

We have considering decoupling the database user from the application user, but it is a major refactoring task. There are some other tasks that have to happen before we can even consider that such as building a different authentication and authorization service. That is on the roadmap for 2017 as we hope to extend the existing OAuth 2.0 server to support being an OpenID Connect Provider. The other task involves starting to use an API service in parts of the Qt client vs. a direct PostgreSQL connection. Both of those tasks are in the early planning stages and neither have been proven yet. We currently have no plans to remove the direct connection to the PostgreSQL server.

If you are concerned about automated backup, uptime and access from anywhere, we recommend you consider xTuple's Cloud Hosting option

Thanks for the detailed update.  I was hoping to use RDS because, for my size business, I can get away with a free tier sized server and still get the automated backups and connect from anywhere capability.  Unfortunately, Aurora starts out pretty expensive (relative to my current business size) so that's a non-starter for me.  I'm also in pretty early stages of figuring out how to use xTuple, so I'm not fully committed to it yet to sign up for a service.

For now, I think I'll continue to run it on my local machine and if and when I need more than that I'll reinvestigate the other options.

So glad this was already asked. I was starting to use RDS and had the feeling I was going to run into something like this. FWIW I would be very interested in a version of xTuple that would work with RDS if that’s at all possible in the future. Base ~$13/mo vs $233.60 for Aurora also unfortunately has me looking like I’m rolling my own postgresql server.

Amazon RDS unfortunately does not work at present as the admin user requires SUPERUSER permissions which RDS does not allow. There are a number of extensions and services required to run a modern xTuple system that currently wont work on a basic PostgreSQL database server/service.

plv8 extension support was just added to Amazon RDS: