All About PostgreSQL Remote Access Under Plesk

Once you have installed the PostgreSQL database server, you may notice that the remote access mode is unavailable. This is a default setting implemented for effective security. But you might prefer to enable PostgreSQL remote access to the PostgreSQL database server so you can use it remotely from different locations, such as your house or workplace. So, how do you do it? Read on to find out all the key information on Plesk PostgreSQL remote access.

Plesk: What it is and how it works

Plesk and PostgreSQL go together beautifully. You may have heard of Plesk: it’s one of the U.S.’s and Europe’s biggest paid hosting platforms. Different editions are available, and Plesk is designed to support Windows as well as various editions of Linux. These include CentOS, Debian, Ubuntu, Cloud Linux and RedHat.

Database servers are required for Plesk, for the storage of its databases as well as those utilized by its various elements (such as the webmail service). Databases developed by hosting clients’ sites and APS apps (e.g. WordPress) are necessary too.

Plesk can support most of the popular database engines. The list of compatible options includes MySQL and, of course, PostgreSQL. It’s shipped with relevant tools for effective database management, and Plesk is able to work with database servers located on the same server or a remote machine.

We’ll take a closer look at connecting Plesk and PostgreSQL below.

PostgreSQL: What it is and how it works

This database system both utilizes and extends the SQL language. To do this, it leverages an object-relational model that stands apart from others. PostgreSQL is capable of handling highly-demanding workloads, designed to keep data stored safely and affording outstanding scalability. PostgreSQL was created at the University of California at Berkeley, as part of its POSTGRES initiative in the mid-1980s. In the decades since, PostgreSQL has undergone considerable work and adjustment — the core has expanded consistently through rigorous ongoing development.

The open source PostgreSQL community is incredibly committed, which makes this database system one of the best. It enjoys a reputation for ongoing data integrity and extensibility, as well as its strong out-of-the-box functionality. As a result, PostgreSQL can be run on the majority of the biggest operating systems in the world.

Another key facet of PostgreSQL is that it complies with ACID requirements, and has done so for almost two decades. Many solid add-ons can be used with PostgreSQL, too, such as POSTGIS. You can use this extension to utilize geospatial data for your database.

With all this in mind, it’s no surprise that PostgreSQL is regarded as one of the open source community’s biggest relational databases. It’s the primary option for a vast range of companies, individuals and organizations.

Last but not least, PostgreSQL is simple to set up and get running. All you need to do is pick the app you’d prefer to make and rely on PostgreSQL to safeguard your data in a strong database.

Using a Plesk server to configure remote PostgreSQL access

PostgreSQL is set to “localhost” by default — you’ll be refused entry if you attempt to connect to the server from outside the machine.

So, to enable access to PostgreSQL server remotely:

Step 1: Connect to PostgreSQL through SSH

Step 2: Execute the right command to get the location of postgresql.conf file (such as /var/lib/pgsql/data/postgresql.conf): psql -U postgres -c ‘SHOW config_file’

Step 3: Open postgresql.conf file and put this line at the end: listen_addresses = ‘*’

Step 4: Get the location of pg_hba.conf file:

grep pg_hba.conf /var/lib/pgsql/data/postgresql.conf


where /var/lib/pgsql/data/postgresql.conf is the file resulting from the second step

Step 5: Put this at the end of /var/lib/pgsql/data/pg_hba.conf file: host samerole all md5

Some important points:

Connection is allowed from this remote IP: If you’re aiming to enable connection from any IP, make sure to specify .

The authentication method is md5. This demands that clients provide a double-md5-hashed password for secure authentication.

The user “john.doe” from database example1 can only access that database.

For different methods of authentication, check PostgreSQL documentation.

To put the changes into effect, restart PostgreSQL server through: Plesk > Tools & Settings > Services

Comprehensive Guide on Open Source Databases

Data plays a crucial part in running a successful organization today, across all industries. And this means that databases are incredibly important for effective, efficient data management. But what are the best options for your goals and budget? To help you find the best open source databases for your upcoming project, we’ve explored the top 11 options on the market right now.

Which is the Top Open Source DBMS?

There seems to be a huge variety of database suites available, with newcomers arriving despite the long-term popularity of powerhouse names like SQL Server and Oracle. A key driver of this ongoing innovation in database design is the freedom which open source brings: enabling developers with talent, skill, and time to create a product they’re genuinely passionate about.

Of course, we can’t overlook the creation of newer business models which allow companies to run community versions of products. This facilitates access to mind share and pivotal traction, while delivering a commercial offering.

As a result, there’s a bigger selection of databases than developers may be able to keep up with — dozens of options now exist. That creates the potential for solo developers and teams to become seriously confused. And that’s not to mention the immense documentation to explore.

When you have a project coming up, you want to find the best database for your goals and requirements with minimal fuss. Just get what you need, get in, get out.

That’s why we’ve taken the time to explore 11 of the best databases you can take advantage of for enhancing your own or someone else’s solutions.

First, though, let’s clear a few things up:

MySQL is NOT in this list. We’ve decided to leave MySQL off this list, despite it being regarded as the most popular open source database on the market. We feel that it’s so ubiquitous, so well-known, and so easy to learn about, there’s just no point in exploring it with you here.

And remember: the open source DBMS products we’ll cover below aren’t necessarily to be considered as MySQL alternatives. Yes, they might serve that function in certain cases, but they could be a totally different solution in other situations. We’ll get into that more when appropriate.

Another point to explain is compatibility. It’s worth keeping this in mind if you’re starting a project which supports a specific database engine only. For example, if you were using WordPress, this guide might not be the best read for you. And if you’re running JAMStack static sites, again, these alternatives may be outside your field of interest.

Ultimately, it’s down to you to make sense of the compatibility situation, but if your slate’s blank and you’re flexible with architecture, you’ll find some terrific recommendations below.


Never heard of PostgreSQL? This might seem like an odd option if most of your experience comes from PHP solutions like Magento and WordPress. But this database is nothing new — it’s been in operation since the mid-90s.

It’s a go-to option for such communities as Python and Ruby. Actually, plenty of developers upgrade to PostgreSQL based on the range of features available and its well-known stability. Yes, you might not be converted to it based on a short piece of coverage like this, but it’s fair to say that PostgreSQL is made incredibly well and offers reliable performance.

You can choose from some solid SQL clients for connecting to the database, for effective development and administration.

What are the key features of PostgreSQL?

This open source DBMS boasts some outstanding features compared to others (particularly MySQL). They include:

  • In-built data types for Range, Geolocation, and more
  • Scriptable in Python, PL, etc.
  • Replication that’s both synchronous and asynchronous
  • Full text searchability

The strongest of these features could be the geolocation engine, which reduces the frustration that sometimes comes with location-based applications). The array support is a big advantage, too.

When should you use PostgreSQL?

PostgreSQL can be considered a better option than alternative relational databases, especially if you’re launching a fresh project with no experience of MySQL. Developers have been known to quit due to MySQL’s negative aspects and switch to an easier option instead.

This is also fantastic if you’re looking for partial NoSQL functions for a hybrid data model. As key-value storage and documents are supported natively, there’s no need to go looking for learning, installing, or maintaining different database options.

When is PostgreSQL not right for you?

This option is unlikely to work for you when you don’t have a relational data model and clear-cut requirements for your architecture. So, for example, with analytics, in which fresh reports are created with existing data regularly, systems such as these can suffer with enforced strict schemas.

While PostgreSQL benefits from a storage engine for documents, things can become complicated when handling datasets on a large scale. PostgreSQL, then, is ideal for anyone with anything less than total confidence in what they’re doing.


This was built as a MySQL replacement ( please read MariaDB vs MySQL comparison ), and comes from the mind of the person responsible for the development of MySQL!

MySQL was acquired by Oracle years ago, and its developer launched their own open source project — MariaDB. It was made using the same code base (a process known as forking), which is why MariaDB became known as a valuable drop-in alternative to MySQL.

So, if you want to migrate from MySQL to MariaDB, rest assured: it’s a quick, easy process. However, you can’t go back to MySQL once you’ve migrated to MariaDB.

What are the key features of MariaDB?

MariaDB could be considered a MySQL clone, but there are a number of differences between the two. Anyone considering switching to MariaDB should think about it carefully, though, but fortunately, there are a wealth of new features that make MariaDB more appealing:

  • There’s no licensing issues or similar “corporate” interruptions to worry about, as MariaDB is open and free
  • MariaDB is faster than MySQL, thanks to the Aria storage engine which handles complicated queries
  • More storage engines, such as ColumnStore and Spider
  • Stronger capabilities for replication, including multi-source
  • Numerous JSON functions

When should you use MariaDB?

MariaDB is a fantastic, authentic replacement for MySQL, but you have to be sure you’re not going to want to go back to MySQL before committing to it. An example usage is relying on new MariaDB storage engines to align with your project’s current relational data model.

When is MariaDB not right for you?

The only issue here is MySQL compatibility, but it’s less problematic as Joomla, WordPress, etc. have begun to offer MariaDB support. It’s best to avoid MariaDB as a way to trick your CMS if it doesn’t support it — there are numerous database tricks that can cause your system to crash.


Cockroach is named so because it’s built for survival, like the insect by which it’s inspired. Cockroaches find ways to survive all manner of situations, and this solution is made to do the same.

CockroachDB comes from a team comprising former engineers at Google, who were irritated by restrictions imposed by traditional SQL options when working on larger scales. Generally, SQL solutions have always been intended for single-machine hosting, and there was no option to create a database cluster running SQL. That’s why MongoDB earned a lot of notice.

While PostgreSQL, MariaDB, and MySQL have all offered clustering and replication, the results have been less than impressive. But CockroachDB is made to offer a stronger alternative, delivering smoother clustering, shading, and availability for SQL.

When should you use CockroachDB?

This is perfect for system architects: anyone who loves SQL and is fixated on MongoDB’s scalability options is sure to be amazed by CockroachDB. It lets you set up clusters and process queries efficiently.

When is CockroachDB not right for you?

Is your RDBMS doing its job well for you right now? Can you handle any of its scalability problems? Then you might be happy to stay with it for the time being. While CockroachDB is a work of genius, it’s still a new option and you don’t want to find yourself struggling to use it down the line.

SQL compatibility is another potential stumbling block, as if you’re performing complex SQL and depend on it for crucial things, CockroachDB can be said to bring a higher number of edge cases than you might like.

From this point on, we’ll look at NoSQL database options for users with highly-specialized requirements.


Connected data is one of the biggest, most important developments within the past 10 years. We all know the world isn’t separated into neat tables — it’s a colossal mess in which almost everything is connected. One great example of this is social media, and creating a data model that’s similar with SQL (or document based databases) can be a formidable challenge.

Why? Because the graph is the perfect data structure for these, and that’s a totally different thing altogether. For this, you’d be best with a graph database — which is where Neo4j comes in.

A data model in which many users or entities are connected is incredibly difficult to build with SQL, due to the struggle of avoiding memory overruns and infinite loops.

What are the key features of Neo4j?

  • Graph analytics and transactional application support
  • Specialized query language used to query the database (Cypher)
  • Features for discovery and visualization
  • Digest complex tabular data into a graph form with data transformation functions

We won’t go into the “when to use” and “when not to use” points here — if you’re looking for graph-based data relationships, Neo4j is your best option.


We mentioned MongoDB above, and it’s an incredibly important database. This was the first of the non-relational databases to create an impact within the technology industry, and it remains a firm favorite today.

This is different to relational databases, as it’s a document database designed to store related data together in chunks. For example, a user’s contact information and access levels are located within one object. When you fetch the user object, you fetch all related data automatically with no join concept.

What are the key features of MongoDB?

A number of MongoDB’s features have inspired experienced architects to quit relational databases and choose this alternative instead. These include:

  • Add or remove nodes from clusters with ease
  • Distributed transactional locks
  • Flexible schema for different, specialized use cases
  • Optimized for quick writes, ideal as a caching system for analytics

NoSQL’s data modelling can be daunting at first, but when architects get to grips with it, they might find it’s always the best alternative to a table based schema.

When should you use MongoDB?

MongoDB is a fantastic entry point for those switching from the regimented SQL world. MongoDB is ideal for creating prototypes due to the lack of schema, and it’s great for scaling.

There are use cases in which SQL options are ineffective. When building a product in which users can make designs that are arbitrarily complex and edit them down the line, relational databases are not the best option.

When is MongoDB not right for you?

For users who don’t know quite what they’re doing, MongoDB’s lack of schema can make it difficult. Such issues include empty fields which shouldn’t be empty, data mismatches, and more. MongoDB users have to remember that the application code must take responsibility for the maintenance of data integrity.


Why is this named RehinkDB? Because it takes a fresh approach to a database’s capabilities when working on real-time applications. When databases are updated, the app has no way to know, and the traditional approach is that the app launches notifications when an update occurs.

This is typically brought to the front end via a complex route, but RethinkDB is designed to bring updates to the front end from the database directly. This is ideal for building real-time apps — including games, analytics tools, etc. — and makes things a little simpler.

Again, no need to go into reasons to use or not to use. If you need RethinkDB, you’ll know!


Some might have overlooked Redis, as it’s an in-memory database used primarily for caching and other support functions.

Redis is fairly quick and easy to learn. It’s a user-friendly key value store, able to store strings with a variable point of expiry (which can be tweaked to be infinite!). While it doesn’t have the biggest portfolio of features on the market, Redis is still an impressive option based on its performance and wide-ranging utility. It lives completely in RAM, which means its read and write speeds are jaw-droppingly fast.

So, if you’re running a project which might benefit as a result of caching or a distribution of components, Redis is well worth a look.


Okay, so we might have claimed that relational databases wouldn’t feature on this list again, but we’re going to cheat a little with SQLite.

This C library provides users with a relational database storage engine, and everything included within the database is able to exist in one file using a .sqlite extension. As a result, you can place these wherever in your filesystem you like.

With SQLite, there’s no service to worry about connecting to and no software for installation either.

What are the key features of SQLite?

SQLite might be a fairly lightweight option, especially when compared to something like MySQL, but it’s a solid package. Its features include:

  • Support for thousands of columns in a table (up to 32,000)
  • Complete transactional support (ROLLBACK, BEGIN, and more)
  • Support for JSON
  • Database size reaches a maximum of 140TB
  • Faster (by 35 percent) than file I/O

When should you use SQLite?

SQLite is specialized and designed for a hassle-free, focused methodology. So, if you’re working on an app that’s fairly simple and want a smooth process without relying on a traditional database, SQLite is a worthy option. It can work well for small or medium CMS or demo apps.

When is SQLite not right for you?

SQLite may be solid, but it doesn’t have all of the features that standard SQL or other high-quality database engines offer. For example, it lacks scripting extensions, stored procedures, and clustering. Furthermore, it’s missing a client for connecting, querying, and exploring throughout the database. Performance is known to decrease as applications increase in size too.


Ever heard that Java is reaching the end of its road? Well, it’s a common claim, but from time to time, something comes along to challenge it. Something like Cassandra.

This is part of what can be considered the columnar group of databases, and Cassandra’s storage abstraction is a column instead of a row. The aim is to keep all data stored within a column physically based on the disk to reduce the seek time as much as possible.

What are the key features of Cassandra?

Cassandra was built for a specific kind of use case: handling write-heavy loads with no tolerance for disruptive downtime. The main points include:

  • Scalability is linear, so you’re free to add any number of nodes to clusters as you like with no increase in brittleness or complexity
  • Write performance is incredibly fast, and Cassandra is the quickest database for heavy write loads
  • Partition tolerance is unmatched, so if a number of nodes within a Cassandra cluster fail, the database is made to continue performing with no integrity loss

When should you use Cassandra?

Two of the strongest Cassandra use cases are analytics and logging. On top of this, huge amounts of data can be handled with no downtime, accommodating projects on all scales.

When is Cassandra not right for you?

Cassandra’s column storage setup has its fair share of drawbacks. For a start, the data model is somewhat flat and high availability is only achieved at the cost of consistency. As a result, Cassandra could be considered as less effective for systems which demand high accuracy in reading.


Timescale is one of the strongest open source databases for the IoT (Internet of Things) age. Timescale is known as a ‘time series’ database, which differs from traditional ones in that time is the main factor. Visualization and analytics of large amounts of data is crucial.

These time-focused databases infrequently spot an adjustment to existing data, such as temperature information from climate sensors. New data is gathered on a second by second basis, ideal for analytics and subsequent reports.

But why would anyone choose to use this rather than a standard database featuring a timestamp field? There are two core reasons why. First, traditional databases made for general purposes aren’t optimized to function with data revolving around time. They’ll be far slower when dealing with lots of data.

Second, the database has to handle plenty of data as it continues to be generated, and removing or altering schema isn’t an option down the line.

What are the key features of Timescale?

This has a range of impressive features which help it stand out from alternatives in its category:

  • As Timescale is built on PostgreSQL, which is considered the best open source relational database available, it’ll fit in brilliantly if your project utilizes PostgreSQL already
  • Write speeds are extremely fast, with potentially millions of inserts each second
  • Timescale can handle billions of data rows
  • Select relational or schema-less based on your unique requirements

We won’t cover when you should or shouldn’t utilize Timescale here. If you’re working in IoT or looking for similar characteristics in a database, Timescale could be right for you.


This is a well-made database that might not be as well-known as others, but it’s designed to handle such issues as network loss and eventual data resolution (developers would rather abandon tasks than try to deal with this themselves).

You could consider a CouchDB cluster to be a distributed set of nodes of different sizes (including some offline). Whenever nodes go online, they transmit data to the cluster, so that it’s digested gradually until it’s available for the whole cluster.

What are the key features of CouchDB?

  • High reliability and resistant to crashes
  • Simple clustering and redundant data storage
  • Specialized mobile and web versions (e.g. PouchDB)
  • Capable of offline-first syncing of data

When should you use CouchDB?

This was designed for offline tolerance, and is still unparalleled here. An example of a standard use case would be a mobile app in which the portion of data is located on a CouchDB instance on a user’s device.

As the user’s device can’t be connected constantly, the database must be ready to resolve updates which may conflict at a later point. This is where the innovative Couch Replication Protocol comes into play.

When is CouchDB not right for you?

Anyone attempting to use CouchDB for a purpose beyond the use case intended is likely to encounter serious issues. It demands a higher amount of storage than others on the market, mainly as it has to maintain redundant data copies and results of conflict resolutions.

This means that its write speeds tend to be incredibly slow, too. CouchDB is unsuitable as a schema engine for general purposes, as it doesn’t cope with schema changes too well.

Final Thoughts

Do you think this list may be missing some solid candidates? That’s because it’s designed to guide you rather than command you — we’re here to inform and advise, not dictate.

Hopefully, you’ve discovered an extensive range of database options that help you achieve your goals to a high standard. Take your time before choosing your open source DBMS and you should be satisfied with the results.

Open Source Databases in Plesk

Plesk represents a fully featured web hosting platform for automating web hosting business and daily sysadmin tasks. This hosting platform is compatible with Linux and Windows operating systems and supports certain database management systems. On Linux Plesk officially supports MariaDB, MySQL and PostgreSQL database servers. Plesk for Windows has full support of non-open source Microsoft SQL DBMS as well as open source MariaDB and MySQL. Although MongoDB is not officially supported – there are  workarounds on how to make them working together.

NoSQL vs SQL: Examining the Differences and Deciding Which to Choose


At 74, Larry Ellison, co-founder and CTO of Oracle has amassed a fortune of $66.1 billion. He got going in 1966 and in the seventies took an idea from IBM’s Edgar F. Cobb for a SQL relational database. This became the Oracle Database rdbms (relational database management system). With no free software competitors, Oracle totally dominated the market. Everything else, like DB2 was running on IBM mainframes, and even it couldn’t oust Oracle from its top position. Mainframes remained popular until the 1990s, when PCs started to be used as servers, as they still are today. Oracle is still in the top spot for the majority of transactional business applications used by the richest companies. It bought the commonest opensource, MySQL, along with opensource Java, but both are still free to use. The big choice for all companies is still SQL vs NoSQL – between relational (SQL) or non-relational (NoSQL) data structure. Both are great in their own way, and both come with pros and cons of course, which we’ve listed for you here.

What is SQL?

SQL (Structured Query Language) organizes information in relational databases. It’s used in Oracle, Sybase, Microsoft SQL Server, Access, and Ingres. SQL uses relations (usually referred to as tables) to store and match data using shared features within the dataset.

It was Cobb’s notion that you could have a database that could be queried using a structured query language. He used SQL to create data in objects known as tables, along with the schema for that data, which describes fields in columns. One SQL record is known as a row.

What is NoSQL?

A NoSQL database describes itself, so it doesn’t need a schema. It also doesn’t mandate relations between tables in all scenarios. It only uses JSON documents, which are self-contained and easy to understand. NoSQL means high-performance, non-relational databases that use many different data models. They are known to be easy to use, have scalable performance, are resilient, and also widely available. NoSQL database examples include MongoDB, MarkLogic, Couchbase, CloudDB, and Amazon’s Dynamo DB.

NoSQL vs SQL: Major Differences

When choosing a data management system for your organization, you need to take into account the many and varied differences between SQL and NoSQL. There are differences in:

  • Language
  • Scalability
  • Community
  • Structure


Use of a Structured Query Language makes any SQL-based database very versatile and helps to explain why it is used so widely. On the downside though, this also restricts it. You have to use predefined schemas to set out the structure of your data before you can even get started. Your data has to use the same structure too, structure as well, you may have to invest considerable time into pairing your data to make it ready.

A NoSQL database has a dynamic schema for unstructured data which can be stored in a lot of different ways, including graph-based, document-oriented, column-oriented, or organized as a KeyValue store. Being highly flexible like this means you won’t be burdened with the same amount of preparation. You’re free to add fields as you go and vary the syntax from database to database. Every document can have its own individual structure, so have a great deal of latitude.


Another significant difference between SQL and NoSQL is how scalable they are. With the majority of SQL databases, can scale them vertically, meaning individual servers can be boosted through the addition of more RAM, SSD, or faster CPU. But NoSQL databases scale horizontally, meaning that they can handle increased traffic simply by adding more servers to the database. NoSQL databases have the ability to become larger and much more powerful, so they are great for handling large or constantly evolving data sets.


SQL has been around for long enough now that its community is large and well developed. If you need a query answered or want to pick up new skills, there are seemingly endless forums full of experienced users who will be glad to help you out. NoSQL can’t match this level of peer support yet because it’s the new kid on the block, so unfortunately, you’ll have to come back in a few years.


SQL databases use a tables approach which makes them better suited to handling apps that ask for multi-row transactions. Accounting systems or legacy systems that were originally created for a relational structure are examples of these. NoSQL databases can be key-value pairs, wide-column stores, graph databases, or document-based.

SQL or NoSQL: Which One is Going to Fit Your Business?

The best way to determine which database is right for your business is to look at what you need it to do. If you need a predetermined structure, multi-row transactions and set schemas then SQL is the one to go for. It’s also highly consistent, which makes it an ideal choice for accounting systems.

If your company is growing rapidly and doesn’t need clear schema definitions, then NoSQL is what you want. A relational database won’t offer as much flexibility as NoSQL, which is great for companies that need to churn through large amounts of data that comes in varying structures.


We can see that the first field is teacher and the second field is subject.

{ teacher:  "James Smith", subject:  "literature" }

With SQL, you create this schema before adding it to the database:

CREATE TABLE teacherSubjects (
teacher varchar,
subject varchar

Varchar is variable character length. To add data to that table, you would:

INSERT INTO teacherSubjects (teacher, subject)
VALUES ("James Smith", "literature");

With a NoSQL database, in this example using MongoDB, you would use the database API to insert data like this:

db.teacherSubjects.insert( { name: "James Smith", subject: "literature" } )

Now you can create the union (all elements from two or more sets) and intersection (common elements of two or more sets) of sets using SQL.

This was such a big deal because all this could be programmed using simple SQL syntax. Then Oracle added indexing fields and caching records to improve performance and make sure that the database could complete referrals with integrity. (Referential integrity is about the completeness of transactions, so you aren’t left with orphaned records. For instance, a sales record with no product to go with it. This is what enforcing the relationship between tables refers to in Oracle.)

Note that in the above MongoDB example, Oracle programmers would call the teacherSubjectes table an intersection. It tells you what subjects a teacher has and also which teachers are in which subject. So you could also add things like subject room number and teacher email address to both records.

The Oracle database is known as a row-oriented database because that’s how it’s organized. There’s no need to turn our attention to column-oriented databases like Cassandra here, because they have different architecture. So, they are not so fundamentally different as SQL vs NoSQL. In particular, the Cassandra NoSQL database columns with similar data near to each other for the fastest possible retrieval. Cassandra and NoSQL databases do away with the concept of database normalization, which is fundamental to Oracle, as we outline below. And they don’t keep empty column values, so the rose can be different lengths.

Normalization and Efficiency

Something which Oracle emphasized was the relationship between objects, insisting that all data should be normalized, and nothing should be stored twice. In practical terms, instead of repeating the school address in every teacher record, it would be more efficient to keep a school table and put the address there. This constraint is largely absent in NoSQL databases, so it wins out here in the SQL vs No SQL debate.

Storage space and memory were costlier in the 1970s, so normalization was necessary. These days though, assembling a record that is split between different tables takes more of both, not to mention the fact that you also need to maintain index files, which can slow everything down.

Fans of NoSQL databases say memory and storage are so cheap and processing power so exponentially faster now that none of that really matters. The computer can handle it and it’s easier for programmers to code.


SAP is Oracle’s biggest business competitor and has its own database, Hana. Oracle keeps all its records in memory (flushing them to disk as necessary) for the speed advantage it brings, but apart from that, they work in pretty much the same way.

NoSQL has been around for so long that it’s hard to argue a business case for changing to a newer one. When firms already understand rdbms, why switch? Oracle has solved management issues like data replication, which might leave someone using, ElasticSearch, for instance, unsupported with a compromised system on their hands. To avoid this, some businesses support opensource databases, like ElasticSearch, in-house, so you can buy in the help you need from them.

There’s been a big shift towards transactional systems. The addition of a sale to a sales database is an easy-to-understand concept. Once it’s done, Oracle calculates on-hand inventory using a saved SQL operation called a view. For MongoDB, a program would have to go through inventory items and takeaway the sales to work out the new on-hand inventory.

NoSQL Databases in Action

Looking at MySQL vs NoSQL, it’s interesting to note that NoSQL databases tend to be used in niche rather than enterprise systems. Uber is a good example as it uses Cassandra to keep tabs on its drivers, but it has unique needs, like writing millions of records a second across many data centers. The company wrote its own version of Cassandra in order to have it run on Mesos. Mesos is an orchestration system that resembles containers.

Amazon markets is a DynamoDB database which has “millisecond latency.”

DynamoDB, like MongoDB, has a JavaScript interface, which makes it simple to use. To add a record, for instance you open the database, then add a JSON item like this:

var docClient = AWS.DynamoDB.DocumentClient()
docClient.put("{JSON … }"}

One implementation detail is that you can use Node.js to run these operations in MongoDB and DynamoDB. Which means JavaScript running in the middle tier, so you don’t have to create JAR files or middleware servers like Oracle Weblogic.

So, which of the two is best for you? You could still run your accounting system on a RDBMS system. But don’t necessarily need to pay licensing fees to Oracle. You could use MySQL instead. But will it use MongoDB? That is unlikely in the short term, as huge numbers of programmers across the globe use Java and Oracle, which project managers and users understand. Use ElasticSearch for logs and Spark for analytics. With the others, look at them individually to see if they will fit in with your resources, skills, tolerance for suffering lost transactions, etc.


Whatever your field, selecting the correct database for your firm is a crucial decision. NoSQL databases are rapidly establishing themselves as a significant force in the database landscape. They bring many benefits: they are cheaper, are open-source, and easily scalable, which makes NoSQL more appealing for anyone who needs Big Data integration. It’s a new technology though, which can bring its own problems.

SQL databases, in contrast have had more than four decades to establish their well-defined. A mature community offers almost limitless possibilities for collaboration and support.

In the end, the choice of SQL vs NoSQL for business will come down to the individual needs of the companies concerned. Only through extensive research comparing their abilities to your needs will you find the one that is the best fit.