Why I Chose PostgreSQL for My Platform

Choosing a Database Based on Requirements, Not Hype

• Why PostgreSQL?

• Why not MariaDB?

• Why not MySQL?

For me, choosing a database isn't about which technology is currently popular.

It is an architecture decision.

When I choose a primary data store, I look at several factors:

• 🧩 Data Model

• 🔒 Data Integrity

• 🔍 Query Capabilities

• ⚡ Performance

• 📈 Scalability

• ⚙️ Operational Complexity

• 🔓 Licensing

• 🧭 Long-Term Governance

There is no single best database.

There is only a database that fits a particular architecture, workload, and set of requirements.

For my platform, that decision led me to PostgreSQL.

🧠 Start With the Problem, Not the Database

Before choosing a database, I don't start by asking:

Which database is popular right now?

I start with a much more important question:

What does my application actually need?

My platform handles a significant amount of structured data with clearly defined relationships.

The finance part of the platform includes entities such as:

• 📈 Securities

• ⭐ Watchlists

• 💱 Exchange Rates

• 📊 Historical Market Data

• 🗃️ Snapshots

These entities are not isolated.

They have relationships.

A security can have historical market data.

A watchlist contains securities.

Snapshots reference financial entities.

Exchange-rate data has clearly defined currencies and timestamps.

That immediately creates several requirements.

I need:

• ACID transactions

• Foreign keys

• Constraints

• Indexes

• Joins

• Reliable relationships

• Sophisticated queries

Those are classic requirements for a relational database.

That brings the discussion to PostgreSQL, MariaDB, and MySQL.

🐘 PostgreSQL as a Relational Database

PostgreSQL gives me practically everything I expect from a mature relational database.

That includes:

• 🔒 ACID Transactions

• 🔗 Foreign Keys

• 🛡️ Constraints

• 🔀 Joins

• 🧠 Common Table Expressions

• 🔍 Advanced Indexing

• 📊 Window Functions

• 🧩 Rich Data Types

These capabilities allow me to build a clean data model while enforcing important rules directly inside the database.

That last point matters.

If a relationship between two records must exist, I don't want to rely exclusively on my Java application to guarantee it.

Even good application code can contain bugs.

For me:

Data integrity also belongs in the database.

Application-level validation and database-level integrity are not competing concepts.

They complement each other.

🧩 JSONB — Relational Structure With Flexibility

PostgreSQL isn't limited to traditional relational data.

One of the best examples is JSONB.

JSONB allows semi-structured JSON data to be stored directly inside PostgreSQL.

But the important part is that the JSON isn't simply stored as an opaque text string.

PostgreSQL allows me to:

• 📦 Store JSON documents

• 🔍 Query JSON data

• ⚡ Index JSON data

• 🔗 Combine JSON with relational data

That creates an interesting middle ground.

I can use relational structures where consistency and relationships matter while still retaining flexibility where the data does not fit perfectly into a rigid schema.

Conceptually:

Relational data when structure matters.

JSONB when flexibility matters.

That means I don't immediately need to introduce another database technology simply because part of my data is semi-structured.

Every additional technology has an operational cost.

If PostgreSQL can solve the problem cleanly, keeping the architecture simpler can be the better decision.

📊 Window Functions for Financial Data

Another PostgreSQL capability that is particularly useful for my platform is support for SQL window functions.

A window function performs calculations across multiple rows without collapsing those rows the way a traditional GROUP BY aggregation does.

That distinction is extremely useful for historical financial data.

Imagine a table containing one stock price for every trading day.

Using window functions, I can calculate:

• ⏮️ Previous Trading Day Price

• 📈 Daily Price Changes

• 🏆 Rankings

• ➕ Running Totals

• 📉 Moving Averages

Functions such as:

LAG()

RANK()

SUM() OVER()

AVG() OVER()

make these types of analytical queries possible directly inside SQL.

The important part is that every individual price record can remain in the result set.

For financial analytics, this is extremely powerful.

Window functions are not proprietary PostgreSQL technology.

They are part of the SQL standard and are supported by other modern relational database systems as well.

But they are an excellent example of the sophisticated SQL capabilities I want from my primary database.

☕ PostgreSQL With Spring Boot, Hibernate and JPA

My backend is built with Spring Boot.

For persistence, Hibernate and JPA provide an abstraction layer between the Java application and the relational database.

That gives me a clean application architecture.

Conceptually:

Spring Boot → Hibernate / JPA → PostgreSQL

JPA helps reduce direct database dependencies for many standard persistence operations.

But there is an important distinction.

JPA does not magically make the entire persistence architecture database-independent.

Once I deliberately use PostgreSQL-specific capabilities such as:

• JSONB

• Specialized indexes

• PostgreSQL data types

• Extensions

• Database-specific SQL

I increase my dependency on PostgreSQL.

And that's not necessarily a problem.

🔒 Vendor Lock-In Is a Trade-Off

Vendor lock-in is often treated as something that should always be avoided.

I don't see it that way.

Almost every serious technology decision creates some form of dependency.

The same applies to:

• PostgreSQL

• Oracle Database

• SQL Server

• MariaDB

• MySQL

• Cassandra

• MongoDB

The more database-specific functionality I use, the more work a future migration may require.

For me, the important question is therefore not:

Can I eliminate every dependency?

The better question is:

Am I receiving enough technical value in return for accepting that dependency?

If PostgreSQL-specific functionality solves real problems in my architecture, deliberately using those capabilities can be a perfectly reasonable engineering decision.

Choosing a powerful database and then restricting the entire architecture to the lowest common denominator across every possible database isn't automatically good architecture either.

The dependency should simply be understood and accepted consciously.

📜 Licensing Is an Architecture Requirement

Database comparisons often reduce licensing to one line in a feature table.

For me, it deserves more attention.

If I'm building a platform that may exist for many years, I want to understand:

• How can I use the technology?

• Can I modify it?

• How can I integrate it?

• Can I use it commercially?

• What restrictions exist?

• What long-term dependencies am I creating?

Licensing is therefore not just a legal footnote.

For me, licensing is a non-functional requirement of the architecture.

🔓 The PostgreSQL License

PostgreSQL uses the PostgreSQL License.

It is a highly permissive open-source license.

Its philosophy is similar to BSD- and MIT-style permissive licensing.

For a long-term software project, that gives me considerable freedom regarding:

• Usage

• Modification

• Integration

• Distribution

• Commercial applications

The license alone would never be enough for me to select a database.

Technical suitability comes first.

But when a database meets my technical requirements and simultaneously provides significant licensing freedom, the combination becomes very attractive.

🆚 What About MariaDB?

Could MariaDB run my platform?

Absolutely.

MariaDB is an established relational open-source database.

It supports:

• Tables

• Relationships

• Transactions

• Joins

• Indexes

• Constraints

A significant part of my platform could probably run on MariaDB without major problems.

I'm not going to pretend MariaDB is a bad database simply to make PostgreSQL look better.

It isn't.

MariaDB would be a technically valid choice for many of my requirements.

But if I'm free to choose today, I prefer PostgreSQL.

🧰 Why I Prefer the PostgreSQL Toolbox

PostgreSQL provides a broad technical toolbox.

That includes:

• Advanced SQL

• JSONB

• Multiple indexing strategies

• Rich data types

• Window functions

• Extensions

• Mature transactional capabilities

I know what my platform requires today.

I don't know every requirement it will have three or five years from now.

That makes flexibility valuable.

I don't want to introduce unnecessary technologies prematurely.

But I do want my primary database to give me enough technical room to evolve the architecture.

PostgreSQL does that very well.

📜 PostgreSQL License vs. MariaDB GPLv2

MariaDB Server is licensed under GPL version 2.

GPLv2 is a genuine open-source license.

But it represents a different licensing philosophy.

GPL is a copyleft license.

That does not mean a Spring Boot application automatically becomes GPL simply because it communicates with a MariaDB database.

That would be an incorrect oversimplification.

However, when I'm free to select a technology for a new long-term platform, I personally prefer the permissive PostgreSQL License.

It provides the licensing flexibility I want for future usage, integration, and distribution.

For me, that is part of the overall architecture decision.

🐬 What About MySQL?

MySQL is another obvious candidate.

Technically, MySQL is an extremely mature relational database system.

It has powered enormous numbers of production applications for decades.

Claiming that MySQL isn't technically capable would make no sense.

The MySQL Community Edition is open source and GPL licensed.

But my decision involves more than technical functionality.

MySQL is developed and controlled by Oracle, while commercial MySQL offerings exist alongside the Community Edition.

That introduces another consideration:

Governance.

When several databases can satisfy my technical requirements, I also look at who controls the project and what long-term strategic dependencies I am accepting.

When I compare those factors, I personally prefer the PostgreSQL model.

📈 What Happens When the Platform Grows?

Choosing PostgreSQL doesn't mean ignoring scalability.

But scalability should be approached incrementally.

Before fundamentally changing the database architecture, there are many things I can do.

1. Optimize Queries

Poor queries can create performance problems long before the database technology itself becomes the bottleneck.

2. Improve Indexes

Correct indexing can dramatically change query performance.

3. Introduce Caching

Not every request needs to reach the primary database.

4. Scale Vertically

More CPU, memory, and faster storage can take many systems surprisingly far.

5. Use Read Replicas

Read-heavy workloads can be distributed.

6. Partition Data

Large datasets can be divided into more manageable structures.

7. Extract Specialized Workloads

If a particular workload eventually requires a different technology, it can be moved into a dedicated service later.

The architecture can evolve when the requirements justify that evolution.

⚠️ Technical Complexity Is Never Free

This is one of the most important principles behind my architecture.

Every additional technology has a cost.

Another database means:

• More Operations

• More Monitoring

• More Backup & Recovery

• More Security Considerations

• More Deployment Complexity

• More Observability

• More Specialized Knowledge

• More Potential Failure Modes

So I don't try to solve today every scalability problem my application might theoretically have someday.

I don't want to pay for scalability with complexity when I don't actually need that scalability yet.

If the requirements fundamentally change, the architecture can evolve.

Build for the requirements you have — while leaving room for the requirements you may have tomorrow.

✅ PostgreSQL Against My Requirements

So how does PostgreSQL perform against what my platform actually needs?

PostgreSQL covers practically every major requirement I currently have for my primary data store.

There isn't one single killer feature.

It's the combination.

🏗️ Part of a Larger Architecture

PostgreSQL isn't my entire platform.

It is one component of a larger architecture.

My platform combines:

• 🎨 Angular — Frontend

• ⚙️ Spring Boot — Backend & APIs

• 🔑 Keycloak — Authentication & Authorization

• 🐘 PostgreSQL — Primary Data Store

• 🌐 Traefik — Reverse Proxy

• 📝 Contentful — Structured Content

• 🐳 Docker — Container Platform

• 🚀 Jenkins — CI/CD

Every technology has a specific responsibility.

The interesting part isn't simply using these technologies.

It is understanding why each technology is there and how the components work together.

That is what this engineering series is about:

Building a production-ready platform step by step.

🎬 Related Video

Why I Chose PostgreSQL Over MySQL & MariaDB for My Platform

In the accompanying video, I explain the complete reasoning behind my database decision.

The discussion includes:

• PostgreSQL vs. MariaDB vs. MySQL

• ACID transactions and data integrity

• JSONB

• Window functions

• Hibernate and JPA

• Vendor lock-in

• Database licensing

• PostgreSQL License vs. GPLv2

• MySQL governance

• Database scalability

• Operational complexity

• Long-term architecture decisions

This isn't a PostgreSQL tutorial.

It is a discussion about how I make a real database architecture decision for a real software platform.

🔮 Beyond Relational Databases

So far, this discussion has deliberately focused on relational databases.

But PostgreSQL, MariaDB, and MySQL are only one part of the database landscape.

Systems such as Apache Cassandra and MongoDB approach data from fundamentally different perspectives.

That raises a much more interesting architectural question than simply:

SQL or NoSQL?

The better questions are:

What does the workload look like?

What consistency guarantees are required?

How should the data be distributed?

What scale is actually necessary?

What trade-offs are acceptable?

Understanding why you would choose Cassandra or MongoDB instead of a relational database deserves its own discussion.

That will be the subject of another video.

✅ Conclusion

PostgreSQL is not the best database in the world.

There is no such thing.

I chose PostgreSQL because it fits the architecture I'm building today:

Technically.

Operationally.

Strategically.

The database decision didn't start with PostgreSQL.

It started with the problem.

What kind of data do I have?

What relationships exist?

What guarantees do I need?

What queries will I run?

How much operational complexity am I willing to accept?

What dependencies am I creating for the future?

Answer those questions first.

Then choose the technology.

For my platform, that decision led me to PostgreSQL.

For another system, the answer could be completely different.

Start with the requirements. Understand the trade-offs. Choose the technology for a reason.