PostgreSQL Database Choices : Shared vs Separate for Microservices

In the ever-evolving realm of Microservices, one of the fundamental decisions developers face is whether to adopt a shared database model or opt for separate databases for each service. This blog aims to dissect both approaches, offering insights to help you navigate this critical decision with confidence

Shared Storage Space

Imagine a giant storage room where all your Microservices “live” together. Sounds convenient, right?

Here’s the upside:

Less Cleaning Up: Managing just one storage room means less work

Reliable Data: Special features keep your data dependable, like everyone following clear rules!

But there are some downsides too:

Scheduling Headaches: Services become dependent on each other, making changes tricky and maintenance difficult

One-Size-Fits-None: The same storage room might not be perfect for everyone’s needs (some services might need a lot of storage space, while others might be fine with a smaller area)

Separate Storage Spaces: Freedom with Responsibilities

Now each service has its own little storage space. This offers some perks:

Independent Service Stars: Services can develop, update, and grow on their own schedule

The Perfect Fit: Choose the ideal “storage bin” (database type) for each service (like a big one for user data and a smaller one for post comments)

But freedom comes with chores:

More Spaces, More Cleaning: Managing multiple storage spaces is a lot of maintenance 

Keeping Things Tidy Across Spaces: Ensuring data stays consistent across separate spaces can be messy (like making sure everyone cleans up after themselves)

SQL Example: Shared Storage Space

Let’s see how this works with a social media platform using a shared storage space (database). Imagine separate services for users (UserService) and posts (PostService):

-- Shared Database

CREATE DATABASE "SocialMediaDB";

-- Using the SocialMediaDB storage

connect "SocialMediaDB";

-- User (UserService)

CREATE TABLE "Users" (
  "UserID" INT PRIMARY KEY,
  "Username" VARCHAR(50),
  "Email" VARCHAR(50),
  "Followers" INT
);

-- Post  (PostService)

CREATE TABLE "Posts" (
  "PostID" INT,
  "UserID" INT,
  "Content" TEXT,
  "Timestamp" TIMESTAMP,
  FOREIGN KEY ("UserID") REFERENCES "Users" ("UserID") -- posts are linked to users
);

In this example, the Users and Posts tables live in the same SocialMediaDB storage room. The Posts table has a special key that connects it to the Users table, ensuring data consistency (a post must be linked to a valid user)

Separate Storage Spaces and the Data Pipeline

With separate storage spaces, the PostService needs a way to access user information from the UserService space.

This can involve “data pipelines” to keep things organized:

Calling Neighbors: PostService could call an “API” provided by UserService to get user data

Sharing News: Services could send alerts whenever data changes, allowing others to update their own data accordingly

Finding Your Storage Space Sweet Spot

So, shared or separate? It depends on your project! Here are some tips to find the perfect fit:

Clear Cabinet Rules: Even with a shared storage room, clear rules ensure everyone respects each other’s space (like having personal belongings labeled)

Separate Desks, Shared Utilities: While having separate workspaces is nice (separate schemas), core functionalities shouldn’t be affected (shared core data model)

Needs, Not Trends: Don’t choose an approach based on popularity. Pick what works best for your project (consider factors like data size, how often data is accessed, and your team’s experience)

Conclusion

Choosing between shared and separate storage spaces for your Microservices is a crucial decision. By understanding the advantages and disadvantages of each approach, as well as considering your project’s specific needs, you can make a well-informed choice that sets your project up for success.