Falix gives you four ways to store data, and picking wrong makes everything after it harder. They aren't ranked — they're shaped differently, and the job is to match the shape to your data. This guide is the honest chooser: what each one is for, and the two Falix-specific questions ("does it survive a reinstall?", "can two servers share it?") that often decide it before the shape does.
| At a glance | |
|---|---|
| You need | Data to store, and a decision to make |
| Plan | Any |
| Pairs with | Add a database and Storing data for your bot |
The four shapes
Redis — key/value, in memory, temporary. A giant, extremely fast dictionary: set a key, get a key, and (its superpower) keys that delete themselves after a timeout. Perfect for cooldowns, rate limits, sessions, and cache — anything temporary or recomputable. Not a home for your only copy of anything. Runs as its own Falix application; used from Node or Python.
SQLite — relational, one file, no server. A real SQL database that lives in a single file next to your code. Tables, indexes, JOINs — everything relational — with nothing to run. Ideal for a single bot or app on one server. It lives in /home/container, so it's wiped on reinstall and can't be reached by another server. See SQLite in depth.
MySQL / PostgreSQL — relational, managed, durable. The same SQL shape as SQLite, but running on a separate always-on host that Falix keeps up. It survives reinstalls and application switches, and several servers can share it. This is the safe home for data you can't lose. Create one on the Databases page; connect from any language.
MongoDB — documents, managed, flexible. Stores JSON-like documents instead of rows and columns, so nested and varying data fits without a rigid schema. Also managed and durable, like MySQL/Postgres. Reach for it when your data is naturally document-shaped rather than tabular. Also on the Databases page.
The two Falix questions that come first
Before you even think about shape, answer these — they rule options out fast:
- Must the data survive a reinstall, an application switch, or the server sleeping on a free timer?
If yes, it has to be managed (MySQL, PostgreSQL, or Mongo). SQLite and any database you run yourself live in
/home/containerand share your server's fate. See Keeping apps online. - Does more than one server need the same data? If yes, it must be managed again — a SQLite file and a self-run engine are reachable only from their own server.
If both answers are "no" — one server, and a server backup is safety enough — SQLite is often the simplest good choice. If either is "yes", you're in managed-database territory, and the only remaining question is the shape.
🎯 Good to know: Redis sits outside this test on purpose. Because it's a cache, "does it survive?" doesn't apply — you're never meant to keep the only copy of anything there. Cache in front of a durable store, not instead of one.
The chooser
| Your data is… | Pick | Why |
|---|---|---|
| Temporary — cooldowns, sessions, rate limits, cache | Redis | Self-expiring keys, extreme speed; loss is fine |
| Structured with relationships, one server owns it | SQLite | Full SQL, zero setup, lowest latency |
| Structured, must survive reinstalls or be shared | MySQL / PostgreSQL | Managed, durable, multi-server |
| Nested/flexible documents, must survive or be shared | MongoDB | Schema-flexible, managed, durable |
MySQL vs PostgreSQL
Both are managed, durable, relational, and speak SQL. MySQL is the default and the most common — a safe first pick, and it's the only type with the phpMyAdmin browser button. PostgreSQL is stricter about types and richer in advanced features (JSON columns, powerful indexing). For a first project, MySQL; choose Postgres when you specifically want its features. Either way the driver pattern is the same.
Relational vs document (SQL vs Mongo)
Choose relational (SQLite/MySQL/Postgres) when your data is tabular and consistent — users have the same columns, and rows relate to each other (a user has many scores). Choose documents (Mongo) when records vary in shape or nest deeply, and you'd otherwise fight a rigid schema. Most bot and small-app data is tabular, so relational is the common default; reach for Mongo when the document shape genuinely fits.
You'll often use two
The shapes combine, and good setups usually do:
- Managed MySQL + Redis — the durable store holds users and scores; Redis caches hot reads and holds cooldowns. This is the classic web-app pairing.
- SQLite for a solo bot — one file, everything in it, a server backup for safety. Simplest thing that works, and it works well.
- Managed database + SQLite rarely mix in one app; pick one durable store and stick with it.
💡 Tip: Starting a bot and unsure? Begin with SQLite — it's the least to set up and your SQL carries straight over. If the data later needs to survive reinstalls or be shared, moving to a managed database is mostly a driver swap and the same queries. Storing data for your bot walks that exact path.
Everything side by side
| Redis | SQLite | MySQL / Postgres | MongoDB | |
|---|---|---|---|---|
| Shape | Key/value | Relational (SQL) | Relational (SQL) | Documents |
| Runs where | Your server (app) | A file in your server | Always-on host | Always-on host |
| Survives reinstall | No (it's a cache) | No | Yes | Yes |
| Shared by servers | Only its own | No | Yes | Yes |
| Best for | Temporary/cache | One-server structured data | Durable structured data | Durable flexible data |
| Setup | Run the app | Just a file | Create + connect | Create + connect |
Still unsure? Answer these in order
- Is the data throwaway or a cache? → Redis, done.
- Must it survive reinstalls or be shared between servers? → managed (go to 4).
- One server owns it and a server backup is enough? → SQLite, done.
- Tabular with relationships? → MySQL (or PostgreSQL for its extras). Nested/flexible documents? → MongoDB.
That's the whole decision. Whatever you land on, keep the connection details in .env (Environment variables and secrets) and back up what matters (Backing up your databases).