GuidesOnly show guides for your app
GuidesGuidesFour database shapes, one honest chooser. Match your data to key/value, single-file SQL, managed SQL, or documents — and know why on Falix "where it runs" matters as much as "what shape it is".
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 |
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.
Before you even think about shape, answer these — they rule options out fast:
/home/container and share your server's fate. See Keeping apps online.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.
| 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 |
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.
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.
The shapes combine, and good setups usually do:
💡 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.
| 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 |
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).