Seed Data

Under Schema → Seed Data, DB Studio keeps seed definitions: the rows a reference table should hold, such as statuses, countries or feature flags. A plan compares a seed with the table on a connection and produces the script, in the engine's own language, that brings the table to the seed.

Supported Engines

Every engine, each written in its own language. The engine and database always come from the connection you plan against.

• PostgreSQL (incl. CockroachDB, TimescaleDB), MySQL / MariaDB, SQLite, SQL Server and Oracle, INSERT, UPDATE and DELETE statements on the table.
• Apache Cassandra, the same in CQL; the key columns should be the table's primary key, because CQL updates and deletes rows by their primary key.
• MongoDB, the table is a collection: insertOne, updateOne with $set, and deleteOne.
• Redis, the table is a key prefix and each row a hash under prefix:key (several key columns join with :): HSET and DEL. A key under the prefix that is not a hash stops the plan, and a value holding a line break cannot be written.
• Neo4j, the table is a node label: CREATE, MATCH ... SET and MATCH ... DETACH DELETE.
• Elasticsearch, the table is an index and documents are identified by _id, which must be the only key column: index, update and delete operations, then a refresh. An index of more than 10,000 documents is not seeded.

Defining a Seed

• Name, unique among seeds, ignoring case.
• Schema and Table, where the rows belong; leave the schema empty for the connection's default (on MySQL / MariaDB the schema is the database).
• Mode, Insert only adds missing rows; Upsert also updates rows whose values differ; Sync also deletes table rows the seed does not list. The editor says under the choice what the chosen mode does. A Sync seed needs at least one row, because with none its plan would delete every row in the table.
• Key Columns, the columns that identify a row, separated by commas, such as id or (country, code).
• Rows, a JSON array of objects, one per row, each with a value for every key column and no two with the same key. A column a row leaves out is not touched.
• Engines, optionally, the engines the seed is for; with none chosen the editor says so, and the seed is for every supported engine.
• Active, an inactive seed is kept but cannot be planned.

The list shows each seed's mode and row count in words, such as Upsert · 2 rows. A seed that breaks one of these rules is not saved; the message lists every problem. The rows field starts empty, with an example as its placeholder. Deleting a seed asks first; it removes only the definition, not rows already applied to a table. If the server refuses, the message names the seed and gives the reason. On a wide screen the seeds are a table you can sort by clicking a column heading, or by moving to it with Tab and pressing Enter; each press sorts ascending, then descending, then back to the original order. On a narrower screen each seed is a card with the same actions.

How a Plan Is Built

A plan reads the seed's columns from the table and matches rows by the seed's key columns. Values are compared by what they mean: JSON by its content whatever the order of its keys, dates by their day, numbers by value, and booleans also against 1 and 0. Then:

• a seed row missing from the table becomes an INSERT;
• in Upsert and Sync mode, a row whose values differ becomes an UPDATE of only the columns that changed (Insert mode never updates);
• in Sync mode, a table row the seed does not list becomes a DELETE.

The SQL uses plain INSERT, UPDATE and DELETE statements, so the table does not need a unique key on the key columns. If the table holds a key more than once, the plan stops and names it, because an update could not tell those rows apart.

Planning and Applying

Choose Plan on a seed and pick a Connection; the picker lists only connections of an engine the seed applies to, each with its engine. If the engines cannot be loaded, Plan and the editor say so with Retry instead of offering nothing. Compute Plan counts what it would change, such as 1 to insert, 1 to update, 0 to delete, and shows the rows to insert, each row to update with its old and new values, and the rows to delete, followed by the SQL. A plan that deletes rows says so above the lists. Copy SQL copies it; Create Script saves it as a migration script for that connection, waiting for approval, which then runs through the usual approval and execution steps. The script holds the plan the server computed when you chose Create Script, and its description gives the seed, the mode and the counts.

Only an active seed can be planned; the Plan button of an inactive seed is disabled. A seed limited to some engines can only be planned against connections of those engines; planning it anywhere else is refused with the engines it applies to.

Who Can Do What

The buttons for actions your role cannot take are not shown. The full list of routes and error codes is in the Seed Data API reference, and each error is explained under Troubleshooting.