A previous article describes how to configure SAS Viya to leverage an external instance of PostgreSQL for the SAS Infrastructure Data Server. After reading it, you may still wonder: “Why would I choose to leverage an external PostgreSQL instead of going with the default internal one provided by SAS?”. Well, I’m glad you asked: here you can find some pros and cons we collected during multiple architecture design workshops.
One of the design principles of SAS Viya is to give customers more choices and control over their desired architecture. This starts with supporting many Kubernetes cluster providers: you can run your cluster on local machines or in a cloud platform, including supported versions of Microsoft Azure, Amazon Web Services, Google Cloud Platform, and Red Hat OpenShift. Deployments with open-source Kubernetes are also supported. We can easily say this is the modern incarnation of the decades-old Multivendor Architecture!
As soon as the first customers started deploying SAS Viya on their Azure clouds (that was the first provider SAS supported back in 2020), they asked about the possibility to leverage their existing native cloud instances for some of the services that SAS Viya requires. Supporting external instances of PostgreSQL answers that requirement, and, in the future, additional services will be able to leverage native cloud implementations. Examples may include Azure Service Bus instead of the SAS Viya-provided RabbitMQ for message queues, or external instances of OpenSearch.
This already gives us the first, possible answer to the original question: using an external instance of PostgreSQL can be a good choice if you already have one! You should still consider all of the system requirements, to make sure that SAS Viya can leverage what you are already using.
Apart from this obvious case, what other considerations should you weigh when deciding to use a PostgreSQL instance not provided by SAS?
Here is a non-comprehensive list gathered from discussions with customers and colleagues during multiple architecture design workshops.
- Do you have the required competency to properly manage a PostgreSQL database? In other words, who is responsible for maintenance? With an external instance, this can be the cloud provider, in case of managed instances, or it can be your IT department for self-hosted installations. With an internal instance, it’s all provided by SAS and managed by the SAS administrator. SAS documentation provides instructions for general management of the included server and services, with a specific section for PostgreSQL administration.
- Can the instance be configured as required by SAS Viya? Obviously, the chosen PostgreSQL instance should be included in the list of supported versions and distributions, but that’s only the first check. SAS Viya has specific requirements including user permissions, available database extensions, configuration settings (a very important one is the maximum number of concurrent connections), and so on. Make sure that these requirements do not conflict with the settings required by other applications that may be using the same external database instance.
- Can it handle the increase or decrease in your workload? The SAS-provided internal instance supports tuning both at the infrastructure level (number of database replicas, CPU, and memory allocated per pod) and at the database level, allowing you to tune the server to meet expected workloads. For the complete list of available PostgreSQL configuration parameters, see https://www.postgresql.org/docs/12/config-setting.html
- Does it support High Availability, Non-Disruptive-Updates? Sometimes the devil is in the details. Some external PostgreSQL distributions claim High-Availability support, but still leverage a single PostgreSQL replica. That means the underlying infrastructure (VM, storage, network, ...) has guaranteed SLAs, but, when the single instance is shut down for any reason – planned or unplanned – all client applications (including SAS Viya) are forced to stop. The internal instance is deployed by default with multiple replicas; if the primary server dies or is stopped for maintenance, one of the replicas is promoted to become the new primary, and service is resumed – it all happens automatically in a few minutes, with no forced stop or restarts.
- How much does it cost? If you are already running an external instance of PostgreSQL, you may be tempted to answer “almost nothing”; did you remember to consider any additional HW/storage that needs to be allocated for the increased demand? If instead, you have to deploy a new dedicated instance, it can cost you thousands of dollars per month in your cloud bill. The internal instance is co-located on the SAS Viya Kubernetes cluster, so it shares the costs with the rest of the infrastructure.
- Does your SAS Viya environment include any solution that currently does not support an external PostgreSQL database? If you are using any of the solutions listed on this system requirements page, you have no choice but to use the SAS-provided PostgreSQL: those offerings do not support an external PostgreSQL database instance. Support statements may change with newer releases, so be sure to always check that page before any new deployment to get the most current information.
Conclusion
SAS Viya gives you many choices and control over your desired architecture. In this article, you can find some of the considerations gathered from discussions with customers and colleagues to evaluate whether to use an internal or external instance of PostgreSQL for your SAS Viya deployment. Do you have any additional points that we may have missed? We’re always open to discussion and eager to learn, so share them in the comments!
Find more articles from SAS Global Enablement and Learning here.
