How Do You Persist Kanban Board State Across Sessions Using a Proper Database Schema Instead of a JSON Blob?

When you first make a Kanban board persist, the tempting shortcut is to dump the whole board as one JSON blob in a single database field. It works at first, but it is fragile and does not scale. A proper schema, real tables for boards, columns, and cards with relationships between them, is what makes the state robust, queryable, and safe. Here is how to persist Kanban board state with a proper database schema instead of a JSON blob, and why the extra structure is worth it.

The JSON blob temptation

The blob approach is seductive because it is easy. You serialize the entire board, columns, cards, and all, into JSON and save it in one field, then load and parse it back when needed, with no schema to design. For a quick prototype it feels efficient, one field, one save. That simplicity is exactly why people reach for it. Understanding the appeal is fair, but the ease is front-loaded, and the problems show up as the app grows. The blob is the path of least resistance, which is not the same as the right path.

Why the blob is fragile

The JSON blob breaks down in several ways. You cannot query inside it, find all cards assigned to someone, without loading and parsing the whole thing, updating one card means rewriting the entire board, and two simultaneous saves can overwrite each other, losing data. There is also no integrity, nothing stops a malformed board. These limits make the blob fragile as soon as the app is real. The convenience hides serious weaknesses. A blob that works for a demo becomes a liability the moment you need to query, update precisely, or handle real use.

What a proper schema looks like

A proper schema breaks the board into related tables. A boards table, a columns table, and a cards table, each row a real entity with its own fields, replaces the single blob with structured, queryable data. Each card is its own row, each column its own row, linked to their parents. This is standard relational design, and an agent can set it up in SQLite easily. The schema turns an opaque blob into transparent, structured storage. Separate tables for the board’s parts are the foundation of robust persistence.

Relationships and foreign keys

The tables connect through relationships. A column belongs to a board and a card belongs to a column, expressed with foreign keys that link each row to its parent, so the database understands the structure rather than treating it as opaque text. These relationships enforce that every card has a valid column and every column a valid board, giving you integrity the blob cannot. Foreign keys are what turn separate tables into a coherent board. The relationships are what make the schema more than just three lists, they encode how the board actually fits together.

Handling card order

Kanban cards are ordered within a column, and a schema handles this cleanly. Giving each card a position or order field lets you store and change its place in the column with a simple update, rather than rewriting a whole ordered array as the blob would require. Moving a card becomes updating its column and position, one small, precise change. Handling order explicitly is a place the schema clearly beats the blob. A position field is how a relational board keeps its cards in the right sequence without rewriting everything on every move.

Why the schema wins

The schema’s advantages are decisive as the app grows. You can query precisely, find, filter, and count cards without loading the whole board, update a single card without touching the rest, rely on integrity to keep the data valid, and handle concurrent changes safely. These are exactly the things the blob cannot do. The structure that costs a little more up front pays off in every direction later, which is why real apps use schemas. The schema wins on queries, precise updates, integrity, and concurrency, everything that matters once the board is real.

Migrating from a blob

If you started with a blob, moving to a schema is a worthwhile migration. Designing the tables, then writing code to read the existing blobs and insert their contents as proper rows, converts your data without losing it. An agent can help write this migration, and doing it early, before the blob’s problems bite, is easiest. Migrating from blob to schema is a normal step in an app maturing. The sooner you move off the blob, the less data and code you have to convert. A one-time migration buys lasting robustness.

Let the agent design it, then review

An AI agent can design a solid schema quickly, but review it. Asking Copilot or Codex to propose tables for the board, columns, and cards with sensible relationships gives you a strong starting point, and then reviewing the schema, checking the relationships, fields, and constraints, is essential, since data structure is hard to change later. Getting the schema right early matters more than most code. Let the agent draft it, then scrutinize it carefully, applying sound API and data design judgment. A reviewed schema is a foundation you can trust.

Wiring the schema to the API

Finally, connect the schema to your endpoints. Having the back-end read and write these tables through your REST API, so creating a card inserts a row and moving one updates its column and position, is what makes the board persist correctly across sessions. Each API action becomes a precise database operation rather than a whole-board rewrite. Wiring the schema to the API is what turns structured storage into a working, persistent board. The endpoints and the schema together give you a Kanban app whose state is robustly saved and correctly updated every time.

The takeaway

Persisting a Kanban board as one JSON blob is tempting but fragile: you cannot query inside it, updating one card rewrites the whole board, concurrent saves clobber each other, and there is no integrity. A proper schema, separate tables for boards, columns, and cards, linked by foreign keys with an explicit position field for card order, fixes all of that, giving you precise queries, safe single-card updates, data integrity, and concurrency. Let an agent design the schema in something like SQLite but review it carefully since data structure is hard to change, migrate off any existing blob early, and wire the schema to your REST API so each action is a precise operation. The extra structure is what makes the board’s state genuinely robust across sessions.

Common questions