Dear all,

We have build our own product CMS platform configuration which is running on SQL server and CMS web site link to it.

We will lauch our product soon but need to identify the correct hosting plan for not having any further issue.

For exemple for now all is hosted in our company azure account with a Standard Basic 5 DTU's.

When we go in production we can expect some connection and big amount of data on our database.

My question are as follow :

- Does using a single database storage for my potential Customers would be enough ?

- How should I plan backup efficiently ?

- Should I plan a safety replication process somewhere in azure or duplicate the storage in order to switch in case of lack of place ?

My concern is to avoid my database beeing full while customers increase

Thanks for your advise and help

regards

serge

Serge,

Every app is different and it's hard to get very much insight into what kinds of loads to expect from what you've shared so far. I'd suggest, before you go public, you try to run some stress tests on your system to see how many connections and how much usage your application can support. Compare that to your expected traffic when you go live and probably include some buffer.

Each edition is a little different on backup - evaluate your needs and choose appropriately.

Replication is always recommended if you need high availablility. You will need to use at least standard edition to get some form of replication. Premium offers readable replicas which can be very useful if you're trying to load balance traffic or trying to decrease latency if you are targeting an international release.

If you share more about your app, I can try to share more advice, but a lot of it will come down to doing proper testing before you go live; otherwise, it's just theoretical.

-Chris

Hello Cris, thanks for your reply.
I will try to explain in more detail what is the application about.

First of all, we have run stress stess during development of our application but it is all therocial of course. What I try to reach is the type of service, type of database I need to selecte on Azure in order to be sure I will be in correct configuration site.

So for the application is actually based on 3 parts :

- 1 SQL server database attached to an Azure server
- 1 Web site that users will  be login in order to be able to configure Products ( see it as a light CRM portal
- 1  Web server hosting REST API services

As long as we will have more Customers using our small CRM web portal, the SQL database size is going to grow with the time. Users who can use our web portal can be from any country.

Of course we will not have 1000 customers in a month, but I try to anticipate potential further load or limit in database size in order to know what will be the action to do.

- If I select by default STANDARD Azure database, which size, DTU, etc should I select ?

- If for instance the initial URL of the web portal connected to SQL server1 has a trouble, how can I switch users transparently to a second replicated server in order that user will notify anything ?

- IF I select the Maximum size of the database, what will happen in case it will be nearly full and need to provide more space ?

regards

serge

Hi Solatys,

- If I select by default STANDARD Azure database, which size, DTU, etc should I select ? 

For this question, you may reference the below link. You can scale your Azure database performance based on the real-time requirement.
Azure SQL Database introduces new near real-time performance metrics 

- If for instance the initial URL of the web portal connected to SQL server1 has a trouble, how can I switch users transparently to a second replicated server in order that user will notify anything ?

Azure SQL Database has a built-in high availability subsystem that protects your database from failures of individual servers and devices in a datacenter. Azure SQL Database maintains multiple copies of all data in different physical nodes located across fully independent physical sub-systems to mitigate outages due to failures of individual server components, such as hard drives, network interface adapters, or even entire servers. At any one time, three database replicas are runningone primary replica and two or more secondary replicas. Data is written to the primary and one secondary replica using a quorum based commit scheme before the transaction is considered committed. If the hardware fails on the primary replica, Azure SQL Database detects the failure and fails over to the secondary replica. In case of a physical loss of a replica, a new replica is automatically created. So there are always at minimum two physical, transactionally consistent copies of your data in the datacenter.
Azure SQL Database Business Continuity

If you have any question, feel free to let me know.