Posted on

A Case for Databases on Kubernetes from a Former Skeptic

Kubernetes is everywhere. Transactional apps, video streaming services, and machine learning workloads are finding a home on this ever-growing platform. But what about databases? If you had asked me this question five years ago, the answer would have been a resounding “No!” — based on my experience in development and operations. In the following years, as more resources emerged for stateful applications, my answer would have changed to “Maybe,” but always with a qualifier: “It’s fine for development or test environments…” or “If the rest of your tooling is Kubernetes-based, and you have extensive experience…”

But how about today? Should you run a database on Kubernetes? With complex operations and the requirements of persistent, consistent data, let’s retrace the stages in the journey to my current answer: “In a cloud-native environment? Yes!”

Posted on

Develop Multi-Value Applications With Modern Source Code Managers

Legacy Version Control Tools for Multi-Value Application Development

The legacy version control tools are specific to the multi-value programming controls BP libraries and DICT files on the PICK operating system environment. Checking out code from a BP library is usually known as the locking process because files get locked by the developer for the time of their code change request. This leads to the sequencing of processing code change requests because the files that the developer intends to modify are locked and copied to the development stage.

Let’s use an example to well explain this concept. Let’s consider five staging levels, such as development, QA, UAT, pre-production, and production environments. The developer is required to move their code changes through these staging environments. The developer checks out the elements from the production BP library to the development BP library and begins to work on modifying the elements.

Posted on

Spotlight on CockroachDB

The construction, process, and usage of databases has evolved a lot over the last few decades. Traditional relational databases were enough to work with the data present at that time, but with the innate reliance on the Internet, the progression of cloud-native architecture, and the advancement of how businesses utilize and analyze data science, relational databases are not cutting it. What happens if a node fails in a traditional single machine of a relational database? Your database would go down along with any applications that depend on it. 

Over time as NoSQL databases were introduced—which are capable of handling a large amount of data in real-time—the risk of apps failing began to decrease but the risk of data inconsistencies increased. So, there has been a growing need for a better storage solution for data to cope with today’s dynamic cloud-native architecture. CockroachDB was specifically designed to solve and meet this need. 

Posted on

Performance Differences Between Postgres and MySQL

Introduction

In the Arctype Community, we answer a lot of questions about database performance, especially between Postgres and MySQL. Performance is a vital yet complex task when managing a database. It can be affected by the configuration, the hardware, or even the design of the system. Interestingly, both PostgreSQL and MySQL are configured with compatibility and stability but depend on our database design's hardware infrastructure. 

Not all relational database management systems (RDBMS) are created equal. Although PostgreSQL (or Postgres) and MySQL share some similarities, they also have unique qualities that make one a better choice over the other in specific situations. We discussed a lot of these differences in a previous post. Still, in terms of performance, they have a lot of differences.