Exactly. Rails hosting shouldn’t fall into the same cheap php hosting
environment. Tons of storage isn’t going to solve your Rails deployment
problems. If you need more disk space, we can always customize a
package… but actually recommend that you find yourself a cheap host
(amazon s3 for example) for tons of disk space. If you need it for your
database… you shouldn’t be looking at shared hosting anyways.
Yup I agree!
Although I myself is one person that values space/bandwidth for $$
quite a lot as my DB is almost cramped up with just 2 GB and have 20
GB/month traffic… I always think that #1 on the list is customer
support. People would pay a lot for that. There’s no such thing that
compares to the satisfaction of having a problem, then a simple phone
call/IM chat/whatever and the people on the other end quickly solves
the problem and within assistance always, focused on our problem at
hand. But e-mail support that takes > 48 hours to reply? These guys
need to get a better job. (and maybe you’ve ever had “We’ve forwarded
your inquiry to our tech support department, please wai…”)
I haven’t used the other services, but I know that we have many
customers that have. Almost all of our employees are developing Rails
applications on a daily basis… so we think like developers. Most of
our customers… are developers. They want more control over their
deployment solution, so we give it to them… because it’s what we want.
Thank you, I’ve edited my list to include a bit details about your
service. I’m not that good writer though…
We’re also huge PostgreSQL fans (I’ve been working with PostgreSQL for
several years before Rails was even around…) and we let you run your
own private instance of it. I don’t think most of the other rails
environments give you that flexibility (currently).
That gives me a wondering… is there something like Amazon S3 for
DBMS? I know some of people have been talking about this possibility.
In my mind, maybe it’s like:
- managed database (of course). PostgreSQL & MySQL are musts I guess.
- easily clone database, either for development, staging, test.
- track database update changes. easily regenerate a schema of any
version of DB in the past.
- daily/hourly/whatever backups.
- easily cluster databases.
- easily set up master-slave replication.
- scale the database, maybe automatically, when the need arrives. so
developers can focus on their app, not pulling their hair out when
they’ve got tons of DB requests per second and they’re not sure how to
best setup Slony-I.
- automated consistency tests. (test-driven database design?)