What is so problematic having 1 database for mutliple applications?
Are you hosting Outsystems yourself for 5 customers? Or are you developing inhouse and will install the Platform server and application at the customer.

If it's so dramatic for you, you can always create your databases yourself and with integration studio import the entities yourself. works like a charm itself.
Which is an advantage if you have to deal with DBA's, they are satisfied and you can still use your favourite platform :D

On that note, with 5.1 you can use multiple schemas, so that should lessen your worries ;)

For me, I don't mind how they store it. It's not important for me, as long as they store it.
The customers may think differently, but there are other ways of achieving that, like I already stated

I see what you're saying, but there are a few things to consider:

1. How many apps have performance or security issues so critical that the DBs need to be separate, but don't mind if the Web apps reside on the same machine?
2. How many apps have performance issues at the DB level so bad in proportion to the app server end, that the app server has tons of resources for other apps, but the DBs need to be separate?
3. How many customers are set up in a fashion that they are looking for this kind of separation, but aren't using a clustered DB product?
4. (this is the big one) How many people are developing Agile Platform apps, deployed to the same server, but servicing different customers... where each app is dedicated to that customer? In other words, hosting what is developed as a single-customer, internal use app in a SaaS model? And if so, why don't you VM the app servers so that each customer is on a separate machine?

Basically, for every scenario I can think of that would justify multiple DBs, multiple app servers would be justified too.

J.Ja

Hi Frank,

Thanks a lot for rephrasing the question, since there's a lot of opinions here that will add to the discussion.

I wanted to add something, building on top of what you said, and Joost and Justin answered.

Here, without taking other manual steps, if I create 5 separate applications, in all likelihood intended for 5 different customer projects, the tool will just mix all of that into one database.

Yes, that is correct. However, as Joost pointed out, if you are just developing the applications in-house, and then deploying them at the 5 different customer sites, then it doesn't really matter to you, right? I mean, you're just developing the applications, and the data itself isn't the main concern in your environment as I see it. When you deploy each application at each customer's server, it will only create the required data models for each application in each individual server.

If, on the other hand, you are hosting these 5 applications for the 5 different customers, then I do see your point. Even though it is pretty much feasible to host the 5 applications for 5 different customers in the same Agile Platform server (trust us, I mean, the server you are accessing our forums also hosts tons of other corporate applications at the same time as well as our corporate web site...), I can see that you could want to deploy each application's data in individual databases.

If that's the case, however, then you'll go into Justin's scenario: more than database scalability, you'll also be looking to scale the application servers. And if you are in a scenario that you are under such a heavy load that you require multiple application servers to handle all the traffic, you can get such features in our more advanced editions - but I would see this not being a requirement by default.

Regards,

Paulo Tavares