NoSQL stands for ‘Not only SQL’, and that explains why Postgres is the clear winner in DB-Engines’ ranking, on Stackoverflow’s developer survey, and on the Cloud Native Computing Foundation’s Database Tech Radar.

Postgres, as opposed to other relational databases, is built on an object-relational architecture. That is why it is the leader in combining relational data with geo-spatial data, key-value pairs, document data, and custom data types.

This key design decision, made by Mike Stonebraker over 25 years ago, is driving Postgres’ rapid adoption by developers and DBAs. DB-Engines’ ranking shows Postgres adoption outstripping MongoDB; the same is reflected in the CNCF’s Tech Radar and in the Stackoverflow survey.

Databases that are relational only don’t show similar adoption trends and may become less relevant over time.

Postgres has passed the test of time surprisingly well. In fact, Postgres’ heritage helps make it stronger as it matures. It is the #1 database in containers, and a key component of all the cloud providers’ database services. Cloud native offerings, such as EDB’s Cloud Native Postgres operator for Kubernetes, continue the drive towards making Postgres easier and more accessible to a broader audience.

Many traditional, commercial and proprietary databases have seen a decline, but Postgres has seen tremendous growth in parallel with the cloud. The fact that Postgres is open source, cost-effective, innovative, powerful and extremely reliable has contributed to that growth. Postgres also runs everywhere under the same permissive license, which is another reason for its increasing popularity.

Postgres, open source and cloud adoption, along with Kubernetes and microservices, all have one thing in common: rapid innovation driven by the need for digital transformation, high feature velocity and improved product market fit.

The key change that we have seen is the maturing of infrastructure as code, be it through Kubernetes operators or through tools like Ansible, which allow for rapid and repeatable Postgres deployments on premises, in the cloud, and in DevOps environments.

More than 95+% of all current databases fit comfortably on the advanced computer servers that are available today in the cloud or on premises. Very few applications actually need horizontal scaleout at a time when 96 cores or more are routinely available in the cloud and in most data centers. One argument historically brought forth by the proponents of horizontal scaling has been that it is difficult to scale compute and memory up and down.

Infrastructure as code technology, like Kubernetes and Ansible, makes scaling up of CPU and memory resources very easy and fast – a lot easier and faster than scaling out.

Also, keep in mind that scaling out to several servers means adding significant latency, as more data travels over the network, which is a lot slower than the backplane of a server or the databus of a modern high-density chip.

At the same time, with the advent of microservices, we see a lot more ‘smart’ designs that refactor super large databases into smaller, smarter architectures. It is a lot easier to solve problems upfront with a good design, rather than trying to fix them afterwards by throwing hardware at them. Fortunately, Kubernetes and micro-services encourage smart designs.

Often NoSQL is used as a synonym for ‘eventual consistency’, and relational really is intended to mean ‘ACID’ (atomic, consistent, isolated, durable). ACID compliant databases are highly reliable, and the outcomes of operations in these environments are highly predictable. That is key for business transactions, accounting operations, and any other data management task that requires 100% trustworthiness. Also, most analytical tools are designed to work with tables and relations. Often, NoSQL formats, like documents, have to be mapped into tabular structures first in order to perform analytics. This is true too for map reduce, which takes unstructured data, and puts it into a structured tabular and relational format to support queries.

The nature of the relational model, especially the use of normal forms, provides the developer a very powerful tool to avoid data redundancy and create data models that are not specific to a single use case.

Postgres has chosen the Portable Operating System Interface (POSIX) abstraction layer as its interface with the operating system. That allows it to run virtually everywhere, and explains why  it works in every cloud, in containers, with all key operating systems and with virtually all hardware platforms. EDB has many customers who have strategically decided to develop against the Postgres API as that allows them to create applications that can be deployed wherever needed.

Unlike other commercial databases that limit some of their features for high availability to their own cloud, there are no such restrictions with Postgres. EDB Postgres delivers the same highly available, always-on Postgres on every platform – not just on some select hardware lines or proprietary clouds.

This extreme portability makes Postgres the ideal platform for hybrid or multi-cloud strategies.

Nothing we do would be possible without a vibrant, independent, and innovative Postgres community. EDB is a strong supporter of the community. We count almost 30 full time EDBers who are named as contributors, committers or Postgres core team members, and we have 300 technologists dedicated to Postgres, the most in the world by a wide margin. Being Postgres fanatics means that we are relentlessly committed to continuing our investment in open source software and the community where we collaborate with the likes of Microsoft, VMWare, NTT, Fujitsu, and many others on creating the most transformative open source technology since Linux.

As my colleague Dave Page, a member of the Postgres Core Team, says, “We collaborate on the code, and we compete in the market.” This collaborative and symbiotic model is extremely important to EDB’s success and to Postgres’ growing adoption.