The on-disk representation of a database schema definition. Every tool in the suite reads, writes, or modifies schema packages.
A schema package is your database's source of truth — the complete, version-controlled definition of what your databases should look like.
A schema package is the on-disk artifact that every SchemaSmith tool produces or consumes.
It is a folder — or a .zip archive of that folder — holding the product and
template configuration, the table definitions, the SQL scripts, and the JSON Schemas that
validate every file in the package. One package, one deployable unit, one source of truth.
The package's contents are described elsewhere in the documentation: see Products and templates for the JSON configuration files at the package's core, Defining tables for the table JSON format, and Data delivery alongside Conditional application for the declarative data and deployment controls table files can carry. This page focuses on the package as a container: where files live, how the folder tree is laid out, how ZIP distribution works, and how filesystem-illegal object names get encoded onto disk.
A schema package is a predictable directory tree. Every tool in the SchemaSmith toolset
discovers what it needs by convention — Product.json at the root,
Templates/ one level down, platform-specific script folders inside each
template — so you never have to configure paths or point a tool at individual files.
Marker files and generated artifacts sit alongside the files you author, and the whole
layout maps cleanly onto source control.
MyProduct/
Product.json Product configuration (required)
.json-schemas/ JSON Schema files for IDE validation (generated)
products.schema
templates.schema
tables.schema
indexedviews.schema SQL Server packages
materializedviews.schema PostgreSQL packages
.community Marker file (generated by SchemaTongs)
Before Product/ SQL scripts run before all templates
After Product/ SQL scripts run after all templates
Templates/
TemplateName/
Template.json Template configuration (required)
Tables/ Table definition JSON files (all platforms)
public.customer.json
sales.order.json
Indexed Views/ Indexed view definitions (SQL Server only)
dbo.vw_OrderSummary.json
Materialized Views/ Materialized view definitions (PostgreSQL only)
public.mv_active_orders.json
<platform default folders> See Default Folders on Products and Templates
<custom folders> Anything you declared in ScriptFolders
Table JSON files are named schema.tablename.json (e.g.,
dbo.Customer.json, public.order_lines.json). For MySQL the
schema segment is the database/schema name. If a table or schema name contains
filesystem-illegal characters, the encoded form is used in the filename — see
Filesystem-Illegal Character Encoding.
SQL script files can be organized into subdirectories within any script folder. All
.sql files are discovered recursively and sorted alphabetically by full path.
Your IDE can help you write correct JSON if you point it at the right schemas. The
.json-schemas/ directory at the package root contains JSON Schema definition
files generated automatically by SchemaTongs on the fly from the live C#
domain types — no embedded files, no shipped artifacts, just a snapshot of the engine's
exact current shape.
Per-platform packages get the relevant schemas:
| File | Validates |
|---|---|
products.schema |
Product.json |
templates.schema |
Template.json |
tables.schema |
Table JSON files (Tables/*.json) |
indexedviews.schema |
Indexed view JSON files (SQL Server packages) |
materializedviews.schema |
Materialized view JSON files (PostgreSQL packages) |
Because the schemas are regenerated every time SchemaTongs writes a package, they always
match the current engine. If you've hand-edited any of them to add a custom validation
fragment under Extensions, that fragment is preserved through regeneration —
see Custom Properties: JSON Schema Validation.
SchemaQuench can consume schema packages as ZIP archives. When the
SchemaPackagePath configuration value points to a .zip file,
SchemaQuench reads the package directly from the archive without extracting it to disk
first.
Requirements:
This is useful for deployment pipelines where the schema package is built as a single artifact.
Object names can contain characters that are illegal in file paths on Windows, macOS, or Linux. SchemaTongs uses a percent-encoding scheme to safely map these names to filenames.
| Character | Encoded As |
|---|---|
\ | %5C |
/ | %2F |
: | %3A |
* | %2A |
? | %3F |
" | %22 |
< | %3C |
> | %3E |
| | %7C |
% | %25 |
Additional rules:
%20 for space, %2E for dot) because many filesystems strip or reject them at the start of filenames.SchemaQuench decodes these filenames transparently when reading definitions. You generally don't need to worry about encoding unless you're creating JSON files by hand for tables with unusual names.
Last reviewed May 2026 by the SchemaSmith Team.