One of my customers is trying to vibe code an ancestry website for his tribe — a directory of famous people in the tribe's history. And he asked me how to add a database to his website — essentially a CMS for adding famous people in history from the tribe.
The first question I asked: “But do you really need a database?”
Let's be honest about vibe coding nowadays. 80% of projects will never ship. 90% of projects will not get any meaningful traffic. And the last 10% — most of them will get modest traffic in the near term (or long term). The truth is, getting a real database, such as PostgreSQL or Supabase, is almost always over-engineering for 99% of new vibe coded projects.
Hosting a separate database is not only costly, but also makes your project harder to maintain and change. You will need to take care of DB schema changes. One thing I do not trust AI to do is managing schemas. And your feature requests keep changing, your DB schema gets migrated again and again, and at some point you might have to choose between wiping old data and dev speed.
As an engineer, I'd like to share what the realistic options are for vibe coders, so that you can save your money and build faster for your new ideas.
Below is a list of database options from simple to complicated.
Rule of thumb: you should always start with the simplest solution that meets your product requirements.
JSON File
JSON (JavaScript Object Notation) is a lightweight data format that can represent lists, trees, and nested structures. Even though it looks simple, it is perfectly fair for your project to store thousands of records in a JSON file, without the need for a database. Suitable for directories of info, music albums, a fixed list of items. The performance overhead of downloading a 10K-entry JSON is less than half a second, which is okay for most side projects to start with.
Not suitable:
- •If you need to keep updating the data, like adding items frequently
- •If you have more than 10K entries — you'll need to benchmark your website performance
SQLite
SQLite is an embedded, minimal version of a SQL database. It can do almost everything a regular SQL database can do, but you don't need to host a separate database instance, as it runs as part of your website server with little overhead. If your business has at most 2 bookings per day, SQLite is more than enough — it can support ~5,000–50,000 writes/sec. For most side projects, that kind of traffic is already a success story.
95% of non-engineer vibe coders should stop at SQLite and not start with the fancier solutions listed below.
Not suitable:
- •If your data records truly explode — then congrats, that's a good problem to have
- •You need some fancy features from PostgreSQL, e.g. pgvector for vector search
Firebase
Firebase is a NoSQL database. Key takeaway: there is no schema to define, so you have maximum freedom to change your data structure. For most non-engineer vibe coders, this is neither an advantage nor a disadvantage — it can basically do anything that a SQL database would achieve for you.
The setup of Firebase is way simpler than SQL databases, and you also don't need an ORM (Object-Relational Mapping — a tool that translates between your code and database queries) as a companion for it. It's also been battle-tested for the last decade, so you'll never need to worry about scaling and performance.
Not suitable:
- •If you do need complex JOINs across related data
- •If you worry about data migration to SQL when your product grows into a real giant in the future
CMS SaaS
I am still studying the CMS SaaS options at the moment — this section will be updated later.
Key takeaway: If you need a blog or want to keep updated records managed by yourself or your team, then a CMS SaaS is easier to set up and maintain than any of the database options above.
Supabase
Supabase is a Database-as-a-Service product. Basically, it hosts a real PostgreSQL instance for you. It has achieved huge success in the hype of vibe coding over the last 12 months and seems to be becoming the gold standard for vibe coding. With all respect, the truth is, your side project would probably never need to start with a real database. Supabase is so powerful that your project likely won't need it for the first 12 months, and you'd be wasting your money and CO₂ due to its overhead.
It is good at:
- •You probably will never need to migrate out of it, as it already meets all requirements for almost all projects
- •A strong schema is good for most side projects
RAG
RAG (Retrieval-Augmented Generation) is the foundation of fancy searching against your private data. If you want to create an AI chat over your private documents or data, then this might be the necessary stack you'll rely on. Technically, RAG by itself is not a database — it involves a vector database + LLM + a RAG framework.
If your documents' total size is quite modest (which is true for most people), then I suggest using Chroma. This is the easiest thing you can find to enable RAG.
If your documents' total size is growing fast, then LlamaIndex Cloud is easier for you. You can think of it as a CMS SaaS for RAG.
Host Your Own DB Instance (Never Do It)
You are not an engineer, even not every engineer are good at doing it. You are wasting your time. That is why all WordPress/Elementor projects are slow and heavy as crawling.
Don't let the hype pick your stack. Start with the simplest option that works, ship your idea, and only upgrade when real usage demands it. Your time is better spent building the product than managing infrastructure.
Need a landing page?
If you're looking for revamping your landing page, you can try Webjourney.
Try Webjourney