In every functioning application, there is a database, whether it is an eCommerce, movie, icon, chat, or health app you would need a database to hold records. Sometimes a database can even be used for the lightest application. But the art of choosing your database is where the role of an engineer comes in.
Developers often argue and boast about their database, which is fun but knowing your database, with their strengths and weaknesses is what makes you a developer. Today we're going to look at some databases and we will discuss how to choose the right database for your next project, without any further interruptions let's begin.
First I'd start with what a database is. Google described a database as an organized collection of data or a type of data store based on the use of a database management system. To make you understand it better, a database is a collection of organized data.
Think of a database as a locker full of records of stuff you love, or your favorite movie.
Databases are used in every application you use on a daily basis. Imagine clicking on save to save your file or going to YouTube to watch a video, right? Well without a database all those won't be possible, no 1. You can't save your file without a database, and YouTube can't store billions if not trillions of videos without a database. Okay, we understand what a database is now, let me walk you through choosing the right database for your next application.
When it comes to picking the right database a lot has to be put into consideration, it takes long planning and engineering work. Let me walk you through a list of plans I made when choosing a database.
Understanding Your App's Requirement.
In order to have a database you need to understand your app, ask yourself these four questions
- Would I need to scale this on a daily basis?
- How many users do I have right now?
- How many users would I be expecting for such an app?
- Who is this app for?
Once you're done asking yourself these questions now let's move to the plan.
Database Structure: Evaluate the nature of your data. Is it relational or non-relational? MongoDB with its flexibility, is great for non-relational data, while databases like PostgreSQL excel in handling relational data.
Scalability: Another thing to consider is the scalability requirements of your app. Will it experience significant growth in users? MongoDB's horizontal scaling makes it a strong contender for applications with scalability demands.
Query Complexity: Now consider complex queries... Access the types of queries your app will frequently perform. Some databases, like MySQL, are optimized for complex queries, while others like Redis are designed for quick key-value lookups.
Now that you've understood your app's requirements, there are many more things we need to address like the elephant in the room which is performance. Ah, we all hate it when we open an app or try to perform a search and it takes like up to 4hours to query and retrieve our data. Performance is a great one to look at, so let's address that right now.
Performance Metrics
In performance metrics, we have two lists to look at here, which are read and write speeds and latency tolerance. These two keys play a valuable role in a database. Let's dive in.
Read and Write Speeds: We all know MongoDB is known for its fast write speeds, making it suitable for write-intensive applications. On the other hand, databases like Redis shine in read-intensive scenarios.
Latency Tolerance: If your app requires low-latency data access, you should probably consider databases like Cassandra, designed for distributed, low-latency environments.
Okay, we've dealt with performance metrics, yikes that was some spicy one, but do take time to do your own research and find out everything about your database, we will move on to deployment and maintenance.
Development and Maintenance
Is it easy to deploy and maintain, that's a great question you should ask yourself before choosing a database, most databases are even more complex to set up in a production environment than development, while some are very easy, databases like MongoDB, PlanetScale, Redis, ScallaDB, Firebase Firestore, Supabase PostgreSQL database are easy to setup.
Another thing to put into consideration is, whether is it easy to maintain, what can you do when things start to get rough, when you start experiencing high spikes, and what can you do, you should ask yourself these questions.
Another important subject to note is to choose a database with a driven and active community, you don't want to choose a database only to find out no one is using it, what then would you do when you face issues, who would you ask questions?
Security and Compliance
Always use a secure database, choose a database that is up-to-date with the latest security updates, and so on. Don't say because because of SQL injection is why you are going for NoSQL like MongoDB, The funny thing someone can still exploit a malicious attack on your MongoDB database. Always watch out and keep yourself up to date.
Conclusion
So yeah that's it, make sure to take your time, and do your research before choosing a database for any application you want to build.
Handles
const getSocials = () => {
return {
X: "https://twitter.com/timi_networks"
Linkedin: "https://www.linkedin.com/in/treasure-alekhojie/"
}
}
console.log(getSocials())
Top comments (7)
1) All data is relational, that's what makes it data. The question is really about whether you need to store it in different tables with a relational key (order header, order lines with a common order ID) or in a nested structure
{orderID: 1,
customerID:9876,
orderdate:2023-11-09,
lines: [
{
lineNumber:1,
itemcode:ABC123
},
{
lineNumber:2,
itemcode:DEF456
}
]
}
The order document above makes noSQL database reads very fast across the order, but if you want to aggregate data about items you have to scan the entire order collection or save the data in multiple formats. With the data in a RDBMS (SQL database) it is much easier to navigate in any direction (e.g. by customer, item, item type, geography or timeslice) the reads are more complicated to craft but data storage is smaller by a significant factor as you don't need to store the key names as well as the values
2) unless you know that your app is going to generate huge amounts of data (like millions of rows of a day) I would not worry about scalability at start up as most databases will scale to a fairly considerable level. More relevant might be the ability to replicate and co-locate the database in multiple regions or quicky scale up the available compute if you have temporary spikes (e.g. release date for Taylor Swift tickets) . Even when it does generate huge amounts of data, there are techniques you can employ to write data quickly into document storage and then process it into relational storage later.
Thank you for noting that
typo in the header graphics: "datatase"
"I appreciate you bringing that to my attention. I will work on fixing it promptly."
Remove the quotes from your ai-generated responses 😀
Lol
Thanks for sharing💞