Glossary

Definitions of the key terms you'll see across the NeoSQL docs and UI, gathered in one place.

Project Types

Account Project: A collaborative project whose ERD and SQL definitions sync in real time through the cloud. Local and server state sync bidirectionally so teammates' changes appear automatically; sign-in is required. Use the desktop app when you also need direct access to an external database.
Local Project: A desktop-only project that stores all of its data on this PC alone. It never syncs to a server, so it works without signing in, and account features such as sharing, member roles, and DDL approval are not available. Converting a local project into an account project is not supported.

ERD & Schema

ERD (Entity Relationship Diagram): A visual diagram of the database's tables, columns, and relationships. NeoSQL builds table design, forward-apply, and reverse engineering workflows around the ERD.
Forward Engineering (Apply to DB): Converts the table, column, and relationship definitions in the ERD into DDL and applies them to the real database. Covers both initial creation and incremental changes.
Reverse Engineering (Import): Reads table structures and relationships from an existing database or DDL file and turns them into an ERD automatically. The imported ERD can be edited and applied back to the database just like any other ERD.
DDL Import: Turns CREATE TABLE, ALTER TABLE, and CREATE INDEX statements into ERD tables by pasting the DDL or dropping a .sql / .txt file. It gives you the same result as reverse engineering without connecting to a database; tables whose names already exist in the target schema are excluded from the import.
Identifying · Non-Identifying Relationship: The two foreign-key models you can pick when drawing a relationship. In an identifying relationship the parent's PK becomes part of the child's PK, so the child cannot exist without its parent (for example order ↔ order line). In a non-identifying relationship the parent's PK is added as a regular column and the child keeps its own independent PK (for example customer ↔ order).
Generated Column (Virtual Column): A column whose value is computed from a SQL expression instead of being entered directly. VIRTUAL computes the value on read while STORED persists it, and support varies by DBMS. Marking a column as generated clears its regular default value and auto-increment settings.
Schema Revision: A snapshot created every time the ERD is saved. You can restore a past revision or diff two revisions to review changes.
Schema Compare: Compares two ERDs, or an ERD against an actual database, side by side to surface added, changed, and removed tables, columns, and relationships. You can apply only the differences you choose via Forward Engineering.
Rename Matching: A schema-compare setting that pairs a deleted item with an added one so a renamed table or column produces RENAME DDL instead of "drop + create". Without the match the rename is expressed as a drop and re-create, which loses the existing data — so it matters most when syncing production.

Connection

Profile (Connection Profile): A risk label applied to a database connection. Choose None / Confirm / Read-only — Confirm pops a confirmation dialog before DDL and DML without a WHERE clause, while Read-only blocks every change other than SELECT.
Watermark: A translucent label drawn across the ERD canvas and SQL Editor background based on the connection's profile. When enabled, the environment identifier (such as Prod or Staging) is shown over the whole workspace so you can tell at a glance which environment you are working in and avoid mistakes on production databases.
Public Connection · Private Connection: Whether a connection can be shared with teammates or stays yours alone. Connection details nobody else can reach — localhost or SQLite, for example — are classified as private automatically, and switching a public connection to private turns every team ERD that used it into a personal ERD. Private connections cannot be created or used in the web app.
Schema Mapping · Prefix: A connection setting that controls which database schemas are exposed and, optionally, prepends the schema name to each table (for example `public.users` instead of `users`). The prefix is useful for telling apart same-named tables that live in different schemas.
Renamer: Rules that rewrite table and column names while reverse engineering. You can stack several regular-expression replacements and case-format conversions (snake_case, camelCase, and so on) for tables and columns separately; they apply in list order. Renamer never affects forward engineering.
Table Template: A list of default columns defined per connection. Every new table added on the ERD starts with those columns, which keeps shared audit columns such as created_at and updated_at consistent across the whole schema.
Custom JDBC Driver: A JDBC driver registered by uploading your own .jar instead of using the bundled one. Use it when you need a specific version or an in-house driver; registration is available in desktop mode only.
Gallery: A space that collects ERDs published as public. You can browse other users' ERDs and clone them into your own project to learn from or reuse.
Embed Viewer: A read-only viewer that embeds a published gallery ERD into an external page — a blog, engineering doc, or internal wiki — through an iframe. It offers table search and DDL viewing, and URL options control the panel, minimap, controls, and the viewport it opens at.

SQL Editor

Danger Guard: A safeguard that inspects SQL before it runs and warns you about destructive statements. Schema-dropping commands such as DROP TABLE or TRUNCATE are flagged as Critical, and UPDATE/DELETE without a WHERE clause as Warning, both prompting a confirmation dialog before execution to prevent accidental data loss.
Transaction · Auto-commit: Controls when SQL changes are made permanent. With Auto-commit on, each statement is committed automatically right after it runs; with it off, you manage the transaction yourself by issuing COMMIT to confirm or ROLLBACK to discard the changes.
Parameterized Query (Bind Parameters): A query that contains bind variables written as `:name`. NeoSQL detects them at execution time and prompts for each value in a modal; the entered values are type-converted automatically and saved for reuse on later runs.
Execution Plan (EXPLAIN): A visualization of how the database will run a query, opened with the PLAN button. The execution path is drawn as a tree with color-coded steps (for example orange for a full scan, green for a key lookup) so you can spot performance bottlenecks; interpretation guides are provided per DBMS.
Max Rows · Load More: The cap on how many result rows are fetched at once (200 by default) and the control that pulls the next page when the cap is hit. Truncated results show a (truncated) marker in the status bar together with a Load More button. Loading more while the edit mode has unsaved changes discards those changes.
Data Edit (Result Grid Editing): An edit mode that lets you INSERT, UPDATE, and DELETE rows straight from a SELECT result grid. Changes are not sent immediately — you review the generated SQL in a preview and then apply them in one batch.
Snippet: Frequently used SQL saved with a name, target connection, and default schema so you can reload it from the list. Where the execution history is recorded automatically, snippets are the statements you deliberately keep.

Collaboration & Permissions

Roles (Owner / Manager / DBA / Member): The four roles assigned to project members. Owner is the project creator (one per project) with full permissions including member management, deletion, and ownership transfer; Manager is delegated member and settings management; DBA can be designated as a DDL approver; Member is a regular collaborator. Fine-grained permissions such as sharing, connection access, and DDL restrictions are configured per role via checkbox combinations.
Personal ERD · Team ERD: The two kinds of ERD in online mode. A Personal ERD is visible only to you and is neither synced nor exposed to teammates; a Team ERD is shared by every project member and kept in real-time two-way sync. Connection privacy determines the type — making a connection private turns its team ERD into a personal ERD.
Invite Status: The lifecycle state of a project invitation. Possible values are PENDING (awaiting response), ACCEPTED (joined), EXPIRED (timed out), and CANCELLED (withdrawn). Invitations can be cancelled before acceptance, and expired ones must be resent.
DDL Approver · DDL Restriction: A feature that restricts who can execute DDL (CREATE/ALTER/DROP) statements within a project and requires approval from a designated DDL approver (typically the DBA role) before changes take effect. Used to prevent accidental schema changes to production databases.

Account & Subscription

Workspace: The unit that lets several people share one subscription plan. The owner who pays for the plan invites members, and each member can create their own projects with the owner's plan features and limits. It is separate from per-project collaboration roles.
Seat: How many members you can invite to a workspace, determined by the subscription plan. Active members and pending invitations take seats; the owner and suspended members do not.
License Key (Offline): The key used to authenticate offline mode. You issue it yourself from a slot on My Page; it only permits the JDBC URLs registered at issue time and stays valid for 30 days. The desktop app revalidates it periodically and signs you out once it expires.
Plan Cleanup: The step after downgrading to a smaller plan where you choose which projects, members, connections, and schemas to keep within the new limits. Anything not selected is deactivated rather than deleted, so upgrading again restores it.

AI & MCP

MCP (Model Context Protocol): The standard protocol that lets AI assistants like Claude, Codex, and Gemini call NeoSQL's table definitions and SQL execution as tools. NeoSQL's MCP server exposes a tool catalog that the AI client consumes.
NL2SQL (Natural Language to SQL): Turning a natural-language question into a SQL query with AI. NeoSQL's built-in AI Assistant or an MCP client uses the database schema information it needs, so you can request data in plain language without knowing the exact table or column names.
Provider Key (AI Provider API Key): An API key you register so AI Assistant can call an LLM. Account projects use encrypted account keys, while local projects use device-local keys in the OS secure storage.
AI DB Context: The Connection, Database, and Schema scope selected when sending a message. It is the strict allowlist the AI may discover or access through DB Tools for that request, and it can change before the next request.
Execution Policy: Controls AI-generated SQL at the target Connection level. A route-bound SELECT runs after the response, DML and DDL follow data-change and schema-change auto-apply settings, and UNKNOWN SQL is never executable.
Tool Approval: The user approval required before the AI runs a limited SELECT that reads actual rows. Approve subsequent lookups can persist across later requests and other Chats in the same project runtime, separately from final-SQL execution policies.
AI SQL Card: An inline Chat card that shows each AI-generated SQL statement and provides Run, Open Editor, and Copy. Results appear on the card, and Open Editor creates an editable copy in the regular SQL Editor.

docs.referenceGlossary.codegen.title

docs.referenceGlossary.codegen.templateTerm: docs.referenceGlossary.codegen.templateDef
docs.referenceGlossary.codegen.languageProfileTerm: docs.referenceGlossary.codegen.languageProfileDef
docs.referenceGlossary.codegen.velocityTerm: docs.referenceGlossary.codegen.velocityDef
docs.referenceGlossary.codegen.draftVersionTerm: docs.referenceGlossary.codegen.draftVersionDef

Security

Zero-Knowledge Encryption: An additional protection layer where credentials are decrypted only with a key derived from the user's passphrase. The server never stores the plaintext key, and lost passphrases make the data unrecoverable.
Standard Encryption: AES-256-GCM credential encryption where the data key (DEK) is protected by KMS Envelope Encryption. Applied to every user by default with no extra configuration.
DEK (Data Encryption Key): The key that directly encrypts sensitive data such as database credentials. Generated separately per user and per resource, never stored in plaintext, and additionally wrapped via KMS Envelope Encryption.
KMS Envelope Encryption: A pattern that re-encrypts the DEK with a master key issued by a cloud KMS (Key Management Service). The master key never leaves KMS; the service requests an unwrap whenever the DEK is needed so the plaintext key lives in memory only briefly, keeping credentials safe even if the database is leaked.
Column Masking: Marks values that must not be exposed — national ID, phone, or account numbers — either by column or by regular-expression pattern, and hides them on the server before sending results to teammates who hold a masked role. The real values never reach the client.