An In-Depth Guide to 6 Major Database Types and the Companies That Build Them

Databases organize, store, and manage data that powers everything from the websites you browse to the apps on your phone. But not all databases are created equal. Each type brings unique capabilities that make them better suited for certain applications.

In this comprehensive guide, we‘ll explore the 6 most popular database types and the key companies that build them:

At a Glance

Let‘s explore each database type in more depth:

Relational Databases

If you‘ve ever worked with data, chances are you‘ve used a relational database before. These databases represent data in tables with predefined columns and rows. For example:

Relational databases establish connections across these tables using keys:

As you can see, relational structures allow you to model complex relationships like enrollment across courses and students using these table connections.

A Brief History of Relational Databases

Relational databases originated from research papers written by Edgar Codd in 1970 which established key concepts like:

• Using tables with rows and columns for data
• Connecting tables through primary and foreign keys
• ACID properties for reliability
• SQL querying language

Commercial options followed in the late 70s/early 80s with Oracle and IBM pioneering relational databases. Standards around the SQL query language emerged in 1986 andRDBMS popularity boomed through the 80s/90s with options like MySQL, PostgreSQL, Microsoft SQL and more.

Thanks to their maturity and widespread use, relational databases remain a popular choice today across industries like:

• Banking
• Retail
• Government
• Healthcare

Nearly any application that relies on reliable storage and querying of structured data leverages relational databases to some degree.

Why Use Relational Databases?

The tabular structure, reliability and standardization of relational databases make them well-suited for:

✅ Transactional applications like orders and banking
✅ Structured business data like sales, inventory, etc
✅ Legacy applications you want to preserve over long time periods
✅ Situations where consistency and integrity are critical

Limitations of Relational Databases

✘ Rigid schemas make iterative development difficult
✘ Not optimal for rapidly evolving data
✘ Scaling requires expensive, high-end hardware
✘ Can struggle with huge volumes of unstructured data

Now let‘s move from the world of tables and SQL to more flexible systems…

NoSQL Databases

While relational databases rely on predefined schemas, NoSQL databases (aka "non-SQL" or "Not Only SQL") take a more flexible approach. They can ingest data in whatever form it comes in without tedious up-front modeling.

You can use NoSQL databases like MongoDB and DynamoDB in a variety of unstructured formats:

// Documents  
{
  name: "Sara Lee",
  enrolledCourses: ["CS101", "EE200"],
  gpa: 4.0  
}

// Key-Value Pairs
SaraLee => {name: "Sara Lee", gpa: 4.0}  

// Graph Structures
(saraLee)-[:enrolled]->(CS101)
(saraLee)-[:enrolled]->(EE200)

This flexibility allows NoSQL databases to scale out to handle huge volumes of data across cheap commodity servers.

A Brief History of NoSQL

The NoSQL movement kicked off in the late 2000s with companies like Google and Amazon pioneering distributed non-relational databases to cope with scale and flexibility needs.

Open source options like MongoDB arrived in 2009 and companies like Couchbase brought new approaches. Major cloud providers like AWS, Azure and GCP began offering fully-managed NoSQL databases.

Adoption boomed in large web companies who needed horizontal scale and flexible data ingestion. NoSQL database now power major sites like:

• Google
• Facebook
• Netflix
• eBay

Why Use NoSQL Databases?

NoSQL databases work well when you need:

✅ Flexible schemas
✅ Developer velocity
✅ Easy scaling
✅ Streaming or varied data types

Limitations of NoSQL

✘ Can struggle to ensure strong data consistency
✘ Typically lose advanced SQL querying capabilities
✘ Usage requires rethinking data modeling

While NoSQL provides flexibility, sometimes your data is more naturally modeled as connections…which brings us to graph databases.

Graph Databases

Relational structures excel at modeling tabular data while NoSQL handles variability. But what about interconnected data?

That‘s where graph databases come in.

Graph structures represent data as nodes, edges, and properties capturing connections. For example, you can model networked data from a social app:

This graph makes relationships first class citizens in the data model itself. You store entities as nodes and connections between them as edges.

Querying networked data becomes traversing the graph itself – a very natural way to interact with linked information.

Brief History of Graph Databases

While mathematical graph theory and networked data models originated in the 60s, commercial graph databases saw mainstream adoption more recently with companies like:

• Neo4j – Created in 2000, the most popular graph database
• Amazon Neptune – Fully-managed graph database by AWS
• TigerGraph – High performance parallel graph

Adoption boomed along with rising interest in knowledge graphs, connectivity analysis, and embodying relationships in the structure itself.

Graph databases now frequently support mission critical systems in sectors like:

• Fraud detection
• Master data management
• Social networking
• Recommendations

Benefits of Graph Databases

Graph databases shine when you need:

✅ Connectivity and relationship analysis
✅ Flexible and evolving data schemas
✅ High performance traversal of networked data
✅ Understanding complexity not apparent in pure tabular data

Downsides of Graph Databases

✘ Still an emerging technology
✘stddev Require rethinking data modeling
✘ Can lack capabilities of mature relational ecosystems

Of course when it comes to analytics on vast troves of data, columnar databases have your back…

Columnar Databases

If your workload relies heavily on crunching analytics across billions of data points, columnar databases offer unique advantages.

Instead of storing data in traditional rows, columnar databases organize information by column as seen below:

Pivoting data storage this way allows for:

✅ High data compression since values in columns are often repetitive
✅ Easy analytic querying focused on aggregates

So while rows excel at transactions, columns offer optimized analytics.

Brief History of Columnar Databases

Google unveiled the Dremel paper in 2006 outlining their columnar storage system underpinning Google BigQuery analytics. Startups like Snowflake arrived offering columnar databases for data warehousing. On the open source side, Apache Cassandra added columnar support in 2016.

Now column stores frequently support business intelligence workloads at scale across sectors like:

• Retail
• Finance
• Insurance
• Manufacturing

Benefits of Columnar Databases

Columnar databases work well when you require:

✅ Analytics & reporting
✅ Fast aggregate queries
✅ Large scale data volumes
✅ Data compression

Downsides of Columnar Databases

✘ Not optimized for transactions
✘ May require middleware to integrate operational systems
✘ Costly to store all raw data over long periods

While columnar structures serve analytical needs well, more niche requirements exist around storing specialized application data…

Enter object oriented databases.

Object Oriented Databases

Applications rely on a wide variety of intricate data structures from nested JSON to classes in object-oriented code.

Object oriented databases seek to model these rich structures directly without painful translations through mechanisms like:

• Object-oriented querying
• Complex attributes
• Inheritance
• Polymorphism
• Versions
• References

By cleanly integrating application objects and database, they aim to boost developer productivity and data fidelity.

For example, directly storing product variants with common roots but different properties:

Product
  - BookProduct 
    - title
    - isbn
  - VideoProduct
    - title 
    - length
    - resolution

Brief History of Object Oriented Databases

After early research papers in the 70s, companies like Object Design (later Objectivity after acquisition) started offering commercial object-oriented databases in 1991 focusing areas like:

• Telecom
• Manufacturing
• Media

They found niches managing intricate application data structures efficiently. Other companies like Versant and Progress (through acquisition of db4o)also offer their own object oriented persistence solutions.

You commonly find use in industries like:

• Engineering
• Financial services
• Government
• Utilities

Benefits of Object Oriented Databases

When you need to:

✅ Streamline object-data mapping
✅ Store precise complex data closely aligned with app code
✅ Integrate cleanly with object-oriented programming languages

Downsides of Object Oriented Databases

✘ Small ecosystem relative to relational and NoSQL
✘ Typically requires complex planning around data analysis
✘ Skills to utilize infrastructure remain relatively rare

This brings us to our final database structure – optimized for data through time…

Time Series Databases

Most database models excel at storing records, relationships, and structured snapshots. But as the Internet of Things (IoT) emerges along with devops monitoring, requirements arise around understanding behaviors through time using time series data:

• Sensor readings
• Application metrics
• Operational statistics
• Thermostat temperatures
• Car RPM telemetry

Time series databases offer high-performance storage and analytical engines purpose built for this temporal data including:

Optimal storage schemas, data lifecycle management and analytics functions specifically for time-oriented data underpin these systems.

Brief History of Time Series Databases

While time series data occurred in niche applications before, IoT and devops monitoring brought broad adoption of time series starting in 2015 with:

• InfluxData creating InfluxDB
• Timescale releasing TimescaleDB

Now drone fleets, self-driving experiments, analytics behind apps, and smart cities run on time series databases.

Benefits of Time Series Databases

Time series databases help when you need to:

✅ Store and analyze time-stamped data
✅ Achieve high ingest and query speeds on temporal data
✅ Manage histories over various time ranges
✅ Understand trends and behaviors over time

Downsides of Time Series Databases

✘ Requires planning data lifecycle management
✘ Typically requires separate databases for operational records
✘ Complex proprietary query languages

Key Considerations When Choosing a Database

With so many database types to choose from, how do you determine what fits your needs?

Here are some key points to consider:

What primary operations will your database handle? If transactions – relational may be best. If analytics – consider columnar. Time series for temporal data workloads.

How structured vs flexible does your data schema need to be? Relational offers structural rigor while NoSQL provides agility.

How interconnected is your data? Choose graph databases when relationships matter most.

What data volume sizes/growth do you expect? Relational can struggle to scale while NoSQL offers horizontal scale-out.

Does specialized functionality matter? Time series for time-based data, graph for connections, etc

How business critical is the application? Relational databases offer mission critical reliability.

What development skills exist on your team? Align database choice with internal experience and capabilities.

Another key consideration is managed cloud services vs running your own database infrastructure…

Cloud Database Options

Most database types are available as fully managed services through major cloud providers like AWS, Azure and GCP including:

• Relational: Amazon RDS, Azure SQL Database
• NoSQL: AWS DynamoDB, Azure Cosmos DB
• Graph: Amazon Neptune, Azure Cosmos DB
• Columnar: Google BigQuery, AWS Redshift
• Time Series: Amazon Timestream

These remove infrastructure management overheads and allow near infinite scale on demand. Just be cautious of tightly coupling your systems to proprietary technology that may cause vendor lock-in.

Wrap Up

We‘ve covered a variety of major database types along with history and leading technology companies in each market space.

Every model serves specific needs from crunching analytics on vast datasets to storing highly interconnected data. By understanding the core capabilities and typical use cases of each database type, you can determine the best choice for your needs. Reach out with any questions!