Every Project Is a Data Problem(Local Storage Is How We Pretend It Isn’t)

2026-01-14

Intro - Premature moment of joy

Every project starts the same way. You have an idea. You build the idea. You build the user interface You have a button that does something useful.

The data is there.

Sucess. Job Done.

For a lot of software, that's technically sucess. Most applications are, at their core, just CRUD containers.

Create > Read > Update > Delete

If those four things work, the app "works".

But thats just the icing on the cake, it doesn't tell you whether the cake is edible.

Learning V Reality

When you begin learning databases it feels very academic.

• Data Modelling
• Entity-Relationship Diagram (ERD)
• Entities and Attributes
• Primary Keys
• Table Relationships
• Normalisation
• Relational Data Modelling

You learn databases through careful modelling and structures. You build software by solving problems in front of you.

But the moment you create data, it takes on a life of its own and demands to know:

• Who Owns this?
• How long should it live?
• What happens when its wrong?
• Whos allowed to touch it?
• What breaks if it changes?

You stop asking where did I store the data and Now this data exists what am I responsible for.

Once you’re thinking in those terms, the old question becomes impossible to answer:

What database should I use?

The database was never the real question.

Choosing a Database

I've tried several different data stores and whats important isn't how they worked but what they revealed.

SQLite

SQLite is a lightweight database that stores all its data in a single file. There's no seperate database server running in the background. The application reads from and writes to that file directly.

From a user's point of view, it behaves like a "real" database.

Strengths

SQLite is reliable and predictable:

• data belongs to one application
• data needs to be persistent between runs
• simplicity matters more than scale

Because everything lives in one place, it's easy to understand whats happening and where the data actually is.

Weaknesses

SQLite isn't designed for busy shared systems:

• lots of people need to use the data at the same time
• the database needs to live seperately from the application
• the project grows into a multi-user service

Experience

Most of my experience came through Django, where it's the default database. Its a good starting point to understand web apps without making a architecture decision. You can focus on building features and the data is already stored in a structured, consistent way.

Best Use Cases

• small web applications (contact forms, blog comments, basic user accounts)
• internal tools (admin dashboard, reporting tool, internal trackers on same machine or server)
• personal projects (learning apps or utilites skipping infrastructure)
• early-stage projects (prototypes or MVPs without shared access)

MySQL

MySQL is a server-based relational database. Unlike SQLite, the database runs as its own service, seperate from the application, and applications connect to it rather than accessing a local file.

Strengths

MySQL's strength is when data needs to be shared and is widely supported and available on most hositng platforms, making it a common choice in production.

• multiple users accessing the same data
• applications running on more than one machine
• data that needs to be central and always available

Weaknesses

• it needs to be installed, configured and maintained
• the database becomes a seperate dependancy
• changes to data structure require more care

Experience

Most of my experience as come throgh the way its hosted over its long-term functionality in experimentiation. Exploring different platforms and hosting methods I've touched on it, without forming fully completed web applications suitable for deployment.

Hosting Dashboards - phpMyAdmin

Local Development Installs - XAMPP, WAMP

Container-based setups - Docker

Managed Cloud Services - Amazon RDS, Google Cloud SQL, Azure Database for MySQL

No matter how it's hosted, MySQL is when data stops living inside the app and starts living in the greater environment.

Think of MySQL as The Final Boss By the time you reach it, the game is no longer a tutorial.You’re dealing with real users, real data, and real consequences.

Best Use Cases

• traditional web applications (content managed sites, e-commerce, business with user accounts and admin panels)
• multi-user systems (booking systems or shared dashboards)
• hosted apps with shared data (An app where multiple users need to see and update the same data, like bookings, orders, or shared records.)
• projects moving from local to production (A side project that worked locally during development but required a central database once it was deployed online.)

PostgreSQl

PostgreSQL is a server-based relational database, similar to MySQL, but more hands on. Rather than something mostly managed through hosting dashboards, PostgreSQL lives closer to your system. You install it, run it and interact with it directly.

Strengths

• strong data integrity and consistency
• clear, predictable behaviour
• well-suited to complex or evolving data

Weaknesses

• steeper learning curve
• less "set and forget" than some hosting setups
• changes tend to require more thought

Experience

Most of my experience has been managing directly on my system rather than via hosting dashboards.

Using command line becomes the way of interaction. Creating databases, running queries, inspecting data and managing changes.

You're not clicking around a UI with many features you may not use or understand. You're working directly with the database.

I have enjoyed this more, as it feels more controlled and closer to the system.

Best Use Cases

• applications with complex data models (Users, Roles, Permissions, Orders and Audit logs)
• projects where data integrity matters (Financial Transactions, app submissions, historical logs)
• systems that evolve over time (New Features added regularly- adding new user roles, workflows or reporting requirements)
• comfort working closer to the system (SaaS Backends, Internal platforms still ongoing development, long-lived products)

MongoDB

MongoDB is a non-SQL, document-based database. Instead of tables and rows, data is stored as flexible documents that can vary in shape.

It's often presented as a modern alternative to traditional relational databases, especially alongside JavaScript-heavy stacks.

Strengths

• data doesn't need a fixed structure upfront
• changes to data shape are easy early on
• works naturally with JSON-style data
• fast to iterate for frontend-driven projects

Weaknesses

• less structure means fewer guardrails
• data shape can drift over time
• relationships are harder to reason about

Experience

My exposure to MongoDB came mainly through the MERN stack. Pre-AI, it was heavily promoted as the shiny new option, especially in JavaScript-focused ecosystems. Since then, the focus has shifted toward tools and approaches that favour clearer structure. Things like PostgreSQL, SQLite, and platforms such as Supabase that build on relational foundations.

I found MongoDB harder to learn in practice. Managing data through route handling and hosted dashboards made it feel distant compared to databases I could interact with more directly.

The flexibility was obvious, but the benefits were less so at this stage. While learning, structure made it easier for me to reason about data and understand how systems fit together.

I expect I’ll come back to MongoDB later. It feels like a tool that makes more sense once your understanding of data, and when to relax structure, has matured.

Best Use Cases

• projects where data shape is highly variable (User generated content such as forms, surveys or profiles with changing fields)
• early-stage experimentation (prototyping without knowing data structure)
• applications prioritising felxibility over strict structure (content-heavy app or API such as CMS like system or feature-flag service)

Backend-as-a-service

Supabase and Firebase sit in a different category alogether. They're backend platforms, not just databases. Bundling data storage with authentication, file stroage and APIs.

Strengths

• authentication out of the box
• media storage for images and videos
• APIs generated automatically
• minimal setup to get something usable.

Weaknesses

• database becomes less visible
• data access is often routed through platform-specific logic
• behaviour can feel indirect or hidden

Experience

My experience with Firebase came mostly through learning mobile app development with React Native. WHile it made certain things easy early on, I ran into similar issues to MongoDB. Data access being heavily tied to routing and platform-specific patterns taht made it harder to reason about. Now more matured as a developer I can see the benefits I missed first time round.

Supabase felt more approachable. It's heavily recommended now alongside AI-assited development. The PostgreSQL foundation makes the data model easier to understand. Even with added services layered on top, th eunderlying structure feels familiar.

Best Use Cases

• apps that need authentication quickly (startup MVP or internal tool with authentication)
• projects with image or video storage
• rapid prototyping and demos (proof of concept or demo)
• teams that want backends without building them (small teams or solo developers focusing on frontend or product features)

So, Where does local storage fit?

Local storage is the cheat.

And that's not an insult, it's the point.

Local storage wih when you aren't ready to answer questions about ownership, lifespan, or correctness. When you want something to just work.

It lets you:

• move fast
• avoid infrastructure
• skip commitment
• reset without consequence

Early, on thats exactly what you want. It makes todays problem, tomorrows feature. Everything is disposable and easy to undo. Find the issues early.

It only becomes an issue and liability when the data needs to:

• survive changes
• be trusted
• be shared
• mean the same tomorrow as it does today.

Closing Thoughts

Every project is a data problem.

Some just delay admitting it.

Learning databases teaches you how data should look. Building software teaches you how data actually behaves.

Local Storage is how we pretend that we don't need to know where data lives and can figure out what responsibilty do we have with it

Build it First. Figure it out Second. Secure before sharing.