Heads up! This blog post hasn't been updated in over 2 years. CodePen is an ever changing place, so if this post references features, you're probably better off checking the docs. Get in touch with support if you have further questions.
With CodePen being a front-end environment, of course, you can use things like localStorage or indexedDB to store data. You know, data that will be there even if the page refreshes. But that data is only for the one person looking at your creation, it’s not data stored in some permanent database that persists across time and sessions and all that.
Need that? There are plenty of options.
Firebase
Firebase has two things that are mighty appealing to CodePen users. One is easy authentication entirely client-side, so you can get going with secure (and user-based) data storage with no middleman. Two is that the data storage can be real-time in that you can not only store and retrieve data but react to changes in that data should it happen anywhere else. Kitt Hodsden wrote quite a robust intro article on building a blog (read & write) with Firebase.

Webtask
Webtask‘s primary function is a clean little UI for creating cloud functions. That’s useful for all sorts of things, and data storage is one of them. Webtask could be your middleman for data storage anywhere, but has its own simple 500KB data store if that’s enough for you.

Code.xyz
Speaking of cloud functions, Code.xyz is a lot like Webtask in that it allows you to create cloud functions easily with their in-browser editor. They pitch it as “building APIs”, which is essentially what you are doing. This could be your middleman for communicating with any other data storage tool, for example, MongoDB.

JSONBin
Dump some JSON in JSONBin, save a Bin, and get CRUD (Create Read Update Delete) APIs for all of it.

n:point
You can drop your JSON in n:point, but additionally, you can create a schema that enforces the structure of that JSON, so you can’t change the data and screw things up. It has read APIs, including sub-property access so you don’t have to load everything, but no write APIs yet.

Google Sheets
Did you know you have programmatic API access to your spreadsheets in Google Docs? It requires OAuth and doesn’t look particularly friendly to get started with, but it’s free and there are tons of people that use and are comfortable in Google Sheets. Very worth noting is Sheetsu, which connects your Google Sheets to your websites in much friendlier and interesting ways and Sheetbase for an abstracted/simplified API. There is also Sheet2site which is more of a site builder that uses a Google Sheet for all the content.

Fieldbook
Fieldbook is like a modern take on spreadsheets with the idea that the spreadsheets you make are powerful databases also. Tabledo is an example of a site builder tool on top of Fieldbook like Sheet2site is for Google Sheets. The reason for pointing it out here is that your Fieldbook spreadsheets have full featured CRUD API’s for your data.

Airtable
Airtable is probably the biggest fanciest player in the data storage with nice UI category. Their tag line is even “Looks like a spreadsheet. Acts like a database.” Spreadsheets in Airtable are incredibly nice and intuitive UI features like table cells that can be select menus, or files, or displayed with powerful filters. And listed here of course because you can use their APIs to access and change all that data. We’ve podcasted about Airtable before.

Remember with any of these services in which that you need API keys, using cloud functions is the way to interact with them to protect those keys. That’s why we put in services like Webtask and Code.xyz.