In this era of distributed computing, it is almost impossible to imagine setting up and running a business without having a website. That website will undoubtedly require a database.

Managing customer details, shipping details, inventory, despatch (and the later tracking) of orders, currency information, communications, logging and many many other responsibilities that have been delegated to digital organised storage in Relational Database Management Software (DBMS).

Many of these databases have existed for numerous years and have increased in complexity from having to accommodate increasing business demands. These databases are no longer nimble and as time goes on, increasing project demands get harder to integrate, or require yet another database.

Considering age, new databases are set up for projects that are rushed to market, often missing optimisations and leading to sub-optimal performance which will only degrade further with time.

In either case of an aged database or one that's only been operating for less than a year, a growing list of inefficiencies can build up; hidden and undetected.

A single starter RDBMS instance can cost from as little as £10 / $15 per month. Starting out, you're probably not sweating the small stuff. Larger businesses can easily spend hundreds or thousands each month and tens of thousands every year. You've probably already factored this into your monthly cost analysis. Self hosted (onsite or rented / dedicated bare-metal instance in a datacentre) databases also have hidden operational costs. We'll go into that later on.

Your business is doing well and it's time to scale to serve a larger number of requests to your webservice / online store / warehouse. You could scale horizontally (by adding more instances) or vertically (by adding more CPU / RAM / Disk space). You're aware that this will increase cost, but are you truly prepared to scale your database?

Let us analyse cost as a matter of more than just a figure you have made semi-tangible for your book keeping.

• You scale horizontally:
• • You get more instances behind a load balancer to handle more database operations and utilise high availability to protect against high utilisation bottlenecks
  • You pay for a load balancer and backups per instance, including any backed up mistakes and inefficiencies
  • Reading from and writing to the database is still taking longer than expected. This leads to a degraded customer experience, poor Search Engine Optimization (SEO) responses, in-house chronometric operational bottlenecks and skewed reporting
  • More admin is required, whether it is "managed" (service provider based) or "unmanaged" (onsite). This is expected, however managed service level cannot usually assist with tracking down inefficient schema before a problem occurs
  • Adverse changes to the database are spread over a larger area and are replicated
  • It will not be long before additional instances will be required, increasing cost exponentially with each instance, eating into your profit margins
• You scale vertically:
• • You get more CPU cores to handle more threads and more queries, more RAM to store the query results before they are sent to output and more disk space to store an even greater number of records
  • You pay for the extra CPU, RAM and disk space, only to notice your queries are still slow and even though you can handle more visitors to your site, there's still complaints from customers and employees alike that your website and your internal operations and reporting tools are slow to get them the data they need
  • Eventually you will run into the "Horizontal Scaling" method as described above to counter excessive utilisation. This will begin the cycle anew
• You take out a subscription and monitor your databases with Pletana:
• • Before and after you launch your first database or before planning to scale horizontally or vertically after running a database / multiple databases for an extended period of time:
  • Receive reports (by email) detailing best practices to employ for your database. By targeting a "staging" instance, receive feedback on a number of topics* including:
    • Table column density
    • Index efficiency
    • Schema ratio
    • and more...
  • Receive alerts* when schema changes on an observed database including:
    • Webhooks → Push notifications to a webhook endpoint of your choice
    • Emails → Send to a list of other users from your organisation that have a connected Pletana account
    • Push System Integrations → Configurations available for select push notification systems that are also used internally by Pletana staff!
    • SMS → SMS notifications that can be received when a WiFi / Ethernet connection is not guaranteed COMING SOON!
    • and more...

(Eco)System Shock

There is a modern emphasis on how economical or "green" a technology can be due to businesses pushing a more "eco friendly" marketing stance or genuinely caring for the environment.

By making your database more efficient, you reduce necessary storage space. As well as reducing cost, this makes the storage controller more efficient, which in turn uses less energy.

In turn, proper utilisation of indexes and other techniques can speed up queries, reducing both the number of processor cycles and the amount of RAM consumed which are both dependant on energy usage.

As a general rule: the more performance you can squeeze out of your database, the more overall reactive your connected applications will be. The effect of making the data-centric components of your digital ecosystem more efficient is a compound amplified return on investment.

Development, Operations & Project Management - The Headache Saga

In the system design and development paradigm, the software development life cycle (SDLC) begins its life with a set of real world needs and processes to be digitally abstracted that are carefully thought out; without scope creep, with shared ideas, with clear cut targets.

Unfortunately, those set of circumstances never quite happen. Instead we get meetings held behind closed doors, requirements at a moments' notice, requirements that shift and skew based on opinion and then ultimately are pushed into the live environment, often because there is little time left for testing in a staging environment.

Databases are the critical component that get overlooked as just another piece of software in these instances. There are those at all levels of employment whom believe that such matters can be rectified at a later date, but underestimate the complexity in doing so and risk system outages, lost revenues and longer development times as a result.

"Cut corners", "bronze standard", "minimum viable product". If you're the one that's handing out these phrases, or if you're the one on the receiving end of these excuses, it's time to get the tools to help do the job properly.