How do I store small bits of data without running a full database?
Short answer: For something genuinely small, a vote count, a simple cache, a one-off counter, you don't need a real database with tables, schemas and relationships. A key-value store, like Netlify Blobs used as a simple set/get mechanism, lets your site's own code read and write small pieces of data with almost no setup. The moment you need to filter, sort, search, or relate different pieces of data to each other, that's the actual signal you've outgrown this and need a real database, not before.
You want something simple, a counter, a tally, a small cache, and setting up and maintaining a full database for it feels like massive overkill, and you want to know what the actual lightweight option is.
I'm Ranjit, and I run Blur Studio: 15+ years building software, 120 apps taken live, and clients who have gone on to raise $10M+. I build AI systems and processes that help businesses do a lot more with a lot less time. I also work differently from most of what else is out there, more on that further down this page. Say hello.
This page may contain affiliate links from which Blur Studio earns commissions.
"I need a database" is often the wrong conclusion for a genuinely small problem. A database brings schemas, migrations, a connection to manage, and ongoing maintenance, which is a lot of infrastructure for something like "how many times has this button been clicked" or "which names are on this list right now." A key-value store does the actual job with none of that overhead.
What a key-value store actually is, in plain terms
Think of it as a very simple labeled-box system: you give each piece of data a label (the "key"), and you store a value under that label. Need the current count? Ask for the value under the key "counter." Need to update it? Write a new value to that same key. There's no table structure, no relationships between different pieces of data, just labeled boxes you can read from and write to.
Netlify Blobs works exactly this way and is accessible directly from your site's own code, with a handful of simple operations: set a value, get a value, list what's stored, delete something. For a counter, a simple voting tally, or a basic cache of recently fetched data, this genuinely covers the whole job.
A few practical things worth knowing before you build
- Concurrent writes to the same key are last-write-wins. If two people vote or update the same counter at nearly the same instant, whichever write lands last is the one that sticks, which can occasionally undercount if two updates happen in the same split second. For a casual counter or simple poll, this is rarely noticeable or important. For anything where an exact, guaranteed-accurate count genuinely matters, this is a real limitation worth knowing about upfront, not discovering after launch.
- Updates can take up to 60 seconds to show up everywhere under the default consistency setting, since data is cached at the edge for faster reads. A strong-consistency setting is available if you need every reader to see an update immediately, at a small cost to read speed.
- There's no filtering, sorting or searching built in the way a real database gives you. You can list everything in a store, but asking "give me only the entries from this week, sorted by value" isn't something a key-value store does for you; you'd fetch everything and sort or filter in your own code, which gets slow and clunky once you've got more than a small number of entries.
The spreadsheet option, and when it's actually better
A plain spreadsheet as your "database" is a genuinely valid option for very small, simple cases, and it has one real advantage a key-value store doesn't: non-developers can open it and read or edit it directly. If whoever needs to check or adjust this data isn't a developer and shouldn't need one just to glance at a number, a shared spreadsheet is friendlier day to day, even though it's less tidy from a pure engineering standpoint. The trade-off is that a spreadsheet gets unwieldy fast once you're dealing with real volume or need your site to react to changes quickly; it's genuinely great for low-volume, human-readable data, and genuinely bad for anything with meaningful traffic or complexity.
The moment you've actually outgrown this
You need a real database the moment any of these become true: you need to filter or search ("show me all entries from this customer"), you need relationships between different pieces of data (an order that connects to a customer that connects to a product), or you need guaranteed-accurate counts under real concurrent load, not last-write-wins. None of these are about scale alone; a small app with real relationships between its data needs a database even at low volume, while a huge, simple counter can stay a key-value store indefinitely.
What I'd actually tell someone building a small internal tool
I'd default to the simplest option that actually does the job and resist the urge to "do it properly" with a full database for something genuinely small, since the maintenance cost of infrastructure you didn't need almost always outweighs the tidiness of having used the "correct" tool. The honest test I use: can you describe what you're storing in one sentence without the word "and"? ("A vote count" is one thing. "A vote count and who voted and when and whether they're eligible" is actually several related things, and that's a database, not a key-value store, even if it still sounds small.)
A worked example: a contest entry counter that almost became a database prematurely
A small business running a simple social media contest wanted to display a live entry count on their website, "X people have entered so far," updating as new entries came in through a form. The developer they first consulted suggested a full database with a proper entries table, user records, timestamps, the works, treating it as a standard "store user submissions" build from the outset.
Stepping back and describing the actual requirement in one sentence revealed it was simpler than that: the website only needed to show a running count, not list, search or manage individual entries, since entry validation and prize fulfillment were already happening manually through a separate spreadsheet the owner already used. A single key-value counter, incremented each time the form submitted, did the entire visible job on the website at a fraction of the setup time a full database build would have taken. The spreadsheet handled the part that genuinely needed structure (who entered, contact details, prize eligibility), and the website only needed the one number everyone could see update in close to real time. Matching the tool to the actual requirement, rather than the requirement that sounded more official, saved a meaningful amount of unnecessary build time.
A practical note on combining a key-value store with a spreadsheet
These two lightweight options aren't mutually exclusive, and some of the simplest, most cost-effective small tools combine them: a key-value store for anything your website itself needs to read or update quickly, like the live counter above, and a spreadsheet for anything a human needs to review, adjust or act on directly. Trying to force one tool to do both jobs, a website-facing live number and a human-editable record, usually produces something clunkier than just using the right lightweight tool for each half separately.
How I'd approach this
When a client describes something that sounds like "just a simple counter" or "just a quick list," I always probe one level deeper: will this need relationships to other data later, even if not today? For the genuinely simple cases, setting this up directly through a Netlify account takes minutes, which is itself a sign you've picked the right-sized tool. A lot of "simple" tools grow one requirement at a time until they quietly need a real database, and it's much cheaper to build on the right foundation from the start than to migrate off a key-value store after the fact, once real data and real usage depend on it. If you've already built something this way and it's starting to strain, that migration is exactly the kind of project I help with.
Questions people ask
What's the difference between a key-value store and a real database?
A key-value store holds simple labeled pieces of data you can read and write directly, with no structure connecting different pieces to each other. A real database adds tables, relationships between data, and the ability to filter, sort and search properly, at the cost of more setup and ongoing maintenance.
Is a key-value store accurate enough for a real vote count?
For a casual poll, generally yes. Concurrent writes to the same key are last-write-wins, so two nearly-simultaneous updates can occasionally undercount by one. If an exact, audit-proof count genuinely matters, a real database with proper transaction handling is the safer choice.
Can I just use a spreadsheet instead?
For very small, low-volume, human-readable data, yes, and it has the advantage that non-developers can open and edit it directly. It becomes unwieldy once volume or complexity grows, so it's a good fit for simple cases, not a long-term substitute for a real database at scale.
How fast do updates show up with a key-value store?
Under the default consistency setting, updates can take up to 60 seconds to appear everywhere, since data is cached for faster reads. A stronger consistency option exists if you need every reader to see changes immediately, at some cost to read speed.
When should I actually move to a real database?
When you need to filter or search your data, when different pieces of data need real relationships to each other, or when you need guaranteed-accurate counts under real concurrent use. These are about the shape of your data, not necessarily about how much of it there is.
Does a key-value store let me search or filter the data?
Not built in. You can list everything stored, but filtering or sorting has to happen in your own code after fetching it, which becomes slow and awkward once you have more than a small number of entries. That's the clearest signal to move to a real database.